Smart Calculators

Smart

Calculators

OpenTTD Frachteinnahmen-Rechner

Sehen Sie genau, was jede Lieferung in OpenTTD einbringt. Wählen Sie eine Fracht, legen Sie Entfernung und Tage unterwegs fest, und der Rechner liefert £ pro Fahrt, £ pro Kachel, £ pro Tag und die profitabelste Fracht für diese Strecke.

Einnahmen für eine Lieferung berechnen.

Bestimmt, welche Frachten im Dropdown erscheinen. Wählen Sie dasselbe Klima wie in Ihrem OpenTTD-Spielstand.

Die Fracht, die Ihr Zug, Schiff, Flugzeug oder Lkw transportiert. Jede Fracht hat ihren eigenen Zahlungssatz und ihre eigene Frischekurve.

Passagiere

Kacheln

Tage

Frachtbrief №1
Einnahmen · pro Lieferung
£3,508
100 Kacheln · 100 Passagiere · 60 Tage · Passagiere
£ pro Kachel
£35.08
Einnahmen ÷ Entfernung
£ pro Tag
£58.47
Einnahmen ÷ Tage unterwegs
Zeitfaktor
231 / 255
Fracht ist zu 90,6% frisch

So wird diese Zahl berechnet

Zeitfaktor
255 − 24 − 2·0 → 231
Halbe Entfernung
100 ÷ 2 → 50
Schritt 1 (>> 7)
50 × 231 × 100 ÷ 128 → 9.023
Mal Zahlungssatz
× 3.185
Durch 8192 teilen (>> 13)
÷ 8192
Einnahmen
£3,508
Frachtspickzettel · Gemäßigt
FrachtZahlungssatzOptimal bei EntfernungVeraltet ab
Wertsachen7.509≤ 75 Kacheln33 Perioden
Waren6.144≤ 375 Kacheln33 Perioden
Kohle5.916≤ 525 Kacheln—
Stahl5.688≤ 525 Kacheln—
Eisenerz5.120≤ 675 Kacheln—
Holz5.005≤ 1.125 Kacheln—
Getreide4.778≤ 300 Kacheln44 Perioden
Post4.550≤ 1.500 Kacheln110 Perioden
Öl4.437≤ 1.875 Kacheln—
Vieh4.322≤ 300 Kacheln22 Perioden
Passagiere3.185beliebige Entfernung24 Perioden
Formel verifiziert · OpenTTD-Quellcode

Vanilla OpenTTD 14.x und JGRPP. NewGRF-Frachtsets überschreiben die Standard-Zahlungssätze und werden noch nicht unterstützt. Die Einnahmen werden zum Basisjahr (1950) angezeigt; die Inflation in Ihrem Spielstand skaliert diese Werte proportional.

09·MAI·2026
CS2 Trade-Up-RechnerZDoom Schaden- und DPS-Rechner

OpenTTD Frachteinnahmen-Rechner. £ pro Fahrt aus Fracht, Entfernung und Tagen unterwegs.

Ein OpenTTD-Frachteinnahmen-Rechner liefert die exakten £ einer Lieferung in Vanilla 14.x oder JGRPP. Geben Sie Frachttyp, Menge, Manhattan-Kachelentfernung und Kalendertage unterwegs ein — das Werkzeug führt die ganzzahlige Formel aus economy.cpp aus und gibt das £-Ergebnis, £ pro Kachel, £ pro Tag und den Zeitfaktor (0–255) aus.

Was ist der OpenTTD-Frachteinnahmen-Rechner?

Der OpenTTD-Frachteinnahmen-Rechner ist ein Web-Werkzeug, das bei gegebenem Frachttyp, einer Menge, einer Manhattan-Kachelentfernung und den Kalendertagen, die eine Fracht in einem Fahrzeug verbracht hat, die spielinternen Pfund-Einnahmen (£) für genau diese eine Fahrt zurückgibt. Es bildet die Funktion GetTransportedGoodsIncome() aus src/economy.cpp Bit für Bit nach: die gleiche Rechtsverschiebung um 21 Stellen, die gleiche Zeitfaktor-Untergrenze bei 31 und die gleichen days1- und days2-Schwellen für jeden der 31 eindeutigen Vanilla-Frachtnamen (insgesamt 33 Zeilen — Holz und Öl haben jeweils eine separate Zeile für das subtropische Klima). Das £-Symbol ist nur die Bezeichnung der spielinternen Währung, nicht das echte britische Pfund — OpenTTD erlaubt das Umschalten auf $ oder €, aber die Formel rechnet immer in der internen £-Einheit und formatiert das Ergebnis beim Anzeigen neu.
Der Rechner deckt alle vier Klimazonen ab (gemäßigt, subarktisch, subtropisch, Spielzeugland) und filtert das Fracht-Dropdown automatisch beim Wechsel der Klimazone. Standardziel ist Vanilla OpenTTD 14.x, aber die Formel und die Zahlungssatztabelle sind byteidentisch mit JGR’s Patch Pack und mit dem klassischen Transport Tycoon Deluxe — der Frachteinnahmen-Code wurde seit der Erstveröffentlichung 1995 nicht verändert. Spieler auf Steam, GOG, der Direkt-Download-Version von openttd.org und JGRPP-Spieler sehen alle dieselben Zahlen.
Die offizielle deutsche OpenTTD-Wiki-Seite „Zahlungssätze bei Lieferung” beschreibt die Formel in Worten und nennt die vier Faktoren (Menge, Frachtwert, Entfernung, Pünktlichkeit), zeigt aber kein einziges durchgerechnetes Beispiel und keine konkrete £-Zahl. Das meistzitierte Drittanbieter-Tool, citymania.org/tools/profit, schreibt auf der eigenen Seite, dass die „Numbers may not be exactly accurate (they should be pretty close though)” — und unterstützt weder die vier Klimazonen noch einen Frachtvergleich. Dieser Rechner schließt drei Lücken, die weder die deutsche Wiki noch CityMania abdecken: eine genaue £-Zahl pro Fahrt, die sich gegen den Quellcode prüfen lässt, ein Aufschlüsselungs-Panel, das alle Zwischenwerte (Transitperioden, periodsOverDays1, periodsOverDays2, Zeitfaktor, Zähler, Verschiebung) anzeigt, sowie einen nach Zahlungssatz sortierten Frachtspickzettel mit 33 Zeilen, der auf einen Blick zeigt, welche Fracht auf welcher Streckenlänge gewinnt.

