Simutrans Experimental

[jonasbb]

Nur so als Idee,
könnte nicht Simutrans Experimental eine andere Endung nehmen?
Dann könnte man ein makeobj machen, was beide erstellt (z.B. .pak und .pac). Dann könnte man die auch in ein pak-Set legen ohne das es Probleme gibt.
Dann hätte man ein pak-Set und müsste keine Filter in Simutrans einbauen.

[HomerSimpson]

So, Kapitel 2 ist jetzt auch komplett online.

Fehlt noch Kapitel 3 (zum Glück ist das nicht mehr so lang).

[Rainer]

Zitat Prissi:

Simutrans experimental ist hoffnunglos daneben.

Ich verstehe Deine Argumente, Prissi. Plausibel. In Diskussionen mit James gewann ich den Eindruck, dass ihm das nicht klar ist. Hast Du eigentlich mit ihm darüber gesprochen?

Die Ideen in Experimental finde ich hochinteressant. Ich fände es schade, wenn sich beide Zweige zu weit voneinander entfernen. Experimental als das auffassen, was der Name schon aussagt, fände ich gut: Neuen Kram "in the wild" testen, ob und wie und wann er für den Hauptzweig geeignet ist.

Zitat Prissi:

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

Wenn das das Schlimmste ist, was passieren kann, halte ich das nicht für sooo tragisch. Das passiert bei Projekten gelegentlich. Sehr häufig kommt was Vernünftiges dabei raus - in welchem Zweig auch immer.

[prissi]

Die Frage ist, ob das lange genug überlebt. Und die zweite Frage, ob es nicht Leute abschreckt. Nämlich die 50% der Anfragen, die Simutrans als zu kompliziert empfinden und zum (mittlerweile komplizierteren imho) OpenTTD wechseln ...

Außerdem wäre das eine oder andere Feature zu ende entwickelt vielleicht auch für den Trunk brauchbar. Nur so wie James das macht, kann man das gleich Neuprogrammieren. Außerdem ist viel Schweiß in das Austarieren, Optimieren und Debuggen reingeflossen, sodass ich da sehr zögerlich bin, was komplette Umbauten angeht. Die müssen dann mindestens genausogut wie das Original sein.

[Hajo]

Original von prissi
Die Frage ist, ob das lange genug überlebt. Und die zweite Frage, ob es nicht Leute abschreckt.

Im int. Forum besteht reges interesse, scheint mir. Jemand hat eine Mac OS X version compiliert, jemand hat offiziell im "Praises" thread über STE geposted, und es wird fleissig der Code geprüft und Schwächen/Fehler aufgezeigt.

Wenn James nicht aufgibt, oder der Code hoffungslos verwurstelt ist, dann sieht das für mich eher nach einer Erfolgsstory aus.

[whoami]

Im Internationalen Forum wurde schon viel hinter verschlossenen Türen über diese Angelegenheit diskutiert, aber hat wirklich jemand James deutlich auf den ganzen Problemkomplex angesprochen? Vielleicht ist es gar nicht seine Absicht, eine Abspaltung zu verursachen.

Man kann in der Tat sagen, dass ST für Einsteiger ziemlich kompliziert ist (allein schon Signale, Elektrifizierung, Aktivierung von Warenkategorien). Zusätzliche Hindernisse in STE wie Gewichtsbegrenzung, Lademaßüberschreitung, unterschiedliche, inkompatible Elektrifizierungstypen etc. bereiten mehr Arbeit/Probleme, aber ob der Spielspaß dadurch gewinnt...
OpenTTD hingegen ist nicht kompliziert - ich habe vor kurzem mal wieder reingeschaut: nach der üblichen Durststrecke am Anfang werden schon ein paar Punkt-zu-Punkt-Verbindungen mit Fahrgästen und der Spieler dadurch mit Geld überschwemmt.

Ich bin allerdings für Änderungen in ST, die den Realismus fördern, ohne dass man sich um noch mehr Kleinigkeiten kümmern muss (Balancierung und Ressourcenbedarf müssen natürlich auch noch stimmen). Dazu gehören Fahrzeugphysik und QoS.

[prissi]

Bei OPenTTD klappt unter jedem 2. Button mittlerweile ein Drop down menü auf, wenn man den längern hält. Aber bevor es Offtopic wird: Natürlich wurde das diskutiert im Rahmen der "Abspaltung". Für manche Features gibt es ja auch Patches. Ich denke, das James durchaus kooperativ wäre, ein must-have "zurückzuportieren".

[HomerSimpson]

An alle, die Übersetzung ist jetzt komplett.

