güterverkehr mit speedbonus in pak64

[Kasei]

eigentlich hatte ich nicht vor wagen umzuhängen^^

[Hajo]

Du nicht, aber andere wollten das Feature mal ... ist lange her.

[Kasei]

ja ich erinnere mich sowas gelesen zu haben, rangierloks und so benutzen.
das ist fuer meine fähigkeiten dann doch ein bischen zu großer eingriff *g*

[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.

[Hajo]

Original von Kasei
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)

Zu (1): Mein letzter Stand ist, dass keine besonderen Vorkehrungen getroffen wurden.

Zu (2): Es gibt auch einen good_writer_t der von Makeobj benutzt wird, um die Daten von einem DAT in ein PAK zu schreiben.

Wie immer mit Vorbehalt. Meine Infos sind 2 1/2 Jahre alt ...

Edit:

ware_t objekte sind zahlreich, und, was schlimmer ist, werden bei jeder Zuweisung kopiert (value type). 8 Bytes extra scheinen wenig, sind aber vielleicht schon zu viel, da ware_t so zahlreich sind und oft kopiert werden? -> Testen mit einem gut ausgebauten Spielstand, und sehen wie viel Unterschied es macht.

[prissi]

Ja, es gibt Routinen zum Timerüberlauf. Alle fünf Jahre wird ticks einfach wieder auf Null gesetzt, da der nur für den Test auf den nächsten Monat und den step benutzt wird. Bei jedem Laden startet der Timer auch wieder bei Null. Das ist aber erst ein Problem bei zwei Timerüberläufen ...

ware_t in der Größe zu verdoppeln ist keine gute Idee. Ich habe gerade vor kurzem ware_t in der Größe halbiert und schupps war das Spiel bei sehr vielen Passagieren bis zum Faktor 3 schneller.

Aber der größte Einwand für mich ist, dass sich mit diesem System Ringlinien nicht rentieren, da dort zwangsläufig Sachen länger brauchen. Nur Sternverbindungen mit dem schnellstmöglichen Fahrzeug wären die logische Konsequenz (also am besten nur Flughäfen => TTD, da wurde das gemacht m.E. damit die AI besser dasteht). Doch ich würde ungern Spielern ein Spielprinzip aufzwingen.

[DirrrtyDirk]

Ich muss sagen das die Diskussion schon eindeutig meinen Horizont übersteigt.

Aber wie prissi schon sagte: ich bin auch der Meinung das weiterhin sowohl Ring- als auch Sternlinien rentabel bleiben sollten. Ich finde es nämlich gut das man das in Simutrans wunderbar, je nach Anforderung benutzen und kombinieren kann und beide Formen Ihre Vor- und Nachteile haben.

Aber eine Änderung des Speed-Bonus Systems würde ich auch befürworten. Nur wie genau... nee das überlasse ich Euch.

[Kasei]

prissi, setze wayfactor auf 1 und ein umweg wird genauso gewertet wie ein direkter weg. -> es ist dem pakgestalter überlassen ob er umwege bestrafen will oder nicht.

nur dank dem löschen von ticks, und dem nicht speichern von ticks haut mein system leider nicht mehr hin. dh da müsste man dann auch was ändern.

und ich verdoppel ware_t nicht, ich füge nur 2 4byte große variablen ein.

ein stern ist übrigends auch nicht perfekt^^ denn wenn 2 städte neben ein ander liegen und du die leute erst in die mitte kutschierst ist das auch ein umweg.
(ich persönlich wäre fuer ein wayfactor in höhe von 0.8 oder 0.9 je nachdem wie hoch die gewinnspanne bei einem zug ist. (halber gewinn bei umweg denke ich ist ein guter anreiz ein etwas besseren weg zu finden, man geht aber nicht bankrott wenn man es nicht macht)

[Kasei]

eine frage noch: woher weis das spiel wenn ich es lade das es zb der 7.oktober.1978 18:30 ist wenn ticks nicht gespeichert wird, bzw nach einem laden auch 0 gesetzt wird?
wird dieses datum+uhrzeit aus mehr als einem faktor berechnet? und wäre das eine möglichkeit nicht ticks zu benutzen?

Edit
Habe den Beitrag oben nochmal überarbeitet so das man nur die Erläuterungen lesen muss um zu verstehen wie ich mir gedacht habe, das man die Einnahmen berechnet. ich fände es schon sinnvoll wenn auch normale spieler mitreden können wie sich Einnahmen berechnen sollten.
Und ich weis das ich manchmal sehr umständliche Formulierungen habe

[prissi]

Also ticks=0 des jeweiligen Jahres. Wenn ich am erste August 1980 speichere, dann sind danach die Ticks für den 1.1.1980 relevant. Ticks beziehen sich nach dem Laden immer auf das Basisjahr. siehe simworld_t::laden()

Außerdem ist ware_t genau 12 bytes groß. Daher würde ich das Hinzufügen von 8 Byte schon fast verdoppeln nennen ...