So berechnen Sie OpenTTD-Frachteinnahmen (und so macht es der Rechner)

Die Frachteinnahmen in OpenTTD bestehen aus vier Eingaben und einer ganzzahligen Formel. Der obige Rechner führt sie für Sie aus; die manuelle Version unten ist die, mit der erfahrene Spieler im NetNight2000-Blog und auf tt-ms.de eine Strecke vor dem Bau einer 200-Kachel-Hauptstrecke überschlagen.
Über das Werkzeug
1. Wählen Sie das Klima Ihres Spielstands (Gemäßigt ist die Voreinstellung — etwa 60 Prozent aller Vanilla-Saves).
2. Wählen Sie die Fracht. Das Dropdown ist auf die in diesem Klima erlaubten Frachten gefiltert (Kohle nur in Gemäßigt oder Subarktisch, Diamanten nur in Subtropisch, Spielzeuge nur in Spielzeugland, und so weiter).
3. Geben Sie die gelieferte Menge ein (Voreinstellung 100 — Passagiere, Tonnen, Säcke, Liter oder Stück, je nach Fracht).
4. Geben Sie die Manhattan-Kachelentfernung zwischen Abhol- und Zielbahnhof ein. Das ist NICHT die tatsächliche Gleislänge — es ist die diagonale Gitterentfernung, also $|xsrc - xdst| + |ysrc - ydst|$. Gleise, die sich um Berge winden, können 30 Prozent länger sein als ihre Manhattan-Entfernung.
5. Geben Sie die Kalendertage ein, die die Fracht im Fahrzeug verbracht hat (Voreinstellung 60). Langstrecken-Güterzüge zeigen routinemäßig 80 bis 200 Tage unterwegs an; Schiffe oft über 300.
Das Hauptergebnis sind die £-Einnahmen für diese eine Lieferung. Darunter zeigt der Rechner £ pro Kachel, £ pro Tag, den Zeitfaktor (von 255) und einen Frische-Prozentsatz. Das Aufschlüsselungs-Panel zeigt die Umrechnung von Kalendertagen in Transitperioden, beide periodsOverDays-Werte, den begrenzten Zeitfaktor und die finale Ganzzahldivision — dieselben sechs Zeilen, die Sie von Hand auf Papier schreiben würden.
Mit Stift und Papier
1. Rechnen Sie Kalendertage in Transitperioden um: $tp = \lfloor daystransit / 2{,}5 \rfloor$. Die Wiki betont, dass ein „Tag” auf ihrer Formel-Seite eigentlich 2,5 Spieltage sind; OpenTTD speichert die Transitzeit intern in 2,5-Tage-Einheiten, damit der bytegroße Zähler (max. 255) den gesamten Bereich einer langen Schiffsroute abdeckt.
2. Suchen Sie days1 und days2 der Fracht aus der Tabelle: Passagiere (0, 24), Kohle (7, 255), Wertsachen (1, 32) und so weiter für die 33 Vanilla-Zeilen (31 eindeutige Frachtnamen — Holz und Öl haben jeweils eine separate subtropische Zeile).
3. Berechnen Sie periodsOverDays1: $\max(tp - days1, 0)$. So viele Transitperioden hat die Fracht jenseits ihrer Früh-Verfallsschwelle verbracht.
4. Berechnen Sie periodsOverDays2: $\max(periodsOverDays1 - days2, 0)$. So viele zusätzliche Perioden jenseits der Spät-Verfallsschwelle.
5. Berechnen Sie den Zeitfaktor: $\max(255 - periodsOverDays1 - periodsOverDays2, 31)$. Die Untergrenze 31 ist die Konstante MIN_TIME_FACTOR aus economy.cpp — sie verhindert, dass abgestandene Fracht buchstäblich nichts bezahlt.
6. Wenden Sie die Einnahmenformel an: $income = \lfloor (distance \cdot timeFactor \cdot amount \cdot paymentRate) / 2\,097\,152 \rfloor$. Der Nenner $2^{21}$ entspricht der BigMulS-Verschiebung um 21 in economy.cpp.
Durchgerechnetes Wiki-Referenzbeispiel: 27 Passagiere, 100 Kacheln, 60 Kalendertage, gemäßigtes Klima. tp = 24, periodsOverDays1 = 24 − 0 = 24, periodsOverDays2 = max(24 − 24, 0) = 0, Zeitfaktor = 255 − 24 = 231, Zähler = 100 × 231 × 27 × 3185 = 1.986.484.500, Einnahmen = floor(1.986.484.500 / 2.097.152) = £947 pro Fahrt. Dieser Wert stimmt mit der spielinternen Zahlungssatz-Grafik bei 60 Tagen für Passagiere überein (innerhalb der Grafik-Quantisierung) und ist der QA-Referenzwert in der Testsuite des Rechners.

