güterverkehr mit speedbonus in pak64

[whoami]

Original von Kasei
Bisher hat sich nur Whoami, sofern ich sein Posting richtig verstehe für etwas komplexeres ausgesprochen.

Eigentlich nicht, d.h. ich hab's nicht gerne komplex in der Implementierung (auch ich mag KISS - und damit meine ich nicht diese exzentrisch angezogene Band).
Ich favorisiere den schon beschriebenen Ansatz, den Erlös am Ziel zu berechnen, diesen in einem globalen Konto zu summieren, und den Convois ihren Anteil nach normierter Fahrleistung zuzuweisen: z.B. Gewichtung(Warentyp)*Menge*Entfernung_eff*Geschwindigkeitsbonus(Warentyp,v_eff). Umwege können, wenn gewollt, mit einer bestimmten Gewichtung positiv in die Entfernung einfließen, z.B. Entfernung_eff = (x*Luftlinie + y*Umweg)/(x+y) (<- natürlich normieren, um nur mit Integer und ohne Division auszukommen). Geschwindigkeitsbonus ist vielleicht unnötig - schnelle Fahrzeuge verwendet man am besten über lange Strecken. Und ein Komfortbonus für Passagiere wäre auch möglich. ;-)

Die Überlegung dahinter ist das Komplexe (exakter Beweis eines angenommenen sinnvollen Verhaltens ist mindestens aufwendig), und mit falscher Gewichtung pro Convoi kann man den Spieler ziemlich aufs Glatteis führen (so dass er profitable Fahrzeuge außer Dienst stellen könnte), aber die Umsetzung ließe sich m.E. mit jeweils einem Summenfeld pro Warenpaket (gewichtet durchschnittliches Erzeugungsdatum => Wartezeiten zählen mit) und Fahrzeug (Transportleistung, mit vielen Faktoren gewichtbar) erreichen, so dass auch die Rechenzeit und der Speicherbedarf akzeptabel wären.
Für das Speichern von Zeitstempeln müsste natürlich ein Lösung gefunden werden.

Edit: Unprofitable Fahrzeuge/Linien erkennt man daran, dass sie auf ihren Kosten sitzenbleiben - es geht oben um die Erlösverteilung nach Leistung.

Edit^2: Wenn man zwischen zeitkritischen (je schneller, desto mehr Erlös, aber gedeckelt, im Gegensatz zum jetzigen Bonus) und kostenkritischen (fixer Preis nach Luftlinie) Warentypen unterscheidet, gibt es für das Summenfeld im Warenpaket zwei verschiedene Bedeutungen (und zwei Berechnungsverfahren). Will man beide verwenden, dann sind halt zwei Variablen pro Paket notwendig.
Weil die Werte nicht exakt erfasst werden müssen, reicht vielleicht auch ein 2-Byte Integer pro Variable. (Das hattest Du ja vor einigen Dutzend Posts schon ausführlicher beschrieben.)

Edit^3: Und wenn man die Erlösverteilung genauer halten will, kann man global und pro Convoi den Erlös nach Warentyp separat speichern. (Zur Not auch noch pro Einzelfahrzeug, wenn man pro Wagon eine Profitabilitätsanalyse haben will, aber da genügt vielleicht die maximale Auslastung in einem bestimmten Zeitraum.)

Wenn mein System für gut befunden worden wäre, hätte ich es auch selbst umgesetzt.

Um ehrlich zu sein: ich habe etwas Mühe, dem Thread zu folgen (genauer: Deinen Ausführungen - das liegt natürlich an mangelnder Quellenkenntnis meinerseits), daher ist mir derzeit nicht ganz klar, wie das vorgeschlagene System aussieht. Daraus entstammen auch die Überlappungen zwischen Deinen und meinen Vorschlägen - betrachte sie einfach als Zustimmung meinerseits. ;-)

Vll habe ich Prissis Antwort nur falsch verstanden, aber fuer mich hörte sich die auch so an wie: Das System ist ok wie es ist, wems nicht gefällt der kanns ja einfach ausschalten!

Und wenn die separate Tabelle kommt, kann man es dort abschalten oder ändern (d.h. schummeln ;-) ), ein Schalter in simuconf.tab wäre auch einfach einzurichten, aber allein auf den Bonus zu verzichten bringt ja nur Nachteile.

Nur dazu müssen wir uns eben erstmal einigen, wie es geändert werden soll. Deshalb schreibe ich meine Ideen hier rein und Programmier nicht einfach darauf los.

Beim Programmieren wäre ein #ifdef für die Erlösberechnung sinnvoll.