güterverkehr mit speedbonus in pak64

[Kasei]

scheinbar ist eine Frage untergegangen:

I: wird Wegtyp "tram" zur Zeit als Strasse oder als Schiene abgerechnet?

Nun zu meinem Vorschlag:

Warentyp bekommt 3 neue Variablen, Speedbonus fällt dafür wech:
wayfaktor (liegt zwishcen 1 und -1) zur Gewichtung von Umwegen. (fährt man in die falsche Richtung wird nur Distanz*wayfaktor gewertet) (defaultwert 1)
speedfaktor1 (zwischen 0 und 1) (defaultwert 0)
speedfaktor2 (>=0) (defaultwert 1000)
Diese Defaultwerte ergeben ein Spiel wie bisher mit speedbonus 0.

ware_t bekommt 2 neue Variablen
uint32 Starttime;
int32 Dist;
und eventuell die Funktionen

Code:

wigthed_average_ST(uint32 St_n, menge_n) { Startime = (Starttime*menge+St_n*menge_n)/(menge+menge_n); }
wigthed_average_D(int32 Dist_n, menge_n) {Dist = (Dist*menge+Dist_n*menge_n)/(menge+menge_n); }

wird Ware an einem Halt übergeben wird dort:
(in haltestelle_t::vereinige_waren(const ware_t &ware))
Starttime=welt.gib_zeit_ms(); (ticks(Millsekunden=10-³ s) seit Kartenstart)
Dist=0;
der übergebenen Ware.
liegt nun schon Ware mit dem selben Ziel dort, werden die beiden miteinander vereinigt.
Dabei wird St gewichtet gemittelt(durch die Funktion wigthed_average_ST), Dist muss man nicht behandeln, da Dist ja fuer alle wartenden Waren 0 ist.

Wird Ware auf ein Fahrzeug verladen,
(in vehikel_t::load_freight(halthandle_t halt))
und befindet sich dort bereits Ware mit dem selben Ziel, wird diese auch vereinigt, dabei wird aber St und Dist gewichtet gemittelt (beide oben beschrieben Funktionen).

erreicht ein beladenes Fahrzeug einen Halt wird:
für alle Waren im Fahrzeug Dist wie folgt neu berechnet:
(bereits einmal von mit beschrieben)
(in der funktion sint64 vehikel_t::calc_gewinn(koord3d start, koord3d end) stehen alle infos dafuer zur verfügung, daher sollte es dort gemacht werden)

Code:

dx=end.x-start.x
dy=end.y-start.y

halthandle_t halt=haltestelle_t::gib_halt(welt,end);

uint32 now=welt.gib_zeit_ms()

und in der Iteration über alle Waren:

Code:

koord zielkoord = ware.gib_zwischenziel()->gib_basis_pos;
Dx=zielkoord.x-start.x
Dy=zielkoord.y-start.y

if(dx*Dx>0) ware.Dist+=abs(dx);
else ware.Dist+=ware.gib_typ()->gib_wayfactor()*abs(dx);
if(dy*Dy>0) ware.Dist+=abs(dy);
else ware.Dist+=ware.gib_typ()->gib_wayfactor()*abs(dy);

die Einnahmen werden dann so berechnet:
(auch in sint64 vehikel_t::calc_gewinn(koord3d start, koord3d end) in der Iteration über alle Waren)

Code:

if( ware.gib_zwischenziel() == halt) //ware wird hier entladen
{
speedfaktor=((ware.Dist/(now-ware.starttime))*ware.gib_typ()->gib_speedfactor1()+ware.gib_typ()->gib_wayspeedfactor2())
value+=(speedfaktor*ware.Dist*ware.menge*ware.gib_preis());
}

Dazu ein paar Erläuterungen:
Die Einnahmen fuer abgeliefterte Ware sind also: P*M*D*(S1*D/T+S2)
P(reis) ist also Geld pro Weg pro Geschwindigkeit pro Wareneinheit.
D wird in Feldern gemessen, und ist entweder zurückgelegte Distanz in X-Richtung + zurückgelegte Distanz in Y-Richtung wenn der halt näher am ziel lag als der vorherige, oder diese Distanz mit einer zahl zwischen -1 und 1 multipliziert, wenn man sich nicht in Richtung des Zwischenziels bewegt hat. (nicht des entglültigen Ziels sonder dort wo eine Ware einen Convoi wieder verlässt). Ist dieser Faktor(von mir wayfaktor genannt) = 1 so macht es keinen Unterschied und "Umwege" werden genaus behandelt wie der direkte Weg.
T ist die Wartezeit am Halt+Fahrzeit bis zum Zwischenhalt.
D/T ist somit die Geschwindigkeit mit der die Ware zum Zwischenziel transportiert wurde.
D/T in Feldern/Millisekunde=0.00068 kmh (bei 20 bit pro monat und 1km feldlänge) eventuell sollte man (now-ware.starttime) um 10 bits nach rechts schieben (sprich durch 1024 teilen) dann wäre D/T etwa 0.7 kmh. Fährt ein Zug also 70 kmh ist D/T 103000 (bzw 100).
Wartet Ware die selbe Zeit an einem Halt wie sie fuer die Fahrt zum nächsten Zwischenziel braucht, so ist D/T nur halb so groß, wie wenn die Ware sofort tranportiert worden wäre.
Mit S1 und S2 lässt sich die Abhängigkeit der Einnahme von der Geschwindigkeit regulieren. S2 legt einen Grundbetrag fest den man auf jeden Fall bekommt, S1 kann zwischen 0 und 1 liegen. Ist S1=0 bekommt man nur P*M*D*S2 an Einnahmen, ist S1 = 1 und S2 = 0 bekommt man P*M*D*D/T.

So kann man fuer jede Fracht entscheiden soll sie möglichst schnell transportiert werden(Passagiere,Post,Kühlwaren zb), oder ist es völlig egal wie lange sie lagert(vll bei Kohle/Sand/Öl etc), oder etwas zwischendrin (Autos, Stahl, Bier)

Da mit diesem Modell, doppelt so schnelle Züge doppelt so viele Einnahmen bekommen wie langsame Züge können sie auch mehr als doppelt so hohe Betriebskosten haben. und man bekommt dadurch nicht mehr Gewinn füer den Transport von einer Menge Fracht, sie wird nur schneller Transportiert.

Noch ein paar Fragen:
1) Gibt es schon Routinen die sich mit einem Überlauf des Wertes world::ticks beschäftigt. Das wäre nach etwa 1193 Stunden Spiel so weit. (bei 20 bit_pro_monat=1048576 ms Realtime für einen Monat wären das in etwa 331 Spieljahre. (startet man 1930 passiert es 2261 irgendwann).
2) muss man, wenn man aus einem good.x.pak zusätzliche Daten auslesen will, ausser der Funktion obj_besch_t * good_reader_t::read_node(FILE *fp, obj_node_info_t &node) noch etwas ändern (außer dem good.x.pak selbst)

EDIT: vll sollte jemande diesen threat ins wünsche und anregungsforum verschieben!
EDIT 2: Die Erläuterungen so überarbeitet das alles wesentliche dort steht und man sich nicht durch den Teil davor arbeiten muss. Sollte so viel besser verständlich sein hoffe ich.