Beiträge von Rutel

Vielleicht ist das Problem für die meisten zu einfach.

Wenn Du auf einen einmal gesetzten Standard-UG-Bahnhof klickst, kannst Du ihn ziemlich frei umbauen (Konfigurieren), nämlich Bahnsteige, Gleise und Gebäude stückweise abreißen und hinzufügen. Die Länge der Stücke ist ziemlich einheitlich 40 m, die Breite hängt vom Stück ab.

Es gibt mindestens eine Mod, die ein ähnliches System anbietet; die meisten Bahnhöfe nach Vorbildern lassen sich wenigstens teilweise konfigurieren; auch mit Durchgangsgleisen.

Karten aus TpF1 importieren ist wahrscheinlich nicht viel einfacher als Neubauen. Im Lexikon gibt es den Artikel Kartengrößen in TpF2. Da kannst Du nachlesen, was Du überhaupt erwarten kannst; die Bedingungen sind etwas anders als in TpF. Auf einer sehr großen Karte wäre es im Maßstab 1:2 realisierbar; wenn Du eine größenwahnsinnige Karte hast, auch ungefähr 1:1,5. Wenn Du keinen extrem guten Rechner hast, ist diese Karte aber auch so wie sie heißt.

In meiner Mainz-Wiesbaden-Karte habe ich eine Anleitung, wie Du Dir eine Karte aus Höhendaten erstellst; Zeitaufwand vermutlich irgendwas zwischen 2 Stunden und 1 Tag nur für die Höhenkarte (hängt sehr davon ab, wie gut Du Dich mit den verschiedenen Dingen auskennst). Wenn Du auch noch das Satellitenbild haben willst, geht der Aufwand eher zu 1 Tag, wenn alles ziemlich glatt läuft. Will sagen: Ich habe einschließlich Anleitungen-aus-dem-Internet-Picken-und-Software-Suchen dafür viel länger gebraucht.

Diese Auswahl ist mit dem vorletzten Update neu dazugekommen. Die geraden Straßen sind wahrscheinlich Default geworden, damit auch jeder über das neue Feature stolpert.

web-owl: Bei mir sehen die Varianten aus wie im Bild. Hast Du den richtigen Schalter betätigt? Es is die obere "Gangway floor"-Auswahl (die untere ist nur für die Übergänge, weil die manchmal in Warnfarbe gestrichen sind - die Namensgleichheit ist noch so ein Fehler). Hast Du nach TpF2 konvertiert? Das Flußufer und das Gras sieht verdächtig aus ... Das würde auch erklären, warum er die von mir nur per Referenz geholte Textur für den Bereich hinter der Mauer nicht findet und die Mauer selbst so anders aussieht. Ich habe die Mod jedenfalls erst mal für TpF1 gebaut, weil ich schon vor Erscheinen von TpF2 angefangen habe.

Mit der Haltestelle habe ich eigentlich kein Problem. Es kann aber sein, daß (in TpF1) der Ponton so weit in den Fluß ragt, daß er ihn komplett sperrt (es ist die einzige Möglichkeit, zu verhindern, daß Schiffe anderer Linien durch den Ponton hindurch fahren, zumindest in den meisten Fällen). Das kannst Du sehen, wenn Du Dir die schiffbaren Gewässer anzeigen läßt. Die Anpassung an TpF2 ist für mich noch in etwas fernerer Zukunft.

MaikC : Die Rosttexturen schaue ich mir mal an. Die Mauertextur habe ich von UG per Referenz, und sie ist schon kachelbar. Die fehlenden Widerlager fallen auf, also bringe ich sie noch 'rein. Ich hatte gedacht, daß man sie weglassen kann, weil sie in den meisten Fällen verdeckt sind .

web-owl : Du hast die Auswahl zwischen hell, dunkel und Stahl - in den Bildern habe ich nur hell. Wenn die Auswahl "dunkel" auch noch blendend weiß ist, müssen wir tiefer nachschauen - ich hatte das Problem nicht. (Kuriosität am Rande: Das Original war die helle Variante - ein dunkle Platte, die ich im prallen Sonnenlicht aufgenommen hatte ...)

