güterverkehr mit speedbonus in pak64

[whoami]

Original von Gotthardlok
- Falls die Null-Bonusgeschwindigkeit weiterhin anhand verfügbarer Fahrzeuge berechnet wird, löst er nicht das Problem, dass ab ca. 2000 der PV viel schneller fährt als der GV, (...)

Die Einführung einer pak-eigenen Tabelle (auch hier besprochen) würde dabei auch schon helfen. Überlegenswert wäre in der Tat, ob für bestimmte Frachttypen (auch in der Tabelle) noch eine eigene Referenzgeschwindigkeit festgelegt werden können sollte.

Falls es einen Malus für den Umweg gibt, müsste dieser vollständig vor dem Umsteigen bzw. "Mergen" greifen

Die Berechnung innerhalb eines Convois ist die am ehesten praktikable Lösung. Wenn dann der Umweg darin besteht, dass der Umsteigehalt (Übergang zum nächsten Convoi) weitab liegt, kann es sogar passieren, dass der anliefernde Convoi kein (oder sogar ein negatives) Einkommen erhält, je nachdem, wie stark man den Umweg anrechnet.

Umwege werden als "Schlecht" beurteilt; aber stellt euch ein Szenario vor, wo Streckenunterhalt viel teurer als Laufkosten sind, im Gegensatz zum pak64.

Das ist gerade ein Fall, in dem der Spieler ein effizientes Netzwerk benötigt - er kann nicht für jede Verbindung eine eigene Trasse anlegen (arme KI-Spieler), auch wenn das den Erlös pro Verbindung maximiert. Die Fahrpreise (im Verhältnis zu den Kosten) müssen hier genug Luft lassen, damit eine Verbindung auch rentabel ist ohne Verwendung der kürzesten Fahrtstrecke.

Auf Wartezeiten hat man nur bedingt Einfluss

Diese zu berücksichtigen ist eh nur mit einer Historie pro Warenpaket möglich, und sei es ein Summen-/Durchschnittsfeld.
Aus eigener Erfahrung ist es wirklich so, dass man von der Nachfrage überrollt werden kann, das ist dann aber i.d.R. lukrativ. Ohne eine Möglichkeit, etwas wie Taktzeiten zu simulieren, ist immer wieder ein Eingreifen erforderlich bei Streckenüberlastung und Aufstauen von Fahrzeugen derselben Linien (was für hohe durchschnittliche Wartezeiten sorgt).