Frachteinnahmen — die ganzzahlige Formel aus economy.cpp

I=⌊D⋅T⋅A⋅P221⌋,T=max⁡ ⁣(255−max⁡(tp−d1,0)−max⁡(max⁡(tp−d1,0)−d2,0), 31),tp=⌊daystransit2,5⌋I = \left\lfloor \dfrac{D \cdot T \cdot A \cdot P}{2^{21}} \right\rfloor, \quad T = \max\!\left(255 - \max(tp - d_1, 0) - \max(\max(tp - d_1, 0) - d_2, 0),\ 31\right), \quad tp = \left\lfloor \dfrac{days_{transit}}{2{,}5} \right\rfloor
  • II = Einnahmen in spielinternen £ für eine Lieferung (die Ganzzahl, die der Rechner zurückgibt)
  • DD = Manhattan-Kachelentfernung zwischen Start- und Zielbahnhof — $|x_{src} - x_{dst}| + |y_{src} - y_{dst}|$
  • TT = Zeitfaktor (0–255), 255 = perfekt frische Fracht, Untergrenze MIN_TIME_FACTOR = 31
  • AA = Menge der gelieferten Fracht (Passagiere, Tonnen, Säcke, Liter, Stück)
  • PP = Basis-Zahlungssatz der Fracht aus der _default_cargo-Tabelle in economy.cpp — 3185 Passagiere, 5916 Kohle, 7964 subtropisches Holz (Rekord), 7509 Wertsachen (Rekord ohne Holz)
  • tptp = Transitperioden — Kalendertage geteilt durch 2,5 und abgerundet. Eine Transitperiode = 2,5 Spieltage
  • d1d_1 = days1-Schwelle der Fracht — Früh-Verfallsgrenze in Transitperioden. 0 bei Passagieren und Nahrungsmitteln, 1 bei Wertsachen, 7 bei Kohle, 25 bei Öl, 30 bei Plastik und Limonade
  • d2d_2 = days2-Schwelle der Fracht — Spät-Verfallsgrenze. 24 bei Passagieren, 32 bei Wertsachen, 40 bei Getreide, 255 bei Kohle (praktisch unbegrenzt)
Der Nenner $2^{21} = 2\,097\,152$ ist die Verschiebung `BigMulS(..., 21)` in der Funktion GetTransportedGoodsIncome() (src/economy.cpp). Die wortwörtliche Wiki-Formel verwendet zwei aufeinanderfolgende Verschiebungen (`>> 7` und dann `>> 13`); sie sind algebraisch äquivalent, weil $2^7 \cdot 2^{13} \cdot 2 = 2^{21}$ — die führende Division durch 2 in der Wiki-Form fließt in den gemeinsamen Nenner ein. Wir bilden die C++-Verschiebung in JavaScript mit einem einzigen `Math.floor(numerator / 2_097_152)` nach, weil alle Zwischenprodukte bei den Eingabe-Grenzen des Rechners (Entfernung ≤ 2048, Menge ≤ 9999, paymentRate ≤ 7964) sicher in Number.MAX_SAFE_INTEGER passen. Kein BigInt nötig, keine Off-by-One-Abweichung gegenüber der Engine.

Durchgerechnete Beispiele mit voller Aufschlüsselung

Wiki-Referenz — 27 Passagiere, 100 Kacheln, 60 Tage, gemäßigt

tp = floor(60 / 2,5) = 24. Bei Passagieren ist days1 = 0, days2 = 24, paymentRate = 3185. periodsOverDays1 = max(24 − 0, 0) = 24. periodsOverDays2 = max(24 − 24, 0) = 0. Zeitfaktor = max(255 − 24 − 0, 31) = 231. Zähler = 100 × 231 × 27 × 3185 = 1.986.484.500. Einnahmen = floor(1.986.484.500 / 2.097.152) = £947 pro Fahrt, Zeitfaktor 231/255 (90,6 % frisch), £9,47 pro Kachel, £15,78 pro Tag. Das ist der Referenzwert aus §5.5 der Rechner-Spezifikation und der QA-Abgleich gegen die spielinterne Zahlungssatz-Grafik.

Kohle-Langstrecke — 200 Tonnen, 300 Kacheln, 200 Tage, subarktisch

