Multiplayer abweichende paks

[Freahk]

Ich habe für eine neue Spielrunde ein neues add-on Paket erstellt. Nachdem ich den Server erstmal dazu überreden konnte keinen segmentation fault zu produzieren, habe ich den addons/pak128 Ordner vom Server dort gepackt und runtergeladen, meinen addons/pak128 Ordner gelöscht und den neu heruntergeladenen dort entpakt.
Ich starte Simutrans natürlich auch mit den addons.
Wenn ich versuche mich zum Server zu verbinden bekomme ich mitgeteilt, dass die paks abweichen.

Am pak128 ohne addons kannes nicht liegen, da ich zum Server verbinden kann, wenn weder der Server noch mein Rechner die addons laden.
Wenn ich jetzt auf dem Server und dem Client nur ein paar addons rein schiebe funktioniert es auch. Es scheint also an ein par wenigen paks zu liegen die zu diesem Problem führen. Ich versuche noch herauszufinden welche das sind.

Dennoch sieht es für mich erstmal so aus, dass der (Linux) Server manche paks anders läd als mein Windows Client. Ansonsten müssten ja die Prüfsummen der paks (ich vermute mal, dass die Übereinstimmung darüber geprüft wird) übereinstimmen.

Edit: ich meine ein Muster erkannt zu haben: teilweise haben wir komplette packs genommen und nur einzelne Fahrzeuge daraus verändert, wodurch manche objekte doppelt als addon existieren (schön blöd, ich weiß). Die Ladereihenfolge scheint nicht vom System unabhängig zu sein. Daraus folgt, dass mein Server sich für das jeweils andere objekt entscheidet.
Es wäre super wenn Simutrans sich "merkt" welches Objekt addon ist und welches nicht.
Wenn es in einem addon ein Objekt findet das bereits im normalen pack existiert, dann sollte es wie aktuell auch dieses einfach überschreiben.
Wenn es in einem addon ein Objekt findet das bereits als addon aus einer anderen Datei geladen wurde, sollte es sich dieses merken und den Ladevorgang fortsetzen.
Am Ende des Ladevorgangs sollte Simutrans alle solche Objekte auflisten (zusammen mit den Dateinamen der in Konflikt stehenenden paks) und das Spiel abbrechen.

Aktuell wird zwar immer eine overlaid warning ausgegeben aber diese wird auch ausgegeben wenn etwas aus dem originalen pak überschrieben wird. Dies ist häufig gewollt und führt dazu, dass die tatsächlich problematischen overlays in den Tiefen des logs übersehen werden.

[Dwachs2]

Wenn es in einem addon ein Objekt findet das bereits als addon aus einer anderen Datei geladen wurde, sollte es sich dieses merken und den Ladevorgang fortsetzen.

Das Problem ist tatsaechlich, dass unterschiedliche Betriebssysteme die Dateien in unterschiedlicher Reihenfolge einlesen. Das Einzige, was man hier machen kann, ist, eine Warnung anzuzeigen nach dem Laden. Beim Rumspielen mit addons muss man also aufpassen, dass da nicht Objekte mit gleichem Namen dabei sind.

[Freahk]

Oder man "bewertet" Die Objekte anhand nicht OS abhängigen Kriterien und entscheidet anhand dieser Bewertung ob das Objekt überladen wird oder nicht. Wäre imho die beste Lösung.
Ich denke dabei dabei an ein System mit dem man in einer Config festlegen kann welches der identischen objekte man haben möchte. Sollte zu einem doppelten Objekt kein solcher Eintrag existieren, wird dies am Ende des Ladevorgangs als Warnung ausgegeben.

Ist etwas mehr Aufwand aber es hätte auch folgende Vorteile:
Wenn man ein (non-oss) addon Gesamtpaket verwendet und davon einzelne Dateien überschreiben möchte, kann man das mit dieser Datei eindeutig und vom OS unabhängig festlegen.
Und wenn man mehrere adon Pakete nutzt, die teilweise gleiche Objekte definieren, werden auch dabei unabhängig vom System immer die Gleichen objekte geladen.
Ich denke da neben dem Multiplayer auch an Maps die zusammen mit den addons weitergegeben werden oder (wie bei mir) in einem Verzeichnis liegen auf das ich je nach Lust und Laune mal mit Windows und mal mit Linux zugreife.

[Dwachs2]

Meiner Meinung nach gibts fuer das Problem keine Loesung, nur die Moeglichkeit, eine Warnung auszugeben.

Das interne Bewerten und Vorziehen von einem Objekt (OS-unabhaengig) geht nicht so einfach, weil intern beim Laden eines Objekts gar nicht weitergeleitet wird, dass da jetzt ein Addon kommt. Das Objekt, das zuletzt gelesen wird, gewinnt.

