Kachel-Reorganisation

[Peter Dobrovka]

Ich bin ja immer noch hinter einer ganz bestimmten Sache her und möchte anfragen, ob Interesse / Bedarf besteht, das mal anzugehen. Ich wäre auch bereit, mitzuhelfen.

Die Rede ist von der Reorganisation der basalen Kachelstruktur.

Was es damit auf sich hat:
Zur Zeit ist es so, daß ein Straßenfeld zwei Fahrstreifen besitzt, während ein Schienenfeld nur eines. Das führt dazu, daß Doppelgleise breiter sind als eine Straße und zu diversen Schwierigkeiten beim Coden lang ersehnter Features wie Einbahnstraßen, mehrspurigen Straßen, Autobahnen, Straßenbahnen etc. All das ist inzwischen zwar implementiert, aber irgendwie nicht richtig. Auf den Autobahnen kann nicht überholt werden, Straßenbahnschienen gibt es nur eine in der Mitte, usw.
Es spräche einiges dafür, der Straße wie der Eisenbahn ein Feld pro Fahrtrichtung zuzugestehen. Dadurch wären im Nu ein Haufen hochinteressanter Features verfügbar: 4- oder gar 6-spurige Alleen und schmale Gassen, und natürlich: 2-spurige Straßenbahnen auf einer 4-Feld-breiten Straße.

Was das Coding angeht, so ist ein nicht gerade unerwünschter Nebeneffekt, daß viele Dinge EINFACHER werden.

[prissi]

Das müsste dann aber vermutlich mit einer Verkleinerung der Basiskacheln auf 32x32 einhergehen, sonst würde eine ganz normale Straße zwei Gebäudekilometer breit werden.

Die Straßen sind ja intern auch nicht zweispurig, sondern genauso einspurig wie die Schienen. Einfacher wäre m.E. das Überholen zu implementieren.

Intern wären Einbahnstraßen ja kein Problem. Das größte Problem wäre vermutlich, beim Bau trotzdem ein 64er Raster beizubehalten auch wenn intern ein 32er Raster verwendet wird, denn diverse Programmteile, nicht zuletzt der Stadtcode, kommen nur mit Gebäuden klar, die nur eine Kachel umfassen.

Meine persönliche Schätzung wäre das ein drei Monats- bei ein Halbjahresprojekt. Es könnte durchaus auch bei anderen Sachen helfen, z.B. bei den Steigungen, da könnte ich mir etwas vorstellen.

Nur ich persönlich werde das nicht angehen, da schrecke ich davor zurück. Verglichen mit den Tramschienen oder den Flughäfen ist das eine richtig große Sache, wo mir persönlich auch noch die Motivation fehlt.

[gpmfuchs]

zu den Steigungen. Ich weis nicht ob es das ist was du dir vorstellst, aber ich fände z.b. bei Eisenbahnen (zusätzlich) Steigungen über 2 oder mehr Felder realistischer (die entsprechend weniger auf die Geschwindigkeit einwirken). Vielleicht in form einer speziellen langsamanstiegs Brücke? (Oder mit halbhohen slopes wobei sich das nach mehr Aufwand anhört, nur damit man noch realistischere Gleiskreuzungen bauen kann in der das eine Gleis steigt und das andere fällt)

Irgendwie höhenungleiche Gleiskreuzungen von nebeneinander liegenden Gleisen ermöglichen.

sowas in der art:
-------+
-------|------ 1
........+----- 2

geht leider im moment nur wenn man gleis 1 anhebt, was aber meist das Durchgangsgleis ist, und die Loks ziemlich bremst. falls man Gleis 2 anheben will braucht man im moment nicht 3 sondern 5 felder. wofür im Grossbahnhofsvorplatz meist kein Platz ist.

[blackbox]

von Peter
Ich bin ja immer noch hinter einer ganz bestimmten Sache her und möchte anfragen, ob Interesse / Bedarf besteht, das mal anzugehen. Ich wäre auch bereit, mitzuhelfen.

Und ob da Interesse / Bedarf besteht. Meinen Segen hast du dafür. Solch ein Doppelgespann an erfahrenen Programmierern für Simutrans zu haben, wäre ja besser als Weihnachten und Ostern zusammen.

Hatte mir vor ein paar Monaten auch schon mal grafisch ein paar Gedanken dazu gemacht, die Kacheln nochmals zu unterteilen, um eben eine bessere Verkehrswegeführung zu ermöglichen. Da dann aber die Karten auch intern 4 mal so groß werden würden (Speicherverbrauch), habe ich die Thematik ersteinmal wieder auf Eis gelegt.
Oder kann man das programmtechnisch auch effektiver bauen? Ist das von Peter überhaupt so angedacht, oder schweben dir da andere Lösungen vor?

