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:

• 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.
• Wenn jemand einen Bereich platziert, erstellt er zuvor eine neue Mission. Diese wird danach mit der aktuellen Mission "Zusammengeführt".
  Probleme:
  
  
  • Wenn jeder selber die Missionen Zusammenführt, kann in dem Moment niemand anderes Zusammenführen.
  • 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.
  • Wenn Objekte bearbeitet wurden, müssen diese Änderungen jedem bekannt gemacht werden, da dies beim Zusammenführen beachtet werden muss.
• 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.
• 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

Ich danke euch beiden für eure Antworten.

Zitat von Raven

Also besser als mit git wirds meiner Erfahrung nach nicht... Aber damit das funktioniert darf die Missionsdatei natürlich nicht binarisiert werden

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.

Zitat von James

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.

Zitat von James

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.

Zitat von James

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.

Zitat von James

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.

Zitat von Raven

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.

Zitat von Raven

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.

Zitat von Raven

In welcher Sprache wollt ihr euer Tool denn schreiben? Solltet ihr Java verwenden, dann könnt ihr euch das hier mal anschauen: https://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.

Zitat von John Weingarten

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.

Das die Objekte per Script gesetzt werden, hat bereits James vorgeschlagen.

Ich bin mir jetzt nicht ganz sicher was du genau meinst. Erkläre dies doch bitte nochmal genauer.