MaikC : Die Mauern müßten selbst für die steilste Variante hoch/tief genug sein. Ich kann aber noch mal zwei Meter dranpappen. Das zweite Bild zeigt eher einen Fehler im Schattenwurf. Woher der kommt? Keine Ahnung. Für Tips bin ich dankbar.

Ich hatte mich nach einigen Pontons in Mainz gerichtet. Davon war einer ziemlich angerostet. Deshalb habe ich das als eine Variante aufgenommen. Mit 2k natte ich experimentiert, aber gerade in der rostigen Variante fielen die Pixel sehr deutlich auf. Die doppelten Texturen und die krummen Abmessungen sind mir bekannt und gehören zu den Gründen, warum das noch Version 0 ist.

Seit fast einem Jahr bastele ich an Anlegern, die zumindest an den Städten am Rheinufer zu finden sind - irgendwie sieht es laut Bilder-Google an anderen Flüssen oft anders aus. Ich bin jetzt soweit, daß ich eine Art Alphaversion zum Testen in die Runde werfen kann (so die Moderatoren wollen, in der Webdisk - als Anhang ist das zip-Archiv definitiv zu groß). Bitte verwendet die Mod noch nicht in ernsthaften Projekten - ich möchte noch die Freiheit für Umbenennungen, Strukturänderungen etc. erhalten, bis ich das Gefühl habe, daß die Mod gar ist.

Ich plane noch einige Arbeiten, die aber zum Teil für die Tonne sind, wenn ich sie zu früh anstelle:

- Lokalisation des Interfaces (Das Aussehen ist wohl zu Rhein-zentriert, um wirklich nicht-deutsche Ingame-Beschriftungen anzubieten und irgendwie finde ich sogar weder für Basel noch Straßburg etwas ähnliches, und selbst die Anleger an anderen deutschen Flüssen sehen meistens anders aus)

- Erdaushub am Ufer verbessern

- Ausrichtung der Passagiere (ich fürchte aber, das führt zu mehreren neuen Dateien)

- Ankerpunkt ans Ufer macht die Bedienung wahrscheinlich einfacher

- Texturen nach .dds

- Doppelte Texturen vereinen

- LoD-Tiefen optimieren. Ich habe sie im Moment so gewählt, daß ich die Sprünge sehe. Das ist natürlich für eine Endfassung genau nicht Sinn der Sache

- Kleinigkeiten

- Vorschaubild

- Alternativ als funktionsloses Asset

- Konvertierung für TpF2. Mal sehen, was sich da zusätzlich konfigurieren läßt.

Einen Soundset habe ich nicht vor. Ich möchte auch nicht den von UG einbinden, es gibt praktisch keine Durchsagen an diesen Anlegern (und erst recht nicht, wenn kein Schiff da ist)

Dann zu meinen Fragen / Räteseln / Unsicherheiten:

* Einige Gegenstände werfen Schatten, andere nicht. Woran kann das liegen? Die Brüstungen der Brücke, der Boden der Brücke, der Ponton und der rote Kasten sind jeweils eigene .mdl. Die Wände werfen Schatten, der Kasten nicht.

*Die Schatten-Klötzchen, die von den Geländern oder vom oberen Blech der Brüstung geworfen werden: Sind die vermeidbar?