Bei Kohle ist days1 = 7 und days2 = 255 (praktisch unbegrenzte Haltbarkeit). tp = floor(200/2,5) = 80. periodsOverDays1 = 80 − 7 = 73. periodsOverDays2 = max(73 − 255, 0) = 0. Zeitfaktor = max(255 − 73 − 0, 31) = 182. Zähler = 300 × 182 × 200 × 5916 = 64.602.720.000. Einnahmen = floor(64.602.720.000 / 2.097.152) = £30.804 pro Fahrt, £102,68 pro Kachel, £154,02 pro Tag. Kohle zahlt 5916 Basis — nicht der höchste Satz im Spiel — aber das 7/255-Schwellenpaar bedeutet, dass ein 200 Tage unterwegs befindlicher Zug immer noch mit 71 Prozent der Geschwindigkeit frischer Fracht verdient. Genau deshalb ist Kohle auf tt-ms.de und im NetNight2000-Blog die kanonische „1949 Hauptstrecke gebaut und vergessen”-Fracht.

Wertsachen-Kurzstrecke — 50 Wertsachen, 50 Kacheln, 5 Tage, gemäßigt

Wertsachen haben den höchsten Zahlungssatz ohne Holz (£7.509) und das engste Verfallsfenster (days1 = 1, days2 = 32). tp = floor(5/2,5) = 2. periodsOverDays1 = max(2 − 1, 0) = 1. periodsOverDays2 = max(1 − 32, 0) = 0. Zeitfaktor = max(255 − 1 − 0, 31) = 254 (99,6 % frisch). Zähler = 50 × 254 × 50 × 7509 = 4.768.215.000. Einnahmen = floor(4.768.215.000 / 2.097.152) = £2.273 pro Fahrt, £45,46 pro Kachel, £454,60 pro Tag. Pro Tag ist das der höchste Ertrag im ganzen Spiel — aber nur bei kurzen Strecken. Zieht man dieselbe Fahrt auf 50 Tage, sinkt der Zeitfaktor auf 236 und die Einnahmen sinken um etwa 7 Prozent; bei 200 Tagen fällt der Zeitfaktor auf 129 (Einnahmen halbieren sich grob auf £1.154); erst nach etwa 325 Tagen erreicht der Zeitfaktor die Untergrenze 31 — wo dieselbe Fahrt nur noch £277 einbringt.

Subtropisches Holz — 100 Tonnen, 200 Kacheln, 80 Tage

Subtropisches Holz hat unauffällig den höchsten Basis-Zahlungssatz aller Vanilla-Frachten: £7.964 (gegen £5.005 bei gemäßigtem/subarktischem Holz — 59 Prozent Aufschlag für dieselbe Frachtart, nur weil das Klima anders ist). days1 = 15, days2 = 255. tp = floor(80/2,5) = 32. periodsOverDays1 = 32 − 15 = 17. periodsOverDays2 = 0. Zeitfaktor = 255 − 17 = 238. Zähler = 200 × 238 × 100 × 7964 = 37.908.640.000. Einnahmen = floor(37.908.640.000 / 2.097.152) = £18.076 pro Fahrt, £90,38 pro Kachel. Auf einem subtropischen Spielstand verdient Holz auf identischen Strecken 60 Prozent mehr als gemäßigte Holz-Sägewerkrouten. Die meisten Anfänger-Guides übersehen das, weil beide Frachten dieselbe deutsche Bezeichnung tragen. Genau deshalb enthält die 33-Zeilen-Vanilla-Tabelle Holz zweimal (und Öl zweimal): Die Einträge für gemäßigt/subarktisch und subtropisch teilen sich den Namen, transportieren aber unterschiedliche paymentRates.

Zwei Fahrten vergleichen — Kohle gegen Wertsachen auf derselben 100-Kachel-Strecke

Dieselben 100 Kacheln, dieselben 60 Tage, dieselben 100 Einheiten. Fahrt A: Kohle, paymentRate 5916, days1 = 7, days2 = 255. tp = 24, periodsOverDays1 = 17, periodsOverDays2 = 0, Zeitfaktor = 238. Kohle-Zähler = 100 × 238 × 100 × 5916 = 14.080.080.000. Kohle-Einnahmen = floor(14.080.080.000 / 2.097.152) = £6.713. Fahrt B: Wertsachen, paymentRate 7509, days1 = 1, days2 = 32. periodsOverDays1 = 23, periodsOverDays2 = 0, Zeitfaktor = 232. Wertsachen-Zähler = 100 × 232 × 100 × 7509 = 17.420.880.000. Wertsachen-Einnahmen = floor(17.420.880.000 / 2.097.152) = £8.306 (+£1.593 gegenüber Kohle). Wertsachen gewinnen pro Fahrt — aber Banken produzieren nur 1 bis 8 Wertsachen pro Monat, während ein Kohlebergwerk 100+ Tonnen liefert. Auf Monatseinnahmen schlägt Kohle Wertsachen um eine Größenordnung, es sei denn, Sie haben viele Bank-Strecken parallel.