Ich denke, ich habe die Essenz von James' Beitrag einigermaßen wiedergegeben (wenn es nach eurer Meinung schwere Fehler gibt, bitte melden). Ich hoffe, auch die nicht so Englisch-Mächtigen verstehen jetzt besser, was James so alles vorhat.

Ob das alles sinnvoll sein mag und vor allem, ob es einfach und ohne allzuviel Overhead (vor allem Rechenoverhead) zu integrieren ist, dazu kann ich nichts beitragen. Ich habe keine Ahnung vom Sourcecode, ich spiele das Spiel nur gerne.

Interessant finde ich so Ideen wie "Kurvenfahrten" und "Steigungen" - ganz ehrlich, meine persönliche Meinung: die Fahrzeuge werden aktuell in den Kurven viel zu sehr ausgebremst. Gerade weil man ja durch die Feldbasierung nur 45°/90° Kurven bauen kann. Die Idee mit den Neigetechnik-Zügen finde ich auch lustig, aber ich traue mich nicht zu bewerten, ob so was einfach einzuführen wäre.

Nett ist auch die Idee mit den Wegbeschränkungen. Wenn sich sowas in Simutrans einbauen lässt, dann ergeben sich wohl völlig neue Möglichkeiten bei der Fahrzeugerstellung. Das hört sich für mich so an, als ob dann z.B. 2-gleisige Straßenbahnen möglich sind, etc. etc. etc.
Der Code muss es natürlich hergeben.

Die Dampflokphysik finde ich dagegen stark übertrieben, das hört sich nach mehr Aufwand im Programm an, als was es am Ende wohl bringt.

Was prissi natürlich so alles erzählt, das hört sich nicht so erbauend an. Eigentlich schade, da ist jemand mit wohl großem Eifer und Ehrgeiz, der jedoch sein eigenes Süppchen kocht. ?(

[whoami]

Original von HomerSimpson
An alle, die Übersetzung ist jetzt komplett.

Alle Achtung, Du übersetzt schneller als James das Forum mit Text flutet.

was James so alles vorhat.

Vieles davon (womöglich alles!?) ist schon eingebaut. Ob die jeweilige Änderung aber funktioniert, weiß ich nicht (vielleicht nicht mal der Ersteller selbst).

die Fahrzeuge werden aktuell in den Kurven viel zu sehr ausgebremst. Gerade weil man ja durch die Feldbasierung nur 45°/90° Kurven bauen kann.

Das stimmt. Sogar Haarnadelkurven lohnen sich für Züge. Das Problem ist hier wohl die Implementierung, insbesondere das (performante) Erkennen des Kurvenverlaufs über viele Kacheln hinweg.

Die Idee mit den Neigetechnik-Zügen finde ich auch lustig, aber ich traue mich nicht zu bewerten, ob so was einfach einzuführen wäre.

Technisch wohl nicht so schwierig, es wurde aus anderen Gründen nicht in ST aufgenommen (siehe hier).

Nett ist auch die Idee mit den Wegbeschränkungen. Wenn sich sowas in Simutrans einbauen lässt, dann ergeben sich wohl völlig neue Möglichkeiten bei der Fahrzeugerstellung.

So wie ich verstanden habe, wird es eher komplizierter, den passenden Zug für eine Strecke zusammenzustellen, sofern die Paks entsprechend eingestellt sind, weil alle möglichen Beschränkungen beachtet werden müssen (schon oben genannt: Gewichtsbegrenzung, Lademaßüberschreitung, unterschiedliche, inkompatible Elektrifizierungstypen; beliebige weitere kann man sich auch noch ausdenken).

Das hört sich für mich so an, als ob dann z.B. 2-gleisige Straßenbahnen möglich sind

Das ist etwas ganz anderes, und viel schwieriger. Zweigleisige Trams gibt es (unabhängig von STE) derzeit per Simulation mittels Straßenfahrzeugen.

[HomerSimpson]

Original von whoami
Alle Achtung, Du übersetzt schneller als James das Forum mit Text flutet.

Danke für das Lob. Immerhin hat es jetzt eine Woche gebraucht, den Text ins Deutsche zu bringen.

die Fahrzeuge werden aktuell in den Kurven viel zu sehr ausgebremst. Gerade weil man ja durch die Feldbasierung nur 45°/90° Kurven bauen kann.

Das stimmt. Sogar Haarnadelkurven lohnen sich für Züge. Das Problem ist hier wohl die Implementierung, insbesondere das (performante) Erkennen des Kurvenverlaufs über viele Kacheln hinweg.

Ich wollte eigentlich nur mal darüber "klagen", dass aus meiner Sicht der Reibungfaktor für Kurven generell sehr hoch ist. Mag damit zusammenhängen, dass ich auch noch die 0.80x Zeiten kenne, in denen die Züge nur so um alle Kurven und über alle Hügel flizten.