[prissi]

Man könnte jedem weg_t statt einem zwei Ribis und einen jeweiligen Offset geben. Damit würden Straßen wie bisher gehen und Gleise automatisch zweigleisig werden. Ein Problem sind dann leider die Kurven, für die mir adhoc auch keine gute Lösung einfällt.

[Gotthardlok]

Hab mir über zweigleisige Strecken auch schon den Kopf zerbrochen; meine Lösung wären "Unterkacheln", d.h. ein Feld wird beim Wegbau in 4, 9, oder gar 25 Unterkacheln aufgeteilt, auf denen dann die Schienen verlegt werden, wobei es für ein- und zwiegleisige Strecken zwei verschiedene Baumenus gibt.

Ach ja, noch etwas: Bitte nehmt auf Rückwärtskompatibilität keine Rücksicht, wenn damit bessere Lösungen möglich werden.

[prissi]

Die "Rückwärtskompatibilität" entsteht vor allem dadurch, dass der Rest vom Programm noch funktionieren muss. Sonst könnte man die Kacheln ganz weglassen und das Programm umschreiben mit Vektorwegen und -Städten und keinen Kacheln mehr, so wie es Peter in 3DTTT gelöst hat. (Das wäre vermutlich auch der beste Weg, Simutrans 3D tauglich zu machen.)

[Peter Dobrovka]

> Die Straßen sind ja intern auch nicht zweispurig, sondern genauso
> einspurig wie die Schienen

Wie darf man das verstehen? Die Straßen HABEN doch zwei Richtungen.
In 3DTT ist es übrigens so, daß auch Schienen zweispurig sind wie die Straßen, nur daß beide Richtungen auf denselben Ortskoordinaten liegen.

Also, mein Ansatz sieht so aus:
Keine Unterteilung in Unterfelder, sondern schlicht und ergreifend: 1x1 Feld = ein Straßenfeld = eine Richtung. Also wie Schienen. Die kleinste mögliche Straße wäre damit 1 Feld breit und besäße nur eine Fahrtrichtung. Eine zweispurige Straße mit Bürgersteig beidseits wäre sogar 4 Felder breit. Eine vierspurige Straße mit baumbestandenem Mittelstreifen oder eine Autobahn besäße sogar eine sagenhafte Breite von 7 Feldern.
Wie so etwas aussieht, sehen wir sehr schön bei "Der Verkehrsgigant". Und genau darauf will ich hinaus.

Die Karten würden dadurch feldanzahlmäßig tatsächlich größer, aber bei der Gelegenheit wäre gleich zu prüfen, ob da nicht eine drastische Optimierbarkeit möglich ist; meiner Ansicht nach ist das mit Sicherheit der Fall, ich hatte ja mal einen sehr kurzen Einblick in die Datenstruktur vor einigen Jahren.

Das wäre in der Tat ein "Umbau von unten", der etliche Abhängigkeiten umstrukturieren würde, die davon ausgehen, daß die Datenstruktur so ist, wie sie ist, aber ich bin solche Aktionen gewohnt. Wenn man genau weiß, was man will, geht das schneller als man denkt. Und ihr habt ja - Hajo sei dank - schön brav objektorientiert programmiert.

Peter

[Peter Dobrovka]

Original von prissi
Die "Rückwärtskompatibilität" entsteht vor allem dadurch, dass der Rest vom Programm noch funktionieren muss. Sonst könnte man die Kacheln ganz weglassen und das Programm umschreiben mit Vektorwegen und -Städten und keinen Kacheln mehr, so wie es Peter in 3DTTT gelöst hat. (Das wäre vermutlich auch der beste Weg, Simutrans 3D tauglich zu machen.)

In der Tat, wollte man das Gelände vektorbasiert machen, würde nichts vom alten Code übrig bleiben.
Aber kacheliges 3D sieht auch ganz nett aus. Ich denke da zum Beispiel an CIV4.
Nur: Wer soll die Modelle bauen. Das ist eine Arbeit, die ist dermaßen exorbitant ...

Peter

[Hajo]

Prissis Idee, die Kacheln and sich so zu lassen wie sie sind, aber eine Kachel in 2x2 Wege einzuteilen, scheint die einfachste Möglichkeit zu sein echte Doppelgleise und auch echte zweispurige Strassen zu implementieren.

Auch was den Speicherverbrauch angeht, ist diese Lösung schlanker als alle Kacheln komplett zu 4teln. Ebenso können dann die Routinen für Haus- und Industriebau unverändert bleiben. Immerhin funktionieren diese Routinen gut und Fehlerfrei, es wäre schade dort neue Fehler einzubauen durch eine Änderung die nicht unbedingt notwendig ist.