Nachfragen

[Wurzelgnom]

Es ist durchaus möglich und vorgesehen Karten von anderen Sets zu laden.

Habe ich eben mal versucht:
1. Pak128 geladen - Pak128G-Spielstand geladen - Absturz!
2. Pak128G geladen - Pak128-Spielstand geladen - läuft; aber mit welchem Ergebnis? Der lange Zug auf der Screencopy ist eigentlich ein Kohlezug und der Bus rechts ein Personenzug. Macht so etwas Sinn?

Die Betonung lag auch auf diesen beiden Sätzen.

...
Ursprünglich war es so vorgesehen. ...

Je besser die compat.tab da gepflegt ist um so besser lassen sich halt andere Setkarten laden.
....

Es kommt halt nicht von ungefähr, das bei pak64, pak64german und pak64.japan viele Waren den gleichen internen Namen haben.

Das alte pak128 hatte da auch noch recht viele Gemeinsamkeiten.

Beim pak128.german und dem openSource-pak128 war man halt dann der Meinung alles anders machen zu müssen, ohne Rücksicht auf bestehendes.

Es gibt 3 Standard-Waren ( None, Passagiere, Post ) die überall gleich sein müssen, weshalb eben reine Passagierkarten weniger Probleme machen.

Und es ist richtig, um etwas kompatibel zu machen/halten bedarf es Umsicht und Aufwand.
Etwas inkompatibel zu machen ist dagegen sehr leicht.

Also besteht von Seiten der Setmacher kein Interesse das Laden anderer Setkarten zu ermöglichen, wird dies auch nur schwer gelingen.

[Pumuckl999]

Also besteht von Seiten der Setmacher kein Interesse das Laden anderer Setkarten zu ermöglichen, wird dies auch nur schwer gelingen.

Ehrlich gesagt, habe ich persönlich diese Sicht auf die Dinge noch nie gehabt: Ich will als Spieler und beim Grafik erstellen möglichst was Neues, wenn es ein anderes Pak ist.
Kompatibilität bedingt mir im Gegensatz dazu zu viele Ähnlichkeiten.
Für neue Objekte schaue ich u.a. deswegen bewußt nicht in andere Paks, orientiere mich im Normalfall an der Bildersuche von Suchmaschinen, gefüttert mit eigenen Suchbegriffen, oder an Wünschen aus Forum und/oder Team.

"Anders" könnte also schon ein Grund gewesen sein, beim pak128.german zu landen .

Und einige "german"- spezifische Objekte dürften sich schlecht auf Objekte aus anderen Sets mappen lassen, oder umgekehrt ohne dass man dafür zu viele Einschränkungen hinnehmen müsste. In dem Fall müsste man sich bei der Objektwahl auf einen klein(st)en gemeinsamen Nenner einigen.

Ggf. ist das Thema aber ein Punkt für die readme eines Paks.

@Topic:
Finde ich gut. Mehrfache Ablehnungen der Vergangenheit könnte man ja im Zuge der technischen Weiterentwicklung auch mal neu überdenken: Auf den heutigen Monitoren mit angeschlossener Rechentechnik sollten sich i.d.R. die Inhalte von deutlich mehr Fenstern gleichzeitig ruckelfrei darstellen lassen, als zu Zeiten, als ST entstand. Risiko ist also ungleich höher, ausversehen mal das falsche Fenster zu schließen. Bin jedenfalls auch einer der gelegentlichen Fenster-ausVersehen-Schließer.

Das Problem, die zu speichernde Datei bei einem zwangsweise herbeigeführten shutdown zu terminieren, haben doch alle entsprechenden Programme?

[The Transporter]

Beim pak128.german und dem openSource-pak128 war man halt dann der Meinung alles anders machen zu müssen, ohne Rücksicht auf bestehendes.

Jaa, und das ganz bewußt!
Ansonsten hätte man ja auch das PAK128.german nicht zu machen brauchen. Wenn ich alles miteinander kompatibel halten will, das Karten, Fahrzeuge, Infrastruktur usw. alles austauschbar ist, ist der Aufwand für eine Neuerstellung eines Grafiklsets nicht nötig. Dann kann ich auch das bestehende verwenden. Darum heißt unser Grafikset auch PAK128.german und nicht pak128 Version 2.
Und da eine abwärtskompatibilität zu bereits bestehenden Grafikset nirgends zwingend gefordert ist, haben wir eben die Freiheit genutzt, was neues zu erstellen.

