Mission als Gruppe bearbeiten

  • Multiplayer

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Mission als Gruppe bearbeiten

    Hallo an alle,

    für unser Projekt haben sich nun mehrere Leute gefunden, die gerne an der Mission (mission.sqm) arbeiten möchten. Allerdings bringt dies nun Probleme mit sich.
    Als großen Problem sehen wir, dass beim "Zusammenführen" der Mission durch den Editor, alle Objekte die zuvor schon platziert waren nun doppelt vorhanden sind.

    Unsere Gedanken waren nun folgende:
    1. Die Mission ist auf dem Server gespeichert und jeder lädt sie herunter, bearbeitet diese und lädt sie danach wieder hoch.Problem: Zeitgleiches arbeiten ist nicht möglich.
    2. Wenn jemand einen Bereich platziert, erstellt er zuvor eine neue Mission. Diese wird danach mit der aktuellen Mission "Zusammengeführt".
      Probleme:
      1. Wenn jeder selber die Missionen Zusammenführt, kann in dem Moment niemand anderes Zusammenführen.
      2. Wenn es einen Verantwortlichen für die Mission gibt, der das Zusammenführen übernimmt. Besteht das Problem, dass kein Fortschritt möglich ist, wenn dieser keine Zeit hat. Zudem muss sich dieser mit den neuen Missionen beschäftigen.
      3. Wenn Objekte bearbeitet wurden, müssen diese Änderungen jedem bekannt gemacht werden, da dies beim Zusammenführen beachtet werden muss.
    3. Die Mission ist in Git gespeichert und Git übernimmt das Zusammenzuführen.
      Problem: Unsere bisherigen Test zeigten allerdings klar, dass Git damit nicht umgehen kann und eine bearbeitung durch den Nutzer verlangt.
    4. Wir wollten ein Tool nutzen, dass mit dem Missionsformat umgehen kann und das Zusammenführen übernimmt.
      Problem: Wir haben zwar einige Tools gefunden die angefangen wurden zu programmieren, allerdings nicht fertiggestellt wurden.
    Punkt 1 fällt weg, da keine wirkliche Gruppenarbeit möglich ist.
    Bei Punkt 2 kann es durch Unachtsamkeit schnell zu doppelten Objekten kommen.
    Bei Punkt 3 kann es durch die Bearbeitung durch den Nutzer schnell zu einer fehlerhaften Mission kommen, wenn nicht alle IDs, etc. richtig angepasst wurden.
    Wir würden gerne Punkt 4 nutzen. Allerdings kein Tool gefunden.

    Unsere Überlegung war nun, ein eigenes kleines Tool zu schreiben, dass die Aufgabe erledigt.

    Bevor wir dies tun, wollten wir uns mal umhören, ob wir eine einfache Variante übersehen haben.
    Vielleicht haben wir auch ein Tool übersehen das die Aufgabe bereits erledigt.

    Wir sind offen für Vorschläge mit denen wir unser Ziel erreichen können.

    Grüße
    Henne
  • Das Problem ist altbekannt und hierfür gibt es einfach keine (mir bekannte) Lösung. Git fällt komplett flach, da die Objekte in der mission.sqm ja eine Nummerierung aufweisen, die du nicht per Hand nachkorrigieren kannst, ausgeschlossenes Mikromanagement. Die sauberste mir bekannte Lösung ist das von dir bereits angesprochene manuelle Zusammenführen. Wollt ihr das nicht an eine Person binden, dann müsst ihr ganz einfach mit einem manuellen Lock-Mechanismus arbeiten, sprich die master-Datei liegt für alle bereit und wer diese nimmt, um etwas hinzuzufügen, sperrt sie für alle anderen, z.B. durch eine Umbenennung einer anderen Datei etc., da gibt es bel. Möglichkeiten. Aber die mission.sqm ist leider so speziell, dass man sich sonst die Zähne ausbeißt.

    Und das löst auch nur das Problem für neue Objekte. Bestehende Objekte sind beim Zusammenführen ja nicht betroffen. Wenn also jemand dann noch etwas an bereits bestehenden Objekten ändert, wären diese Änderungen verloren.

    Daher ist ein zeitgleiches Arbeiten fast ausgeschlossen. Git könnte grundsätzlich Änderungen an ausschließlich bestehenden Objekten lösen, da hier keine Nummerierung verändert wird. Zusammenführen muss dann manuell erfolgen. Daher wäre mein Vorgehen, dass man neue Objekte/Basen etc. modular verteilt und dann manuell zusammenführt. Änderungen an bestehenden Objekten sollten abgesprochen und dann sofort eingespielt werden, so dass immer nur eine Person zu einer Zeit die master-Datei verändert. Daher auch grundsätzlich: Möglichst wenig im Editor und möglichst viel via Skript -> alle Probleme gelöst ;)

    Bin mit dem Format der mission.sqm bei Änderungen nicht so vertraut, es kann aber gut sein, dass ein Tool hierfür tatsächlich schnell programmiert ist, wenn "nur" die Nummerierung aufeinanderfolgend und lückenlos sein muss. Mir fallen da zunächst die Classnames auf wie Itemxyz und dann das Attribut id, hier wäre das Zusammenspiel wichtig zu verstehen.
    Autor des SQF-Scriptquide
    Missionsbauer der OPT

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von James ()

  • Ich danke euch beiden für eure Antworten.


    Raven schrieb:

    Also besser als mit git wirds meiner Erfahrung nach nicht... Aber damit das funktioniert darf die Missionsdatei natürlich nicht binarisiert werden :28_thinking:
    Es ist richtig, dass die Missionsdatei nicht binarisiert werden darf. Allerdings ist dies ja kein Problem. Für den laufenden Betrieb wäre es ja möglich diese nachträglich zu binarisieren, wenn man es umbedingt möchte.

    James schrieb:

    Das Problem ist altbekannt und hierfür gibt es einfach keine (mir bekannte) Lösung. Git fällt komplett flach, da die Objekte in der mission.sqm ja eine Nummerierung aufweisen, die du nicht per Hand nachkorrigieren kannst, ausgeschlossenes Mikromanagement. Die sauberste mir bekannte Lösung ist das von dir bereits angesprochene manuelle Zusammenführen. Wollt ihr das nicht an eine Person binden, dann müsst ihr ganz einfach mit einem manuellen Lock-Mechanismus arbeiten, . . . Aber die mission.sqm ist leider so speziell, dass man sich sonst die Zähne ausbeißt.
    Meine bisherigen Test zeigten, dass es möglich ist. Mit dem Wissen wie die Datei aufgebaut ist, diese auch per Hand zu bearbeiten (was ich zum Test auch gemacht habe) und so Fehler zu beheben.

    James schrieb:

    Und das löst auch nur das Problem für neue Objekte. Bestehende Objekte sind beim Zusammenführen ja nicht betroffen. Wenn also jemand dann noch etwas an bereits bestehenden Objekten ändert, wären diese Änderungen verloren.
    Nunja, gerade bestehende Objekte sind betroffen. Tests zeigten, dass Arma im Prinzip die beiden Missionsdateien lädt und die Objekte beider Dateien platziert. Denn Arma prüft beim Zusammenführen nicht, ob an der Stelle bereits ein Objekt mit den selben Argumenten vorhanden ist. Arma platziert also dann das Objekt an der Stelle doppelt.
    Richtig, das bearbeiten und löschen eines Objekts wird dadurch schwer, da alle anderen das Objekt ja noch haben und dieses wieder platziert wird.

    James schrieb:

    Git könnte grundsätzlich Änderungen an ausschließlich bestehenden Objekten lösen, da hier keine Nummerierung verändert wird. Zusammenführen muss dann manuell erfolgen. Daher wäre mein Vorgehen, dass man neue Objekte/Basen etc. modular verteilt und dann manuell zusammenführt. Änderungen an bestehenden Objekten sollten abgesprochen und dann sofort eingespielt werden, so dass immer nur eine Person zu einer Zeit die master-Datei verändert. Daher auch grundsätzlich: Möglichst wenig im Editor und möglichst viel via Skript -> alle Probleme gelöst ;)
    Sobald ein Objekt gelöscht wird, verändert sich die Nummerierung. Alle folgenden Objekte werden nach vorne gezogen.
    Also würdest du Punkt 2(.1) nutzen. Ohne weiteren Aufwand, wäre dies wahrscheinlich auch die einfachste Lösung.
    Das mit allem im Skript klingt zwar sinnvoll, dass würde die Probleme großteils lösen. Allerdings müsste dann ja das Skript erst jedes Objekt auf der Karte platzieren.

    James schrieb:

    Bin mit dem Format der mission.sqm bei Änderungen nicht so vertraut, es kann aber gut sein, dass ein Tool hierfür tatsächlich schnell programmiert ist, wenn "nur" die Nummerierung aufeinanderfolgend und lückenlos sein muss. Mir fallen da zunächst die Classnames auf wie Itemxyz und dann das Attribut id, hier wäre das Zusammenspiel wichtig zu verstehen.
    Im "Header" der Datei ist eine Angabe für den Editor welche Objekt-ID als nächstes folgt. Diese müsste entsprechend angepasst werden.
    In der Liste mit den Objekten ist eine Angabe, wieviele Objekte in der Liste stehen. Jedes Objekt kann eine weitere Liste beinhalten, in der genauso verfahren wird.
    Die Objekte in der Liste sind durchnummeriert, diese müssen vollständig sein und mit der Anzahl übereinstimmen.
    Jedes Objekt hat zusätzlich noch eine ID und einen type-Bezeichnung (Klassennamen). Die ID verändert sich nicht. Dadurch wäre eine eindeutige Zuordnung möglich. Die IDs müssen nicht aufgefüllt sein. Der Klassenname könnte nur Händisch verändert werden, was nicht vorgesehen ist.

    Für das Tool haben wir uns natürlich schon Gedanken gemacht. Wenn die Ursprungsdatei (auf welcher Basis die Veränderungen gemacht wurden), die aktuelle master Datei und die neue veränderte Datei, miteinander verglichen werden, ist anhand der ID und des Klassennamen ersichtlich, welche Objekte doppelt sind. Diese können rausgefiltert werden. Durch die fehlenden IDs ist klar welche Objekte gelöscht wurden. Die Veränderungen an einem Objekt sind durch die Ursprungsdatei ersichtlich. Ein Problem das wir gedanklich noch nicht gelöst haben ist, was passiert wenn ein Objekt sich in allen Dateien unterscheidet, welche der Änderungen dann übernommen wird. Sobald das Tool die Objekte sortiert hat, schreibt es die Listen und passt die Nummerierung an. Die IDs der alten Objekte werden nicht verändert, da sonst Probleme beim nächsten Zusammenführen auftreten. Die IDs der neuen Objekte müssen ensprechend angepasst werden, da sonst IDs doppelt belegt sind. Ein weiteres Problem ist, wenn zwei Leute das gleiche Objekt setzen und die Objekte zufällig die selbe ID bekommen. Das würde das Tool als ein Objekt erkennen und das andere löschen.


    Wenn die nächste Zeit, keine anderen/besseren Vorschläge kommen, werden wir uns mal an einer kleinen Testversion für das Tool versuchen.
  • Sobald das selbe Objekt von mehr als einer Person geändert wurde, muss jemand eingreifen und dem Programm sagen, welche Änderung genommen werden soll (oder beide Änderungen zusammenführen). Da kann das Programm einfach nix entscheiden (siehe git).

    Was das Problem der zufällig gleichen ID angeht so lässt sich das umgehen, indem man Objekte anhand ClassName und Position unterscheidet und die IDs bei Bedarf nachträglich verändert, wenn sie doppelt belegt ist.

    In welcher Sprache wollt ihr euer Tool denn schreiben? Solltet ihr Java verwenden, dann könnt ihr euch das hier mal anschauen: github.com/Krzmbrzl/ArmaFiles
    Das ist ne kleine Bibliothek von mir, die unter Anderem dafür gemacht ist mit Config-Dateien umzugehen. Preprocessor versteht sie zwar nicht aber für die SQM sollte das ja egal sein. Und wenn ihr Fragen dazu habt, dann könnt ihr euch natürlich an mich wenden ;)
    Entwickler von SQDev
    Co-Entwickler von OurAltis
  • Warum baut ihr sie nicht Live in Zeus? Speichern geht dann nicht aber wenn es nur eine Abendmisson sein soll klappt es. Sonst müsste ihr euch einteilen das einer die Bais baut, der anderen die Feindebewegung ... Das kopiert dann nur eine Person rein oder kann sie bearbeiten. Wenn dich aber mehr dafür interessiert fragt doch mal im Evants Team nach wie sie es machen. Das wäre evlt. Eine Hiffe.
    Grüße
    Airmean J.Weingarten
  • Raven schrieb:

    John Weingarten schrieb:

    Wenn dich aber mehr dafür interessiert fragt doch mal im Evants Team nach wie sie es machen. Das wäre evlt. Eine Hiffe.
    Bei uns wird die Mission komplett von einer einzigen Person gebaut.
    Bausteine werden aber zusammen gelegt. Einer kümmern sich um die Ausrüstung, einer für das Befring... Die Teile gehören doch zum Bauen dazu.
    Grüße
    Airmean J.Weingarten
  • Raven schrieb:

    Sobald das selbe Objekt von mehr als einer Person geändert wurde, muss jemand eingreifen und dem Programm sagen, welche Änderung genommen werden soll (oder beide Änderungen zusammenführen). Da kann das Programm einfach nix entscheiden (siehe git).
    Da geplant ist, es dem Nutzer so einfach wie möglich zu machen, wollten wir so ein Tool auf dem Server laufen lassen, damit er nur die Datei hochladen muss und den Rest das Tool übernimmt. Daher sind Nutzer Eingaben nur bedingt möglich. Eine Überlegung war von mir vorhin, eine weitere Missionsdatei mit allen Konflikten zu generieren, diese dem Nutzer zu geben, er die Konflikte löst und diese danach wieder eingespielt wird. So hat der Nutzer nur die Konflikte in einer Datei und kann sich darauf konzentrieren.

    Raven schrieb:

    Was das Problem der zufällig gleichen ID angeht so lässt sich das umgehen, indem man Objekte anhand ClassName und Position unterscheidet und die IDs bei Bedarf nachträglich verändert, wenn sie doppelt belegt ist.
    Richtig, wenn unterschiedliche Objekte die selbe ID bekommen, ist es sehr einfach dieses zu erkennen und dieses zu lösen. Die Frage ist aber wenn von zwei Nutzern je ein Objekt mit dem selben Klassennamen und zufällig der selben ID platziert wird. Die Objekte lassen sich dann nur anhand der Argumente (Position, Bezeichnung, Ausrüstung, ...) unterscheiden. Woran soll nun das Programm aber erkennen, dass dies zwei neue Objekte sind, oder ob das Objekt nur bearbeitet wurde.

    Gedanklich wäre es möglich, zu prüfen ob die Objekte in der Ursprungsdatei sind, wenn beide dort nicht vorhanden sind, sind beide neu und werden beide übernommen. Denn ein Zusammenführen auf anderem Weg, als über das Tool ist dann nicht vorgesehen und führt dann zu solchen Problemen.

    Auch wäre von uns eine Identifizierung eines Objekts durch die ID und dem Klassennamen geplant.

    Raven schrieb:

    In welcher Sprache wollt ihr euer Tool denn schreiben? Solltet ihr Java verwenden, dann könnt ihr euch das hier mal anschauen: github.com/Krzmbrzl/ArmaFilesDas ist ne kleine Bibliothek von mir, die unter Anderem dafür gemacht ist mit Config-Dateien umzugehen. Preprocessor versteht sie zwar nicht aber für die SQM sollte das ja egal sein. Und wenn ihr Fragen dazu habt, dann könnt ihr euch natürlich an mich wenden ;)
    Als Sprache war bisher Java geplant. Ich habe deine Bibliothek mal kurz überflogen, allerdings bin ich da noch nicht ganz schlau draus geworden. Ich habe aber auch noch nicht alles angeschaut.

    John Weingarten schrieb:

    Warum baut ihr sie nicht Live in Zeus? Speichern geht dann nicht aber wenn es nur eine Abendmisson sein soll klappt es. . . .
    Für eine Mission die nur an einem Abend laufen soll ist dies möglich, dass ist richtig. Allerdings geht es bei uns aktuell vorrangig um eine Mission für einen Life-Server.
  • Henne schrieb:

    Als Sprache war bisher Java geplant. Ich habe deine Bibliothek mal kurz überflogen, allerdings bin ich da noch nicht ganz schlau draus geworden. Ich habe aber auch noch nicht alles angeschaut.
    Also wenn das Ganze OpenSource wird und die Entwicklung zeitnah anfängt, würde ich mich prinzipiell dazu bereit erklären ein API für euch zu schreiben, das auf meiner Bibliothek aufbaut. Dann müsst ihr euch nicht mit dem Auslesen aus der Config beschäftigen, sondern könnt euch auf das Problem des Zusammenfügens konzentrieren.
    Da könnte man sich ja mal zusammen setzen und die genauen Anforderungen besprechen :)
    Entwickler von SQDev
    Co-Entwickler von OurAltis