05-10-2016, Wednesday-11:19:34
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.
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.