Nachdem ich grade heute Abend im englischen Forum was zu dem Thema geschrieben habe hier ein Link dazu: http://www.tt-forums.net/viewtopic.php?f...0#p1134231

Kurz gesagt gingen mir die Höhenstufen dann aus, wenn ich in eine alpine Landschaft sowas wie realitätsnahe Bahnstrecken setzen wollte. Und zwar keine, die dann auf der obersten möglichen Höhenstufe enden (bei "richtigen" Bergen passiert das doch praktisch gesehen eh nirgends), sondern welche die vielleicht irgendein Tal raufführen, dann über einen Pass gehen, und ein anderes Tal runter. Für sowas reichten mir zumindest 15 Höhenstufen einfach nicht.

Ich spiele immer mit der selbstauferlegten Regel, eine Bahnlinie kann nur dann eine neue Höhenstufe raufgehen, wenn vorher mindestens fünf Felder flach waren. Wenn man das tut, eröffnen mehr Höhenstufen auch die Dimension, dass eben nicht alles beliebig verbindbar ist, das man auch mal knobeln muss wie man jetzt von A nach B deutlich höher kommt.

Auch gerne großräumig: Ich will Großstadt A mit B verbinden, geht die Bahnlinie jetzt besser das eine Tal rein oder das andere, wie komm ich am besten über die Gebirgskette dazwischen?

Da geht dann die Bahnlinie vielleicht ein Tal rauf, an einer Stadt vorbei, macht eine Schleife um über die nächste Talstufe zu kommen, geht dann am gegenüberliegenden Hang entlang weiter bergauf um gleich Höhe für die nächste zu gewinnen, bis sie irgendwann am Pass ankommt. Wie sieht "Höhe gewinnen" aus, wenn der Pass nur Höhe 8 hat (die umliegenden Berge haben ja auch noch eine Höhe, wenn ich aus Heightmaps generiere), die vorherige Talstufe 6, die Stadt vielleicht 3? Solche Höhenunterschiede sind jedenfalls noch keine echten Hindernisse.

Zum Implementierungsgesichtspunkt: Ich geh mal kurz die Patches durch:
- Limitierung der maximalen Brückenhöhe: Die Thematik gabs vorher nicht, spielt mit dem intelligenter-machen des Viewport-Codes zusammen.
- Viewport: Der alte Code hat einfach ein festes Fenster an Tiles neu gezeichnet, der neue ermittelt kraft der tatsächlichen Landschaft von wo im Norden bis wo im Süden neu gezeichnet werden soll (Tiles ändern ja ihre Zeichenposition je nachdem auf welcher Höhenstufe sie sind). Ob es effizienter ist, immer die Tiles für den worst case 15 Höhenstufen zusätzlich zu zeichnen, oder die Berechung durchzuführen was eigentlich gezeichnet werden muss (geht mit binärer Suche) - offen gesagt keine Ahnung, aber ich denke nicht dass das Welten sind.
- Terraformer: Da hat sich sogar die Komplexität im Informatiksinn von O(n^2) reduziert; der alten Code hat nämlich einen array mit set-Semantik betrieben, d.h. für jedes neu untersuchte Tile wurde eine Liste der Länge <bisher untersuchte Tiles> mit linearer Suche durchsucht ===> da ist der Code sogar effizienter geworden, einfach indem ich ein std::set verwendet habe. Das ganze Thema wieso der alte Code hier nicht MHL-fähig war bestand ja eh darin dass dieser Array eine fixe Länge hatte, und mit mehr Höhenstufen im worst-case auch mal mehr Tiles auf einmal angefasst werden beim Terraformen.
- ein paar Anpassungen an der Art und Weise wie Klicks auf die Smallmap verarbeitet werden, und wie gezoomt wird
- Flugzeuge müssen ihre Flughöhe dem Relief darunter anpassen, das geht aber effizient (man muss nur die Höhe des darunterliegenden Tiles abfragen, und dann entscheiden ob man steigen, auf gleicher Höhe bleiben, oder fallen soll)
- Anpassungen am Kartengenerator: Code der einmal abläuft, bei der Kartengenerierung

Das wars eigentlich im wesentlichen, der Viewport-Code war sicher der schwierigste Teil. Also, große Teile von dem Patch gingen eigentlich garnicht darum, neuen Code zu produzieren, sondern eher darum, existierenden Code auszutauschen der nicht für mehr Höhenstufen geeignet war.