Planungstipps für tt-ms.de-Veteranen und Steam-Neulinge

  • Kohle zahlt 5.916 Basis — nicht der höchste Satz im Spiel — aber das days1/days2-Paar (7, 255) hält sie selbst auf 2.000-Kachel-Karten nahezu auf vollem Preis. Kohle ist die Fracht, bei der Sie schlampige Gleise legen und trotzdem Gewinn machen können. Wertsachen zahlen 7.509 Basis, aber mit days1 = 1 und days2 = 32 lässt alles über 80 Kalendertage (32 Transitperioden) den Zeitfaktor in Richtung Untergrenze 31 abstürzen. Wertsachen für Strecken unter 50 Kacheln, Kohle für alles andere.
  • Entfernung ist Manhattan-Metrik in Kacheln, nicht Gleislänge. Die Einnahmenformel rechnet mit $|xsrc - xdst| + |ysrc - ydst|$ zwischen den beiden Bahnhöfen — egal, wie viele Kurven Ihre Gleise haben. Eine schlangenförmige Strecke durch die Berge verdient genauso viel £ wie eine gerade, solange die Bahnhofskoordinaten identisch sind. Das ist die häufigste Verwechslung auf tt-ms.de: Spieler glauben, dass 200 Kacheln Gleis auf einer 100-Kachel-Manhattan-Route 200 Kacheln Einnahmen einbringen. Tun sie nicht. Platzieren Sie die Bahnhöfe an den weit voneinander entfernten Enden der Industrien, um die Manhattan-Entfernung zu maximieren.
  • Ein „Tag” auf der Wiki-Seite zu Frachteinnahmen sind eigentlich 2,5 Kalendertage in Ihrem Spielstand. OpenTTD speichert die Transitzeit intern in 2,5-Tage-Einheiten, damit der bytegroße 0–255-Zähler den langen Schiff-Bereich abdeckt. Der obige Rechner akzeptiert Kalendertage (die Einheit, die das Fahrzeugfenster im Spiel anzeigt) und rechnet intern um — aber wenn Sie Werte direkt aus der Wiki-Formel ziehen, multiplizieren oder dividieren Sie selbst durch 2,5.
  • Der Zeitfaktor hat eine Untergrenze von 31, nicht null. MIN_TIME_FACTOR = 31 in src/economy.cpp bedeutet: Selbst eine Fracht, die seit Spieljahren unterwegs ist, zahlt noch etwa 31/255 ≈ 12 Prozent ihres frischen Wertes. Spieler beschweren sich manchmal „meine alte Fracht hat nichts verdient” — meist liegt das nur daran, dass die £-Zahl klein ist (1 Passagier auf einer 2.000-Kachel-Schifffahrt über 4.000 Tage ergibt floor(2000 × 31 × 1 × 3185 / 2.097.152) = £94), aber es ist nie buchstäblich £0, außer Entfernung oder Menge sind null.
  • Subtropisches Holz zahlt £7.964 Basis — der höchste Basissatz aller Vanilla-Frachten, über Wertsachen (£7.509) und nur von Limonade (£6.250) auf kurzen Strecken pro-Kachel-mäßig erreicht. Dieselbe Bezeichnung „Holz” wie auf gemäßigt (£5.005), aber 59 Prozent teurer. Bei einem subtropischen Spielstand priorisieren Sie Holz vor Waren auf jeder brauchbaren Sägewerk-Lieferstrecke. Die deutsche OpenTTD-Wiki nennt Holz im subtropischen Klima ausdrücklich als wertvollste Fracht.
  • JGR’s Patch Pack nutzt dieselbe Formel. Der Frachteinnahmen-Code in JGRPP ist byteidentisch mit Vanilla — der einzige wirtschaftliche Unterschied ist die Alterungsrate-Einstellung (Standard 100 Prozent in beiden, in JGRPP konfigurierbar). Zahlen aus diesem Rechner lassen sich 1-zu-1 in einen JGRPP-Spielstand übertragen, solange Sie economy.cargo_aging_rate nicht geändert haben. NewGRF-Frachtpakete (FIRS, ECS, YETI) überschreiben die Zahlungssatztabelle und sind nicht unterstützt; für ein NewGRF-Spielstand behandeln Sie diesen Rechner als Vanilla-Basislinie und skalieren mit dem im NewGRF-README veröffentlichten Verhältnis.
  • Die Inflation skaliert das Ergebnis proportional. Die angezeigte £-Zahl ist der Basisjahr-Wert (1950), identisch mit der Kalibrierung der spielinternen Zahlungssatz-Grafik. OpenTTDs Standard-Inflation von etwa 1,5 % pro Jahr skaliert sowohl Kosten als auch Einnahmen, sodass Ihre relativen Einnahmen gegenüber den Betriebskosten unverändert bleiben — das £ des Rechners ist nicht Ihr realer Kontostand-£ im Jahr 2050, aber das Verhältnis zwischen zwei Fahrten bleibt exakt erhalten.
  • Lesen Sie den Frachtspickzettel unter dem Rechner, bevor Sie Gleise legen. Er sortiert alle 33 Vanilla-Frachtzeilen (31 eindeutige Namen plus separate subtropische Holz- und Öl-Zeilen) nach paymentRate und markiert jede mit „optimal bei Entfernung ≤ N Kacheln” anhand der Heuristik days1 × 75 (da 30 km/h × 2,5 Tage/Periode ≈ 75 Kacheln pro Periode bei typischen Zuggeschwindigkeiten der 1950er ergibt). Frachten mit days2 = 255 erhalten die Markierung „praktisch unbegrenzt” — sie werden auf Landstrecken nie kritisch alt.