Wie willst du denn in einer Config festlegen, welches der Objekte mit gleichem Namen nun gewaehlt werden soll?

Ich verstehe nicht, wo der Vorteil ist, dass man im addons-Verzeichnis mehrere Objekte gleichen Namens hat, von denen man aber bei Programmstart noch nicht weiss, welches am Ende gewinnt?

[prissi]

Also das Objekt im Addon-Folder gewinnt, bzw. wird als letztes geladen. Gibt es das Objekt mehrmals in Multipaks wird es in der Tat zufällig; selbst in Windows kann die Reihenfolge von der Sortierreihenfolge im Explorer abhängen oder was zuletzt im Cache lag.

Ich finde es eh einen schlechte Idee, genau das gleichnamige Objekt mit unterschiedlichen Parametern zu haben. Selbst im besten Fall ist Konfusion vorprogrammiert.

[Freahk]

@ Prissi das ist in der Tat erstmal eine schlechte Idee. Allerdings existieren non-oss paks die sich in wenigen Objekten überschneiden und sich in allen anderen Objekten ergänzen
Da kann man sich bei der aktuellen Situation dann nur zwischen einem der in Konflikt stehenden Paks entscheiden.

Außerdem passiert es ab und an (mir z.B. beim zusammenstellen der addons), dass man zu einzelnen Objekten aus non-oss paks die Quelldateien hat und eines dieser Fahrzeuge anpassen möchte.
Da wäre eine Möglichkeit gezielt das Objekt auszuwählen sehr praktisch. Das könnte dann so aussehen, dass Simutrans sich am Ende des Ladevorgangs beendet und die in Konflikt stehenden Objekte zusammen mit dem Pfad ausgibt.
Also in etwa:

Code:

Beim laden der Objkete sind Konflikte aufgetreten. Simutrans wird beendet.
addons/ace-all.pak/Haru-ACE1_Head steht in Konflikt zu addons/ice1.pak/Haru-ACE1_Head

Das setzt natürlich vorraus, dass Simutrans sich beim laden der Objekte den Pfad merkt. Wenn der Ladevorgang erfolgreich war kann Simutrans diese Daten ja wieder wegwerfen.

Jetzt weiß man zumindest schonmal welche Dateien im Konflikt stehen und könnte eben diese Pfade in eine conflicting.conf im entsprechenden addon Ordner ablegen.
In dieser würde dann in etwa sowas stehen:

Code:

Haru-ACE1_Head = addons/ace-all.pak

Damit wüsste Simutrans beim nächsten Ladevorgang sofort, ob es ein Objekt laden soll oder nicht.
Wenn es einen Eintrag in der Konf gibt, verwerfe alle gleichnamigen Objekte die nicht mit dem eingetragenen Pfad übereinstimmen.
Wenn es keinen Eintrag gibt, lade wie vorher auch das Objekt und merke den Pfad dazu. Wenn es einen Konflikt gibt, vermerke dies und gib die Konflikte wieder am Ende des Ladevorgangs aus.

[Wurzelgnom]

Lösung: einfach keine Multi-Paks im Addon-Ordner ablegen

Zumindest wenn sich an die Grundeinstellung Objektname = Dateiname gehalten wird, fallen gleiche Objekte auf. Namensgleich ergo gleiches Objekt.

[Freahk]

Wo sollen die Multipaks denn dann hin wenn nicht in den addon Ordner?
Nur ein Objekt pro Datei? Na dann viel Spaß bei großen MUs. Ganz davon ab, dass zu viele pak Dateien im addon Ordner das Spiel zum Abstrurz bringen.

[Wurzelgnom]

....
Nur ein Objekt pro Datei? Na dann viel Spaß bei großen MUs. Ganz davon ab, dass zu viele pak Dateien im addon Ordner das Spiel zum Abstrurz bringen.

Wenn es so viele sind, dann kopiere den originalen Setordner in ein neues Verzeichnis und werf Deine ganzen Addons da rein.

Und ich glaube nicht das es an zu vielen Addon-Dateien im Addon-Ordner liegt. Simutrans ist mal Abgestürzt weil es zu viele Objekte waren.

Und an der Objektzahl ändert sich nichts. Denn es ist irrelevant ob die Objekte einzeln oder zusammen in einer Datei stecken.

[Freahk]

Wie auch immer. Das ändert nichts am eigentlichen Problem.
Es wäre wünschenswert, wenn Simutrans zumindest auf solche Konflikte aufmerksam machen würde. Besser wäre eine Möglichkeit solche Konflikte manuell zu lösen.
Einzig möglicher workarround aktuell:
Die meisten addons sauber ins addon Verzeichnis legen und die addons die solche Konflikte erzeugen in den normalen pak Ordner legen. Das ist aber schon ein ziemlich unschöner workarround mit einigen Einschränkungen.