Simutrans Experimental

[sojo]

Prissi, danke für die klaren Worte.

Dann betrachte ich für mich SE (Simutrans Experimental) als Spielwiese um neue Konzepte auszuprobieren. Wenn dann eine gute Idee dabei ist kann diese vielleicht in Simutrans programmiert werden.

[Hajo]

Original von prissi
Simutrans experimental ist hoffnunglos daneben.

...

Nein, ich fürchte, das ist eine Abspaltung.

Das mit der Abspaltung sehe ich genauso wie Prissi. Ich hatte eine solche Abspaltung im int. Forum befürwortet, da es mir besser erscheint, die "esoterischen" Features, die immer wieder gefordert werden in einer eigenen Entwicklungslinie zu haben. Auch um den Druck auf Simutrans Classic zu lindern, solche Features einzubauen, und Prissi und den anderen Entwicklern mehr Luft zu geben, um an den Kernthemen zu arbeiten und diese zu verbessern.

Dass James' Programmierstil und Vorgehensweise eher hemdsärmerlig sind war zu befürchten. Allerding kann er sich immer noch am Riemen reissen und das ganze verbessern. Ich kenne aus einem anderen Projekt so einen Fall der als riesiger Hack begann, später aber eine starke eigenständige Variante wurde. Vielleicht schafft James das auch. Zumindest hatte ich das gehofft, und hoffe es noch immer.

Interesse für Simutrans Experimental ist vorhanden, es liegt an ihm etwas daraus zu machen.

[sojo]

James scheint ja auch sehr motiviert zu sein.

Original von Hajo
Interesse für Simutrans Experimental ist vorhanden, es liegt an ihm etwas daraus zu machen.

Ich hoffe nur das beachtet wird das Paksets in Zukunft in beiden Varianten von Simutrans laufen.

[HomerSimpson]

Es geht langsam voran, es sind wieder ein paar neue Abschnitte übersetzt.

Original von sojo
Ich hoffe nur das beachtet wird das Paksets in Zukunft in beiden Varianten von Simutrans laufen.

Ich fürchte, das wird schwierig. So einiges, was James macht, muss in den Paksets codiert werden...

[whoami]

Original von HomerSimpson
Ich fürchte, das wird schwierig. So einiges, was James macht, muss in den Paksets codiert werden...

Unbekannte Parameter sollten ignoriert werden, damit die Dateien immer noch in beiden Zweigen laufen, aber das .pak-Format muss gleich bleiben. Die Parameter sollten allerdings in getrennten Namensräumen liegen, damit man nicht nur Konflikte ausschließt, sondern auch in der .dat direkt sehen kann, wozu der jeweilige Parameter gehört. Also: makeobj sollte die Parameter beider Zweige verstehen und einbauen, aber ob sie beachtet werden, liegt am ST-Kern selbst.

Die Balancierung kann natürlich verlorengehen, nur im Extremfall dürfte das Objekt in einem Zweig nutzlos werden.

[Hajo]

Original von whoami
Also: makeobj sollte die Parameter beider Zweige verstehen und einbauen, aber ob sie beachtet werden, liegt am ST-Kern selbst.

Das lässt sich sicher machen. Vielleicht sollte man ein Präfix für die Parameter von Simutrabns Experimental definieren, wie "ste_<parametername>" dann hat man auch gleich den Namensraum.

[Wurzelgnom]

Warum was im Programm abfangen?

Man erstellt 2 Setversionen aus den gleichen Dat-Dateien mit dem jeweiligen Makeobj.

Da Makeobj unbekannte Parameter einfach ignoriert, ist das die sauberste Lösung, da jede Simutrans-Version ihre passenden pak-Dateien bekommt.

Problematisch wirds nur dann, wenn vorhandene Parameter abgeändert werden.

[whoami]

Original von FrankP
Man erstellt 2 Setversionen aus den gleichen Dat-Dateien mit dem jeweiligen Makeobj.

Das war doch gerade der Witz: es sollte möglichst nur ein Pak-set geben, mit Parametern für beide ST-Zweige darin. Bei den allermeisten Objekten sind die entsprechenden Auswirkungen auch gering.

[Wurzelgnom]

Was mehr Probleme als Nutzen bringt.

Wie soll dann noch rausgefunden werden, was Fehler verursacht?

[whoami]

Solange beide ST-Zweige beim Laden der Pak-Datei jeweils einen wohldefinierten Satz an Parametern erhalten, sehe ich kein Problem (die beiden Programme verhalten sich sowieso völlig unterschiedlich). Separate Pak-Formate und -Dateien vertiefen die (Ab-)Spaltung eher. Ich kann mir auch nicht vorstellen, dass die Anzahl der Pak-Auslieferungen mal eben verdoppelt würde, um ST-Exp zu versorgen.

Problematisch wird es natürlich dann, sobald der gute James auch an Fahrzeuglängen, Bilderadressierung (z.B. mehr Fahrzeugansichten für Kurven und Hänge) und Constraints schraubt.