OpenTTD-Frachteinnahmen-Rechner — häufig gestellte Fragen

Wie lautet die Formel für Frachteinnahmen in OpenTTD?

Einnahmen = floor(Entfernung × Zeitfaktor × Menge × paymentRate / 2.097.152), wobei Zeitfaktor = max(255 − max(tp − days1, 0) − max(max(tp − days1, 0) − days2, 0), 31) und tp = floor(daysInTransit / 2,5). Die Konstanten 2.097.152 = 2^21, 255 = MAX_TIME_FACTOR und 31 = MIN_TIME_FACTOR stammen aus der Funktion GetTransportedGoodsIncome() in src/economy.cpp. Die Formel gilt in Vanilla 14.x, JGRPP und im klassischen Transport Tycoon Deluxe — sie hat sich seit 1995 nicht geändert.

Wie wird die Entfernung für Frachteinnahmen gemessen?

Die Entfernung ist die Manhattan-Distanz zwischen Start- und Zielbahnhof in Kacheln: $|xsrc - xdst| + |ysrc - ydst|$. Es ist NICHT die Gleislänge. Eine 200-Kachel-Gerade und ein 350-Kachel-Schlangengleis bringen die gleichen Einnahmen, wenn beide Bahnhöfe auf denselben zwei Koordinaten stehen. Platzieren Sie Bahnhöfe an den weit entfernten Enden der Industrien, um die Manhattan-Entfernung zu maximieren — ein dokumentierter Community-Trick, der keine längeren Gleise benötigt.

Warum ist ein „Tag” in der Wiki eigentlich 2,5 Tage im Spiel?

OpenTTD zählt das Frachtalter in einem ein-Byte-Zähler (0–255), der einmal pro 2,5 Kalendertage tickt. Die Wiki-Formel verwendet diese „Transitperioden” direkt; der Rechner akzeptiert die Kalendertage, die das spielinterne Fahrzeugfenster anzeigt, und teilt für Sie durch 2,5.

Was ist die beste Fracht für Geld in OpenTTD?

Nach Basis-Zahlungssatz: subtropisches Holz (£7.964), dann Wertsachen (£7.509), Limonade (£6.250), Waren/Bonbons (£6.144), Kohle (£5.916). Auf Langstrecken die beste ist Kohle — ihr days2 = 255 hält den Zeitfaktor selbst bei 1.500 Kacheln nahe am Maximum. Pro Monat (unter Berücksichtigung der Industrieproduktion) gewinnt meist Kohle, weil Kohlebergwerke 100+ Tonnen pro Monat produzieren, während Banken nur 1 bis 8 Wertsachen liefern. Nutzen Sie den Modus „Zwei Fahrten vergleichen”, um auf Ihrem Spielstand genau zu sehen, wann Wertsachen Kohle übertreffen.

Funktioniert der Rechner mit JGR’s Patch Pack?

Ja — der Frachteinnahmen-Code ist byteidentisch zwischen Vanilla OpenTTD 14.x und JGR’s Patch Pack. Der einzige wirtschaftliche Unterschied ist die Alterungsraten-Einstellung (Standard 100 Prozent in beiden, in JGRPP als economy.cargo_aging_rate freigegeben). Die 33-Zeilen-Tabelle (31 eindeutige Frachtnamen plus separates subtropisches Holz und Öl) und die Ganzzahlformel sind unverändert. Wenn Sie die Alterungsrate nicht geändert haben, übertragen sich die Zahlen aus diesem Rechner 1-zu-1 in einen JGRPP-Spielstand.

Funktioniert er mit NewGRF-Frachtpaketen wie FIRS, ECS oder YETI?

Nein. NewGRF-Frachtpakete überschreiben die Vanilla-_default_cargo-Tabelle mit ihren eigenen Werten für paymentRate, days1 und days2. Der Rechner enthält nur die Vanilla-Frachtdefinitionen (31 eindeutige Frachtnamen — 33 Zeilen, weil Holz und Öl separate subtropische Einträge haben) — auf einem FIRS-Spielstand liefert er die richtige Formel, aber die falschen Konstanten. Für einen NewGRF-Spielstand behandeln Sie die Rechnerausgabe als Vanilla-Basislinie und skalieren mit dem im NewGRF-README veröffentlichten Satzverhältnis (die meisten NewGRFs dokumentieren das).

Warum zeigt meine Fracht auf einer langen Schiffstour „£0”?

Die Untergrenze MIN_TIME_FACTOR = 31 bedeutet, dass abgestandene Fracht immer mindestens 31/255 ≈ 12 Prozent ihres frischen Satzes zahlt — das Ergebnis sollte also nicht buchstäblich null sein, außer Entfernung oder Menge sind null. Wenn Sie £0 sehen, prüfen Sie: (a) Entfernung ist nicht null (Lieferungen am selben Bahnhof zahlen nichts), (b) Menge ist nicht null und (c) paymentRate ist nicht null (manche NewGRFs setzen den Satz auf null für Frachten, die sie nicht transportiert haben wollen). Auf einer 2.000-Kachel-, 4.000-Tage-Passagierschifffahrt sind die Einnahmen klein (£94 für einen Passagier — floor(2000 × 31 × 1 × 3185 / 2.097.152)), aber nie null.