* Im Moment werden maximal sechs Passagiere auf dem Ponton angezeigt. In dem Game, das sich RL nennt, müssen die Leute am Ufer warten, und dürfen erst auf die Brücke, wenn das Schiff festgemacht hat. Wenn ich das so mache, werden die Leute aufs Schiff teleportiert. Das sieht sch... aus. Die Leute auf der Brücke warten zu lassen, scheitert wahrscheinlich am Platz und ich müßte Parameter aus der .con in die .mdl bringen. Anscheinend bietet ModUtil so etwas an, aber ich habe dafür weder einen Lizenztext noch eine Verfügbarkeitsgarantie gesehen; und so extrem Code klauen, daß ich einfach kopiere, was ich brauche, will ich auch wieder nicht (weil's zu viel ist; nicht wegen zweier Zeilen, aber ganze Routinen? ...). Hat jemand eine gute Idee?

* Irgendwie bin ich mit der Texturgestaltung nur halb zufrieden. Ich kann aber im Moment schlecht den Finger auf die Mankos legen: Betriebsblindheit + Gewöhnung + eigenes ist immer blöd + ist ja schon in zwei bis drei Iterationen besser geworden; das verdeckt zu viel. Sieht von Euch jemand Verbesserungsmöglichkeiten?

* Als gebürtiger Kölner weiß ich natürlich, welches Flußufer das richtige ist, und die Mehrheit der Mainzer, Londoner, Dresdener, Baseler, Römer, Yorker, Augsburger, Münchener und New Yorker wird zustimmen (auch wenn ich auf die letzten beiden keinen so großen Wert lege, selbst wenn ich mal zu vorletzteren gehört habe); bei den Lyonern trifft das nur auf einen der Flüsse zu, daher sind die Wurst. Daher die Bezeichnung der Flußufer (auf "Deutsch" wäre das bei mir "rischtisch" und "schäl"). Ich möchte das aber nicht als Beleidigung, sondern als Frotzelei verstanden wissen - klappt das, oder fühlt sich jemand ernsthaft auf den Schlips getreten? Mein Verständnis einer guten Frotzelei wird hoffentlich aus den fast vollständig fiktiven Unternehmen der Mod klar ...

* Die Uferbefestigung macht mir vom Prinzip her noch Sorgen. Ich möchte auf jeden Fall, daß man sie z. B. mit den Mauerstücken von JoeFried verkleiden kann - aber nicht muß. Die Breite ist den Ankerpunken der Ketten geschuldet, die ein eigenes Problem sind (zu viele Tris, aber mit wenigen geht es nicht - deswegen optional). Auch wenn es Absicht ist, sieht das insgesamt natürlich extrem unfertig aus. Eine auf 40 m gerade Uferbefestigung müßte ich aber beim Schönbau voraussetzen können. Hat jemand gute Ideen?

* Sind animierte Fahnen die Abende und Wochenenden von geschätzt zwei Monaten wert? Ich müßte den ganzen Themenkomplex "Animation" erst lernen.

P.S. Ich bin v. a. von Blender und der Nonchalance seiner Entwickler (Stichwort: 2.79, aber auch unterirdische Dokumentation des API) dermaßen genervt, daß Modden wohl nicht auf Dauer mein Hobby werden wird - ich kenne genügend produktivere Wege, meine Freizeit totzuschlagen. Aber das hier will ich durchziehen.

Danke für die Antwort. Collider kann man auch in Modellen angeben, und sie funktionieren - irgendwie. Es scheint aber alles ein bißchen merkwürdig zu funktionieren; wohl als Ergebnis der Entwicklungsgeschichte von TpF.

Einige Sachen habe ich inzwischen herausgefunden:

- boundingInfo ist für Erdarbeiten, aber auch für das Blockieren von schiffbaren Wasserflächen (diese 32x32-m²-Quadrate) zuständig.

- Mit skipCollision=true in der Konstruktion funktioniert die boundingInfo immer noch für Erdarbeiten und Blockade von schiffbaren Wasserflächen.

- Mit results.terrainAlignmentLists ist die boundingInfo nicht mehr für die Erdarbeiten, aber immer noch für die Blockade der Wasserflächen zuständig (löst mein Ketten-Problem).

- Wenn man die Höhe der boundingInfo gleich 0 hat (beide z-Koordinaten gleich; andere nicht ausprobiert), werden auch keine Erdarbeiten durchgeführt.

- Der collider dafür, ob sich das Modell/die Konstruktion mit anderen Modellen/Konstruktionen zankt (leider einschließlich der Wasseroberfläche ...).
- Wenn es keinen collider gibt, wird statt dessen die boundingInfo herangezogen.

- Auch eine punktförmige boundingInfo (bbMin = bbMax) kollidiert dann noch.

- skipCollision=True blockiert einen Collider nicht nur in den Modellen, sondern auch in der Konstruktion (wozu eigentlich?). VacuumTube kann sein "vermutlich" streichen.

- Wenn die Konstruktion einen Collider hat, werden die Collider der Modelle nicht mehr ausgewertet.

- Ein Collider kollidiert nicht mit Schiffen (und wahrscheinlich auch nicht mit anderen Fahrzeugen.

- Eine schiffbare Wasserfläche wird blockiert, wenn ihr Mittelpunkt in/unter der boundingInfo-Box liegt (d. h. die Box darf auch über dem Wasser schweben und wirkt doch). Das scheint auch die Wirkungsweise bei den Häfen von UG zu sein.

- Eine so blockierte Wasserfläche kann genau dann von Schiffen befahren werden, wenn ihr Start- oder Zielpunkt in ihr liegt. Ansonsten blockiert sie die Schiffahrt; man kann also mit einem Hafen einen Fluß sperren.

- Die Meldung "die Docks befinden sich ausserhalb von befahrbarem Gewässer" scheint nichts mit boundingInfo zu tun haben.

Um zu verhindern, daß Schiffe durch ein Gebäude im Wasser fahren, muß man also die boundingInfo ausdehnen, aber nicht so weit, daß eine Ein-Kästchen-Fahrrinne zwangsläufig blockiert wird. Ich fürchte, das bringt mich so nahe an die Lösung für die Schiffe, wie es geht. Jedenfalls hat der Schönbauer da noch etwas zu tüfteln.

Werte Gemeinde,

Bei einem Projekt, das nahe am Wasser gebaut ist (in jeder Hinsicht, bin schon fast ein Jahr dran ), suche ich noch eine elegante Methode für Kollision und Nicht-Kollision.

Ich will nicht, daß Schiffe durchfahren; also ist skipCollision=true in der .con keine Lösung.

Wenn ich boundingInfo und collider hinreichend hoch setze, bekomme ich es hin, daß es keine Kollision mit dem Wasser gibt. Ich will aber (optional) eine Kette anbieten, die teilweise im Wasser hängt. Die Kettenglieder werden so gedreht, daß ich keine, relativ zum Kettenglied feste, Position für einen collider angeben kann, die auf jeden Fall in der Luft ist.

Häßliche Lösung: Ich definiere drei oder vier verschiedene Kettenglieder; dann kann ich immer eines nehmen, bei dem der collider/boundingInfo in der Luft ist.

Gibt es eine elegante Lösung, bei der ich für eine einzelne .mdl die Kollisionsprüfung ausschalte, während sie für alle anderen .mdls noch funktioniert? Wenn ja, wie?

Zusatzfrage: Kann jemand erklären, wie boundingInfo und collider zueinander stehen? Irgendwie können beide Kollisionen verursachen. Gibt es von beiden unabhängig Kollisionen? Kollidiert die boundingInfo nur, wenn es keinen collider gibt? Wird bei fehlendem collider vom Programm einer aus der boundingInfo gebastelt?

Jein. Wenn ich es richtig verstehe, war *genau da* vorher nie ein Bahnhof. Gleise lagen wohl schon länger da. Auch die Einschränkungen, die die Krümmung erzwingen, waren vor dem Bahnhof da. In sofern ist der Bahnhof als solcher schon von Anfang an krumm geplant worden. Aber man kann sich lange und ergebnislos streiten über Frage, was man als "gewachsen" ansiehst.

Auf dieser Webseite sind eine Reihe alter Karten, auf denen man die Situation vor dem Bau sehen kann.

Stimmt leider nicht für Hamburg Hbf: In der Wikipedia ist ein Bild des Bahnhofes im Bau (endgültiger Beschluß 1899, reine Bauzeit nur von 1904 bis 1906 - das soll man heute mal nachmachen!). Da ist zwar die eigentliche Halle gerade, aber die Gleise dürften ähnlich verlaufen sein wie heute. Und die Bahnsteige außerhalb der Halle waren offensichtlich schon von Anfang an krumm. Der Bahnhof befindet sich an der Stelle der ehemaligen Festungsanlagen, wo einst ein Park war, und folgt deren Kontur. Woanders dürfte in der damals 700 000 Einwohner großen Stadt - ohne Altona, Harburg, etc! - kaum noch Platz gewesen sein.

Ehrlich gesagt: Ich würde einen Bahnhof nicht standardmäßig krumm designen. Ein gerader ist schon manchmal zu unflexibel. Ein krummer hat nach Murphys Law in mindestens 70% der Fälle das Empfangsgebäude auf der falschen Seite oder die Gleise brauchen erst mal einen Knoten, bevor sie in die richtige Richtung gehen. Wenn die Käpsele hier eine Grundlage für gebogene Bahnhöfe gebastelt haben, könnte man sich dranhängen. Oder die Leidensfähigkeit selbst aufbringen, das hinzubasteln; aber das ist ein eigenes, vollwertiges Projekt, so wie ich das einschätze. Aber für jeden, der nicht direkt Hamburg nachbauen will, ist die gerade Version besser. Und für Hamburg selbst: Kurzen Bahnhof ermöglichen, ein paar Assets für die Gleishalle ausklinken und mit JoeFried o. ä. mogeln.

Macht's Euch nicht komplizierter als nötig.

Ich habe gerade noch einmal sorgfältig eine Banane studiert: Die ist nicht so krumm.

Worauf sich dampf19 bezieht, sind die folgenden Zeilen Deiner stdout.txt:

Zitat

error: error: res/scripts/init.lua:64: creating globals by assignment is not allowed (variable was face)

Did you forget to add 'local' before your variable?

Daraus schließt man, daß Du (oder jemand anders) eine Datei init.lua im Verzeichnis res/scripts erzeugt hat oder drin herumgefummelt hat. In Zeile 64 findet sich die Variable "face", der ein Wert zugewiesen wird, ohne daß diese Variable dem System bekannt ist.

Ab da mußt Du (oder der Skriptersteller) selber weitersehen. Wenn die Variable an dieser Stelle erzeugt werden soll, muß es eine lokale Variable sein, daher der Tip, "local" vor die Variablendefinition zu setzen. Es kann auch sein, daß die Variable schon bekannt sein sollte; dann fehlt die Variablendefinition woanders. Welchen dieser beiden Möglichkeiten richtig ist, kann weder TpF2 noch ich sehen, deshalb kommt der Hinweis als Frage.

Die Zeilen darunter sind einfach bloß die Namen der Funktionen und Skripte, die aufgerufen wurden, um an die fehlerhafte Stelle zu kommen (wahrscheinlich in umgekehrter Reihenfolge, aber ich habe im Moment keine Lust das zu prüfen ).

Die Möglichkeit, alles an einer Stelle zu entladen, kann es nicht geben, so wie das Spiel aufgebaut ist. An jedem einzelnen Stück Ware hängt nämlich ein Zettel mit Bestimmungsort. Wenn jetzt das Programm irgend eine krumme Tour zum Bestimmungsort findet, kann es sein, daß die benutzt wird. Das muß nicht der einfachste Weg sein oder der von Dir vorgesehene. In TpF2 kannst Du das weitgehend unterdrücken, indem es die krummen Touren nicht gibt:

Du kannst nämlich für jede Linie an jeder Haltestelle einzeln bestimmen, was ein- und ausgeladen werden darf (beim Ausladen: was, nicht wieviel!). Indem Du das für jede Linie maßschneiderst, kannst Du dafür sorgen, daß Stahl zwar zur Maschinenfabrik hingebracht werden kann, aber von dort nicht mehr wegkommt. Dann sollte nur noch der Stahl, den Du für diese Fabrik - und eventuell für weitere Stahlverbraucher an der gleichen Linie - vorgesehen hast, in den Zug eingeladen werden.

Um nicht mißverstanden zu werden: Den konkreten Fall verhinderst Du natürlich, indem Du die Linien einschränkst, die theoretisch Stahl woandershin abtransportieren können, auch von anderen Stationen Deines Zuges (daher die Antwort von Vacuumtube).

Muß das jetzt mit N oder W anfangen? Ach egal

Nancy

Woippy

je nach Geschmack

Zum Thema effiziente Linienführung: In der Kampagne wird zwar verlangt, daß eine Brücke und ein Tunnel gebaut wird. Die Strecke muß aber zumindest nicht über die Brücke führen. Meine Strecke ging nördlich an Hamamatsu vorbei, direkt am Hang, und ich hatte das ganze Spiel über eine Soda-Brücke. Allerdings sollte der Verlauf wegen der Testfahrt schon eine gewisse Strecke an Brücken haben.

Hm. Irgendwie widerspricht sich das. Entweder nehmen die Sims den schnellsten Weg, oder nehmen es nicht übel, jahrelang auf den Zug zu warten. Irgendwie muß sich ja der schnellste Weg bestimmen. Daß sie Sims jahrelang am Bahnhof ausharren, nachdem sie sich für den scheinbar schnellsten Weg entschieden haben, würde aber wieder auf das Spiel passen (das ist die Antithese zur 20-Minuten-Regel aus TF, nach der die Reisenden 20 Minuten nach Reisebeginn wieder nach Hause gebeamt wurden - oder starben sie? So genau habe ich das nicht überprüft). In diese Entscheidung sollten langsamer Fußmarsch und Frequenz oder Rate der Linie - in denen die durchschnittliche Wartezeit der letzten Zeit enthalten ist - einfließen, aber kein plötzlicher Stau oder ein dummer Eingriff des Spielers.

Daß es die Sparfüchse nicht mehr gibt, habe ich übersehen, sorry.

Ringverkehr nur in eine Richtung ist ganz schlecht, aber zu dem schlüssigen Ergebnis bist Du sicher schon gekommen.

Wenn das klar ist, findest Du für jede Version Apostel. Es hängt von der Situation ab. Bei einer Ringlinie hast Du den Vorteil, daß sie wie eine offene Linie wirkt, wenn Du zwischen Start und Ziel den kürzeren Weg wählst, und zwar zwischen zwei beliebigen Haltestellen auf dem Ring. Das bringt es aber nicht immer: Wenn sie in einem Streckenabschnitt kaum benutzt wird, kannst Du sie an dieser Stelle "aufschneiden" und hin und her betreiben.

Ich kombiniere gerne beides, je nach den Gegebenheiten.

Weil ich malarke68 wahrscheinlich zunächst mißverstanden habe: Du brauchst schon eine Haltestelle direkt am Bahnhof. Der Abstand zur nächsten Haltestelle darf aber etwas größer sein: Der Anteil Pendler ist in TpF2 größer als in RL. Und für die ist es oft schneller, die letzten Meter zu laufen als auf den Bus zu warten. An einer bahnhofsnahen Haltestelle steigt praktisch nur innerstädtischer Verkehr ein oder aus. Wenn Du von Stuttgart zum Stachus in München willst, läufst Du vom Hauptbahnhof und fährst nicht eine Station mit der S-Bahn.

Die Personen werden vom Spiel einzeln simuliert und haben einen mehr oder weniger festen Ablauf:

Zu Hause - auf der Arbeit - zu Hause - beim Einkaufen - wieder von vorn.

Wenn Du gar nichts tust, suchen sie sich Arbeitsplatz und Geschäft im gleichen Ort in der Nähe, oder fahren mit Auto bzw. ab TpF2 auch Kutsche in die nächste Stadt. Du greifst in das System ein, indem Du weitere Transportmöglichkeiten zur Verfügung stellst, die möglichst attraktiver sind. Also innerhalb einer Stadt von den Wohngebieten zur Industrie und zum Geschäfteviertel (eine Buslinie, die nur Industrie mit Geschäft verbindet, bringt praktisch nichts ein - probier's aus). Oder eben auch in die benachbarten oder weiter entfernten Städte.

Dabei suchen sich die Sims je nach Geschmack die schnellste oder billigste Variante. Also mußt Du das bedienen. Lange Laufstrecken beim Umsteigen wirken sich aber wohl ähnlich demotivierend wie Wartezeiten aus und sind daher zu vermeiden. Bei einem gut vernetzten Spiel ist es meist so, daß die meisten Leute zum Arbeiten und Einkaufen pendeln. Es sollte also praktisch jede Linie am Bahnhof halten, der dann auch innerstädtischer Umsteigepunkt wird.

Eine gute Linie bedient also in beliebiger Reihenfolge

- Wohngebiet

- Bahnhof

- mindestens ein anderes Gebiet (Industrie, Geschäfte)

ohne große Umwege.

Ganz Deutschland nachzubauen wird viele Limit sprengen, auch wenn Du Dich nur auf die Schienennetze beschränkst:

- TpF(2) simuliert einzelne Leute und verschluckt sich da schon bei einigen zigtausend.

- Das Spiel ist jetzt schon ziemlich nah an den Hardwaregrenzen; die experimentellen Modi sind praktisch noch unspielbar (sowohl Prozessor als als auch Graphikkarte)

- Du brauchst ein Vielfaches des Speicherplatzes: "Größenwahnsinnig" ist 25% größer als Köln. Die Fläche, die Dir vorschwebt, ist 1000-mal größer als Köln

- Du sprengst 32-bit Floats (ich gehe davon aus, daß die Graphik mit diesen arbeitet). Bei einer Mantisse von 23 bit und 1 cm Auflösung kommst Du auf ungefähr 800 km. Mit drei Bit für Rundungsfehler auf 100 km. D. h. an den Rändern wird die Graphik ungenau, wenn man nicht speziell auf dieses Problem hin programmiert.

- Du wirst wahrscheinlich mehr als den Rest Deines Lebens zu tun haben, egal, wie alt Du bist. Das wäre was für Multiplayer, und den Modus gibt's nicht.

Um nicht ganz negativ zu sein: Versuche es mit Kartenformat 3x1 größenwahnsinnig (experimenteller Modus). Wenn Du die Karte leicht in Nordwest/Südostrichtung drehst, bekommst Du größere Teile von Köln und Düsseldorf drauf. Da sind wenigstens 2 bzw. 3 (mit Köln-Deutz) ICE-Halte drauf. Düsseldorf und Duisburg oder ein Ausschnitt des Ruhrgebiets ist da vielleicht noch bequemer.

Etwas verstehen kann ich es: Es ist einfach nervig, daß TGV/ICE nicht auf Touren kommen, weil sie gleich wieder halten, daß die Flugzeuge in den Sinkflug gehen müssen, bevor der Steigflug angefangen hat, und daß die Gleisanlagen von Stadt B schon in Stadt A beginnen. Letztes Problem hatten aber bisher alle Eisenbahnspiele (wenn sie nicht zu primitiv für Gleisanlagen waren).

Du kannst mit Signalen die Züge auf Abstand halten, mindestens so, daß sie sich nicht gegenseitig überholen. Dazu hast Du an (wenigstens) einer Stelle im Kreislauf den Abstand zweier Signale ein bißchen kürzer als die Strecke, die ein Zug in der Zeit zwischen zwei Ankünften anderer Züge in einem Bahnhof fährt (das ist die Zeit, die UG als Frequenz bezeichnet). Wenn die Züge in gleichmäßigem Abstand bleiben, passiert dadurch gar nichts, sie bekommen immer Grün. Wenn ein Zug aufholt, wird er an dieser Stelle angehalten und bleibt auf Abstand.

Du kannst auch einen kürzeren Mindestabstand der Züge ermöglichen, aber da es Dir auf Effektivität ankommt, keinen längeren. Es sollte mehr als eine Halteposition (Signal oder Bahnsteig) pro Zug sein, sonst steht immer etwas.

Das Problem dahinter hast Du bei allen derartigen Spielen, bei denen es keinen festen Fahrplan gibt: Solange Ladezeit oder Geschwindigkeit von der Beladung abhängen ziehen sich die Züge an. Weil der leerere Zug aufholt, werden für ihn bei der nächsten Station noch weniger Waren bereitgestellt, wodurch die Ladezeit noch kürzer oder die Geschwindigkeit noch höher wird; das verstärkt sich, je mehr sich die Züge annähern. Die Signale erzwingen Abstand.

UG hat zwar eine gewisse Kompensation eingebaut, die funktioniert in TpF1 aber nur bei Bussen und LKWs, bei Zügen sind wohl die Unterschiede zu groß.