Eine volle Austauschbarkeit mit einem bestehenden Grafikset würde aber auch bedeuten, das nicht nur die compat.tab entsprechend ausgelegt sein muß, sondern auch die Anzahl der Objekte (Fahrzeuge, Gebäude, Fabriken und sonstiges) mit dem ursprünglichen übereinstimmen müßte. Da eine Abweichung auch hier zu Unstimmigkeiten, und dadurch zu Ladefehlern führen würde.
Das Problem der Kompatiblität zwischen 2 Grafikset ist wesentlich vielschichtiger als nur die compat.tab "gut zu pflegen".
Genaugenommen müßten sogar Preise, Erlöse und Produktionszahlen übereinstimmen.

Am Ende wäre es nur ein paar Grafiken, die dann den Unterschied zwischen den Grafiksets ausmachen. Das Verhalten, das Balancing wären das selbe.

Wer braucht oder will 2 Grafiksets, die sich nur anhand von den Grafiken unterscheiden?

Das Interessante ist doch, das sie sich ganz verschieden spielen lassen, oder sehe nur ich das so?

[Wurzelgnom]

@The Transporter

Ah ja, man macht also die Sets über andere interne Warennamen inkompatibel weil man es so individueller und schöner findet.

kleiner Denkanstoß

Wenn der Warenname im Spiel bei 2 Sets gleich angezeigt wird, geht man auch davon aus das der interne Name der Ware gleich ist.

Erstellt man ein Fahrzeug für das eine Set geht man davon aus das es auch im anderen funktioniert.

Aber dumm gelaufen, man ist ja so individuell, das man inzwischen für jedes Set sein Fahrzeug als extra pak-Datei mit angepasster Ware erstellen muss.
Selbiges gilt bei Industrieerweiterungen wenn existierende Waren einbezogen werden.

Von daher seid ihr schön individuell, aber macht es Addons-Erstellern und -nutzer um einiges schwerer.

Nachfragen wegen nicht funktionierender Addons sind da vorprogrammiert, die eigentlich unnötig wären wenn die Setmacher etwas mehr Umsicht walten lassen würden. Denn bei fast allen Addons steht nicht expliziet dran für welches Set sie sind bzw. das sie nur bei einem bestimmten Set funktionieren.


Und komm mir jetzt nicht mit "die Ausrichtung und Grafiken sind bei uns eh anders". Das interessiert Addon-Nutzer eher weniger, weil diese Addons deswegen nutzen weil sie ihnen gefallen oder nachrüsten was sie vermissen.

Aber gut, ihr wisst ja eh alles besser und ne gute aufschlussreiche Dokumentation pflegt ihr ja auch, wo man solche Sachen dann nachlesen kann.
Was aber auch auf viele andere Setmacher zutrifft.

[The Transporter]

Manchmal sind Annahmen halt einfach nicht zutreffend.
Eine Annahme ist kein Wissen, maximal eine Vermutung.

Wo steht denn die von Dir so sehr geforderte, zwingende Kompatibilität zwischen den Grafikset niedergeschrieben?
Du willst also ein einheitliches Standard Grafikset, Individualität ist wohl verboten!!

Sollen wir jetzt verantwortlich sein, weil ein Addon Ersteller keine klaren Angaben macht??

Führst Du gerade mal wieder einen Feldzug gegen Simutrans, und besonders gegen Grafikset Ersteller die kein pak64 oder pak64.german pflegen??

Glaubst Du das Du mit solchen Äußerungen, und einem Zwang auf ein Standard Grafikset, der Simutrans Gemeinde und auch Simutrans einen Gefallen tust??

[Wurzelgnom]

hab vergessen zu erwähnen

Bei gleichen (Waren)Namen kann man im Translator auf bestehende Übersetzungen anderer Sets zugreifen und diese ggf übernehmen.

Aber was soll es, wenn man es sich schwerer machen möchte als nötig um so besser. Man hat ja sonst nichts anderes zu tun.

[prissi]

Mal zurück zu Thema. Im neusten Nightly wird das SPiel automatisch gespeichert und wieder geladen, wenn man das nicht in der SImuconf.tab abschaltet.

[The Transporter]

Dankeschön, für die Verbesserung!