Warum geben CityMania und die spielinterne Grafik leicht unterschiedliche Zahlen?

Das CityMania-Tool (citymania.org/tools/profit) schreibt auf der eigenen Seite, dass die „Numbers may not be exactly accurate (they should be pretty close though)” — es nutzt eine Näherung und rundet Zwischenwerte. Die spielinterne Zahlungssatz-Grafik verwendet exakt dieselbe Ganzzahlformel wie dieser Rechner, quantisiert aber die y-Achse mit niedriger Auflösung, sodass der abgelesene Wert um ±5 Prozent abweichen kann. Die Zahlen dieses Rechners stimmen auf die Einheit genau mit der Engine überein, weil wir die Bit-Verschiebung exakt nachbilden. Wenn Ihr spielinternes £ um mehr als ein paar Einheiten abweicht, prüfen Sie nochmal, ob die eingegebenen Tage unterwegs dem entsprechen, was die Fracht des Fahrzeugs tatsächlich anzeigt (die spielinterne Zahl kann steigen, während die Fracht am Bahnhof wartet).

Ändert die Inflation das Ergebnis?

Der Rechner liefert den £-Wert zum Basisjahr (1950), exakt dieselbe Kalibrierung wie die spielinterne Zahlungssatz-Grafik. Die Standard-Inflation in OpenTTD (~1,5 Prozent pro Jahr) skaliert sowohl Kosten als auch Einnahmen, sodass Ihre echten Bank-Einnahmen im Jahr 2050 ungefähr das 4,4-Fache des Rechner-£ betragen — aber Ihre relativen Einnahmen (diese Fahrt vs. jene, diese Fracht vs. jene, diese Entfernung vs. jene) bleiben exakt erhalten. Der Rechner zeigt absichtlich kein jahresangepasstes £, weil die Wiki, die spielinterne Grafik und economy.cpp alle auf das Basisjahr 1950 kalibriert sind.

Wie genau ist dieser Rechner im Vergleich zum tatsächlichen Spiel?

Bit-exakt für Vanilla 14.x und JGRPP — die 40-Test-QA-Suite vergleicht jede Ausgabe mit der C++-Mathematik in src/economy.cpp. Der Rechner modelliert weder NewGRF-Frachtrückrufe (manche NewGRFs fügen über einen Cargo-Callback-Hook einen Multiplikator hinzu) noch Zubringer-Service-Ketten mit negativen Einnahmen noch Frachtalterung jenseits der 4.000-Tage-Eingabegrenze. Innerhalb dieser Grenzen ist das £-Ergebnis identisch mit dem, was die Engine bei der Entladung des Fahrzeugs auf Ihr Konto bucht.

Was ist der Unterschied zwischen days1 und days2?

days1 ist die Früh-Verfallsschwelle: wie viele Transitperioden die Fracht in einem Fahrzeug sein darf, bevor der Zeitfaktor zu sinken beginnt. days2 ist die zusätzliche Spät-Verfallsschwelle, die obendrauf kommt — jenseits von days1 + days2 sinkt der Zeitfaktor doppelt so schnell (die Formel zieht sowohl periodsOverDays1 als auch periodsOverDays2 ab). Eine Fracht mit days2 = 255 (Kohle, Öl, Eisenerz, Stahl, Holz, Kupfererz, Zucker, Spielzeuge, Plastik) erreicht auf keiner sinnvollen Strecke die Steil-Verfallszone. Passagiere (0, 24) verfallen sofort; Wertsachen (1, 32) verfallen fast genauso schnell und haben das steilste kombinierte Gefälle im Spiel.

Ist dieser Rechner kostenlos nutzbar?

Das Aufschlüsselungs-Panel und der Frachtspickzettel sind standardmäßig ausgeklappt statt zugangsbeschränkt — offen für jeden, kein Konto, keine Ratenbegrenzung, keine Werbung auf dem Rechner selbst. Jeder Zwischenwert (Transitperioden, Zeitfaktor, roher Zähler) ist ab dem ersten Rendern sichtbar.

Wie kann ich zwei Strecken nebeneinander vergleichen?

Verwenden Sie den Tab „Zwei Fahrten vergleichen” oben am Rechner. Das Klima ist gemeinsam (ein Streckenvergleich ergibt nur in einem Klima Sinn), aber Fracht, Menge, Entfernung und Tage unterwegs sind für Fahrt A und Fahrt B unabhängig. Der Rechner gibt beide £-Summen plus die Differenz (Fahrt B − Fahrt A) mit einem grünen oder roten Banner aus. Die Voreinstellung ist Kohle gegen Passagiere auf derselben 100-Kachel-, 60-Tage-Strecke — der kanonische „welche Fracht soll ich fahren?”-Vergleich aus den deutschen Foren.

Beeinflusst die Geschwindigkeit die Einnahmen, oder nur die Tage unterwegs?

