güterverkehr mit speedbonus in pak64

[whoami]

Original von Kasei
Wenn du mal versuchst deinen Vorschlag programmtechnisch umzusetzen wirst du wohl mehr speichervariablen brauchen als ich ihn meinem.

So weit liegen unsere Ansätze nicht auseinander. (Mein letztes Posting beschrieb die eigentliche Kalkulation nicht, das war vorher.)

Abrechnung am Ziel -> Fracht muss entweder startort und startzeit kennen oder gebrauchte zeit und zurückgelegte strecke.

Anders: es können (in aggregierbaren Warenpaketen) diese Variablen auftauchen:
- Fahrpreis (berechnet zu Beginn => nach oben beschränkt - verfällt mit der Zeit, Auszahlung am Ziel) -> Bonus (nur positiv)
und/oder
- bisherige Wegstrecke (gewichteter Mittelwert von Luftlinie und gefahrenem Weg) (berechnet am Ziel; nicht zu Fahrtbeginn, weil das Verlieren der Ladung bestraft werden muss, EDIT: UND weil die Route erst am Ziel definitiv bekannt ist) -> Sockelbetrag
EDIT: wenn es eine zugesicherte durchschnittliche Transportzeit gibt (festzulegen nach Warentyp, Kartengröße, Jahr), auch wahlweise:
- seit Erzeugung vergangene Zeit, besser durchschnittliche Erzeugungszeit (auch die ist aggregierbar)

Willst du das erst ganz am ende machen, und Zügen dann irgendwie fuer ihre leistung entlohnen kommt es zu dem problem, das bei manchen zügen ihr Auslastung hoch ist sie aber mehr oder weniger nur einem umweg fahren und so im enteffekt nichts verdienen, aber der auslastung aber profitabel aussehen.

Wenn der Umweg (bedingt durch das Verkehrsnetz) notwendig ist, dann muss er auch 'belohnt' werden - aber nicht durch höheren Fahrpreis, sondern durch Umschichtung zwischen den Fahrzeugen.
Und wenn das gar nicht gewünscht ist, kann die gefahrene Strecke komplett zur Preisberechnung hergenommen werden (Gewichtung 100% sowohl für Warenpaket als auch für Fahrzeug, Luftlinie 0%).

würde es zumindest schwer machen Lange Züge auf kaum befahren Strecken einzusetzen. da diese dort die meiste Zeit warten.

Wenn beliebige Wartezeiten OK sind, dann gibt es eben nur den Sockelbetrag.

Nahverkehr ist seltens Profitabel.

Richtig: der Spieler muss sich bewusst sein, dass er quersubventioniert, weil ohne die Busse seine schnellen Zügen viel weniger Auslastung hätten. Jedes einzelne Fahrzeug zum isolierten Profit Center zu machen wäre falsch.

Deshalb hatte ich bei mir 3 Faktoren, einer für Gewichtung von Umwegen, die 2 anderen zum Gewichten der zeit, zwischen reiner zeitabhängigkeit und keiner zeitabhängigkeit.

Wir sind in der Tat nicht weit auseinander.

Es scheint alles fuer einen Konstanten rev_speed zu sprechen da er am einfachsten umzusetzen ist, und programmtechnisch nicht viele Änderungen erfordert.

Ich dachte, Du magst komplizierte Aufgabenstellungen?

P.S.: ;-)

Original von FrankP
Die Tabelle liese sich auch binär mit Makeobj in eine Pak-Datei schreiben.

Das wäre aber unfair gegenüber denjenigen, die keine Hex-Editor haben. ;-)