güterverkehr mit speedbonus in pak64

[whoami]

Original von Kasei
Wichtig ist hierbei zu bedenken, bisher kennt ein Zug wenn er wo ankommt und seine Einnahmen berechnet nur die transportierte Menge, die Ziel,Zwischenziel Koordinaten, die Koordinaten des vorherigen Halts und die des aktuellen Halts.

Die Zeitpunkte dieser beiden Halte könnten noch festgehalten werden (müssten dann ein Save überstehen), oder aber der Zeitraum dazwischen.

Mir ist bei Deinem Code noch nicht klar, was beim Übergang zwischen zwei Fahrzeugen passiert, d.h. welchen Erlös erhielte ein Fahrzeug, das die Ware z.B. seitwärts zu einem Verladebahnhof bringt. (Solange alles in einem Convoi passiert, haben wir die meisten Möglichkeiten, und brauchen kaum Daten im Warenpaket.) Der Übergang zwischen zwei Transportunternehmen (möglich mit öffentlichen Haltestellen) macht es am schwierigsten, aber in dem Fall kann man am Übergabepunkt komplett abrechnen.

Noch was zu der Sache mit dem Umwegen, schon jetzt werden Umwege zwischen 2 haltestellen garnicht gewertet

Ich verstehe unter Umweg denjenigen Anteil des Wegs zwischen zwei Halten (kann in euklidischer Metrik, Manhattan-Metrik oder in befahrenen Feldern gemessen werden), der nicht der Reduktion des Abstands zum Ziel dient, d.h. er ist pro Warenpaket zu ermitteln.
Der Zug muss die befahrenen Felder sowieso zählen für die Kosten - ein einfaches Feldzahl++ und erst beim nächsten Stationshalt Berechnung von Kosten und Erlös, das kostet kaum Rechenzeit.

(Puuh, liest mich eigentlich noch jemand?)
Es ist verständlich, wenn Prissi und Hajo einen größeren Umbau kritisch sehen, weil hinter dem jetzigen System natürlich einige Überlegung steckt (die wir anderen jetzt erst nachholen).

Ich meine, dass zwei wesentliche Kritikpunkte am jetzigen System der Erlösberechnung- und Zuweisung recht einfach behoben werden können:
- Bonusberechnung sollte nach tatsächlicher Geschwindigkeit geschehen (entweder mit Felderzählung, oder mit Distanz zwischen den letzten zwei Halten, oder (m.E. am besten) mit Reduktion der Distanz zum Ziel). Speicherung der Haltezeitpunkte ist vermutlich erforderlich.
- keine volle Anrechnung des Umwegs für den Erlös(-Sockel),
z.B. Weg_effektiv=(x*Distanzreduktion+y*Wegstrecke)>>7; // x+y=128
Und wenn dann eine Linie wegen zu großen Umwegs in die roten Zahlen gerät, muss der Spieler eben dieses erkennen und als Quersubvention oder als Optimierungsbedarf einstufen (das gibt es jetzt auch schon).
Dann kann die Erlösberechnung weiterhin an jedem Halt stattfinden, und zusätzliche Einträge im Warenpaket erübrigen sich.