Direkt zählen nur die Tage unterwegs. Die Frachteinnahmenformel liest die Fahrzeuggeschwindigkeit nicht — sie liest, wie viele Kalendertage die Fracht im Fahrzeug verbracht hat. Geschwindigkeit zählt nur indirekt, weil schnellere Fahrzeuge dieselbe Manhattan-Entfernung in weniger Tagen zurücklegen, was die Transitperioden senkt und damit den Zeitfaktor erhöht. Ein 100-km/h-Zug und ein 200-km/h-Zug auf derselben Strecke verdienen unterschiedlich viel — nur weil der zweite in der halben Zeit ankommt. Die Wiki merkt an, dass Geschwindigkeit unter etwa 50 km/h den stärksten Effekt hat und sich darüber abflacht; die Verdopplung von 200 auf 400 km/h hat eine viel kleinere Wirkung als die Verdopplung von 25 auf 50.

Glossar zu OpenTTD-Fracht und -Wirtschaft

Manhattan-Distanz

Die gradlinige Kachelgitter-Entfernung zwischen zwei Bahnhöfen, berechnet als $|xsrc - xdst| + |ysrc - ydst|$. Wird von der OpenTTD-Frachteinnahmenformel verwendet; ist nicht die tatsächliche Streckenlänge, die das Fahrzeug fährt.

Transitperiode

Die interne Zeiteinheit, mit der OpenTTD das Frachtalter zählt. Eine Transitperiode = 2,5 Kalendertage. In einem ein-Byte-Zähler gespeichert, sodass der Höchstwert 255 Transitperioden beträgt (≈ 637 Kalendertage), bevor der Zeitfaktor auf MIN_TIME_FACTOR = 31 abfällt.

Zeitfaktor

Der Frische-Multiplikator in der Einnahmenformel, Bereich 0 bis 255 (begrenzt bei 31). 255 = perfekt frisch, 31 = abgestandene Untergrenze. Jede Transitperiode jenseits von days1 reduziert ihn um 1; jede Periode jenseits von days1 + days2 reduziert ihn um zusätzlich 1 (also −2 pro Periode in der langsamen Zone).

days1

Früh-Verfallsschwelle einer Fracht in Transitperioden. Unter days1 verdient die Fracht zum maximalen Zeitfaktor 255. Beispiele: 0 bei Passagieren und Nahrungsmitteln, 1 bei Wertsachen, 7 bei Kohle, 25 bei Öl und Spielzeugen.

days2

Spät-Verfallsschwelle einer Fracht, addiert zu days1. Jenseits von days1 + days2 sinkt der Zeitfaktor doppelt so schnell. Kohle, Öl, Eisenerz, Stahl, Holz, Kupfererz, Zucker, Spielzeuge und Plastik haben alle days2 = 255 (praktisch unbegrenzt).

paymentRate (Zahlungssatz)

Der Basis-Zahlungssatz pro Fracht aus der _default_cargo-Tabelle in src/economy.cpp. Höchster Wert: subtropisches Holz (7964), dann Wertsachen (7509), Limonade (6250), Waren/Bonbons (6144), Kohle (5916). Niedrigster: Früchte (4209). In der Engine als Festkommazahl Q11.4 gespeichert.

GetTransportedGoodsIncome()

Die C++-Funktion in src/economy.cpp, die die £-Auszahlung berechnet, wenn ein Fahrzeug Fracht entlädt. Sie implementiert genau die ganzzahlige Formel, die dieser Rechner nachbildet, einschließlich der finalen BigMulS-Verschiebung um 21 Bit.

JGR’s Patch Pack (JGRPP)

Ein langlebiger Community-Fork von OpenTTD durch Jonathan Rennison mit Hunderten zusätzlicher Funktionen (realistisches Bremsen, programmierbare Signale, Stadtzonen). Der Frachteinnahmen-Code ist byteidentisch mit Vanilla — Zahlen aus diesem Rechner übertragen sich 1-zu-1.

NewGRF

OpenTTDs Format für nutzergenerierte Inhalte: Fahrzeuge, Industrien, Stadthäuser und Frachtpakete. NewGRF-Frachtpakete (FIRS, ECS, YETI) überschreiben die Vanilla-paymentRate-Tabelle (33 Zeilen: 31 eindeutige Frachten plus separate subtropische Holz- und Öl-Zeilen); dieser Rechner nutzt nur Vanilla-Sätze.

Klima

Eine der vier Szenario-Einstellungen in OpenTTD: Gemäßigt (Standard), Subarktisch, Subtropisch, Spielzeugland. Bestimmt, welche Frachten verfügbar sind — Kohle nur in Gemäßigt/Subarktisch, Diamanten nur in Subtropisch, Spielzeuge/Bonbons/Cola nur in Spielzeugland.

Frachtalterungsrate

Eine Wirtschafts-Einstellung (economy.cargo_aging_rate), die skaliert, wie schnell Fracht Transitperioden ansammelt. Standard 100 Prozent in Vanilla und JGRPP. JGRPP macht sie als konfigurierbaren Prozentsatz verfügbar; Vanilla setzt sie fest auf 100.

Inflation

OpenTTDs jährlicher Multiplikator auf Kosten und Einnahmen (~1,5 Prozent/Jahr per Default). Der Rechner gibt das Basisjahr-£ (1950) aus, identisch mit der spielinternen Zahlungssatz-Grafik; relative Vergleiche bleiben durch Inflation unverändert.

Inhalt verifiziert vom Smart Calculators Team