güterverkehr mit speedbonus in pak64

[prissi]

Die Ware kennt keine Route sondern merkt sich von der Routensuche nur den naechsten Bahnhof. Dort fragt sie, ob man sie dort annimmt. Falls nicht, schaut sie nach, ob da schon wer/was in ihre Richtung wartet. Falls ja, ist das naechste Ziel schon bekannt. Ansosnten halt nochmal den naechsten Bahnhof suchen.

Und Waren und Pax anders zu behandeln ist eine ganz schlechte Idee, weil dann die Kernroutinen zweimal vorhanden sein muessen. Doppelt so viel Chancen fuer Fehler, doppelt soviel Arbeit zum Verwalten.

[Wurzelgnom]

Original von prissi
...
Und Waren und Pax anders zu behandeln ist eine ganz schlechte Idee, weil dann die Kernroutinen zweimal vorhanden sein muessen. Doppelt so viel Chancen fuer Fehler, doppelt soviel Arbeit zum Verwalten.

Ich meinte eine Trennung beim Bonus.
Wenn dieser aus den Kernroutinen raus genommen wird, sollte das möglich sein.
Bei der Variante mit dem Zeitstempel, braucht die Bunus-Funktion nur am Ziel aufgerufen werden. (RoutenID, Statzeit, Ankunftszeit)
Die eigentliche Bonusberechnung braucht noch nicht mal, sofort sein.

Original von prissi
Die Ware kennt keine Route sondern merkt sich von der Routensuche nur den naechsten Bahnhof. Dort fragt sie, ob man sie dort annimmt.
...

Dann lässt sich der Weg ja auch Speichern.

Die Ware bekommt eine RoutenID. Erzeugt kann diese schon in der Erzeugerindustrie werden.
zBsp. : Kohle.Industrikoordinate.Zielindustriekoordinate

Über die RoutenID werden dann die Stationen gespeichert.

Bei der Routensuche wird dann die Station, die bei der RoutenID eingetragen ist, zuerst abgefragt.

[Kasei]

Orginal von Prissi

Das Prinzip von Kasai ist genau so in OTTD verwirklicht und ich finde es schrecklich. Man kann auch nicht mal sagen, wieviel Gewinn ein Zug gemacht hat. Wie soll man so disponieren und unrentable Strecken finden?

Falls du das ZielzeitModell meinst, ich hatte nur versucht Franks Vorschlag auszuformulieren und dabei auch gleich auf die Probleme hingewiesen.


Zu der Geschwindigkeitssache von prissi/hajo.

prinzipiell ist nichts dagegen zu sagen es an die echtzeit zu koppeln. (nur fuer ein netzwerkspiel leider unbrauchbar?)

das ein zug bei hoher framezahl sehr viel schneller abbremst ist dann allerdings ein bug!!

und es führt auf unterschiedlich schnellen rechnern zu unterschiedlichem spielverhalten. (abgesehen vom bug)
beispiel.
da wohl über die zuge iteriert wird, faehrt pro step immer erst zug A dann B, (vll wird mal andersrum iteriert, fuer mein beispiel nicht wirklich wichtig)
nun treffen sich 2 züge an einer kreuzung.
zug A fährt sagen wir mal 15 felder/s. Zug B 30Felder/s
zug A ist 12 Felder von der kreuzung wech, Zug B auch 12.
rechner 1 schafft 3 frames pro sek, der 2te nur 1einen.

Bei Rechner 1 erreicht Zug B die Kreuzung bei der berechnung von Frame 2 zug A die kreuzung erst in frame 3 und muss nun warten.
bei Rechner 2 erreicht Zug A die kreuzung im selben frame wie zug B und wird sie blockieren da er zuerst abgearbeitet und bewegt wurde.
solche sachen lassen ein spiel komplett aus dem ruder laufen.

für ein netzwerkspiel ist es daher unbrauchbar. dort sollte ein server die gesamte bewegung der fahrzeuge berechnen und die darstellung erfolgt nur auf den angeschlossenen clientrechner mit den spielern.
dh. -> client sendet was er tut an den server, der bewegt die züge, sendet deren position an den client zurueck und client stellt sie dar.
aber meine gedanken zur realisierung der netzwerkfähigkeit sollten mal in einem anderen threat behandelt werden und nicht auch noch hier.

Das problem ist allerdings nebensächlich wenn man sich gedanken macht wie wir den transport von gütern abrechnen wollen.

Habe jetzt nur keine zeit mehr meine 2 vorschläge (Starzeitmodell und StartzeitDistanzModell) nochmal auszuführen.
das mache ich später

[prissi]

Langsam wird es offtopic:
Für ein Netzwerkspiel wird jeder Frame exakt 50ms (oder 40ms) intern dauern, auch wenn in Echtzeit schon mehr zeit vergangen ist. Exakt alle 200ms wird dann ein Step gemacht werden. Falls es länger dauert, ruckelt es halt.

So machen die beiden Netzwerkspiele, in dessen Quelltexte ich schauen konnte. Und wenn man keine Schiffe 1000 Planquadrate ohne Wegmarken fahren lässt, sollte man das auch kaum bemerken.

[Kasei]

ich sagte ja bereits das mit dem netzwerk führt nun zu weit^^

@ prissi und die die sich auskennen:
nun erstmal ein paar fragen vorweck, habe in den quellcode geschaut:

A: die klasse ware_t wird benutzt um waren an haltestellen und zügen, etc. zu speichern;
haltestellen und züge enthalten einen vector in dem alle dort vorhandenen waren gespeichert werden.

B: die klasse haltestelle_t hat die funktion vereinige_waren(const ware_t &ware), die immer aufgerufen wird, wenn neue ware an der station eintrifft, sowohl wenn ein vehikel etwas liefert als auch wenn neue ware erzeugt wird(step_passagiere)?

C: step_passagiere der klasse stadt_t kümmert sich um die passagiererzeugung und übergibt mit der funktion haltestelle_t:tarte_mit_route(ware_t ware) die passagiere an die station.

D: die funktion sint64 vehikel_t::calc_gewinn(koord3d start, koord3d end)
berechnet die einnahmen die man fuer das fahren der ware von halt start zum halt end bekommt. (start ist der vorige halt, end ist der aktuelle halt) abgerechnet wird also immer von halt bis halt.

E: bisher berechnet sich die einnahme (in der in D erwähnten funktion) so:
fuer jede ware:

Code:

    const long dist = abs(end.x - start.x) + abs(end.y - start.y);
    const sint32 grundwert128 = ware.gib_typ()->gib_preis()<<7;
    const sint32 grundwert_bonus = (ware.gib_typ()->gib_preis()*(1000+speed_base*ware.gib_typ()->gib_speed_bonus()));
    const sint64 price = (sint64)(grundwert128>grundwert_bonus ? grundwert128 : grundwert_bonus) * (sint64)dist * (sint64)ware.menge;

speed_base kann nicht kleiner als -100 werden, und ist 0 wenn man genau durchschnittlich schnell fährt (durchschnittlich errechnet sich wohl aus den möglichen geschwindigkeiten der zur verführung stehenden fahrzeuge auf dem entsprechenden Wegtyp (schiene,strasse,luft,wasser)
(btw wird tram strasse oder als schiene abgerechnet? )
ist man doppelt so schnell wie durchschnittlich möglich ist speedbase 100.

speedbonus wird im good.x.pak festgelegt, nur wie gespeichert? Ist es Möglich das grundwert_bonus überhaubt kleiner wird als grundwert128? sprich kann speed_bonus größer als 10 sein? Wird speed_bonus also %zahl mal 100 gespeichert, also wäre ein bonus von 15% ein speed_bonus = 15?

[Hajo]

A: Ja. Ware_t objekte beschreiben ein Warenpaket das transportiert wird.

B: Ja. vereinige_waren() schlägt neue Ware bereits wartender Ware mit gleichem Ziel und Typ zu oder erzeugt ein neues Paket wenn keine gefunden werden kann mit gleichem Ziel und Typ.

C: Das scheint nach meiner Zeit entstanden zu sein. Weiss ich nicht.

D: Korrekt.

E: Nach meiner Zeit entstanden bzw. modifiziert.

Netzwerkspiel: Simutrans is m.E. von der Architektur her völlig ungeignet um daraus ein Netzwerspiel zu bauen. Aber der Mensch hat sich von solcherart Problemen noch selten von einem Vorhaben abbrigen lassen

Edit:

Aus meiner Sicht würde ich ein globales Konfig-file für ein Pak einführen in dem die Progression des Bonus über die Jahre hinweg festgelegt wird. Linear interpoliert zwischen ein paar Stützpunkten. Das sollte zum einen einfach zu machen sein und zum anderen ausreichend, zumindest was die Probleme mit dem Speed-Bonus angeht.

Ein komplett neues Bezahlungsverfahren für Transportdienstleistungen wie hier angedacht ist sicher eine größere Baustelle. Da möchte ich mich heraushalten. Das bisherige Verfahren ist ein Mix zwischen halbwegs realistisch und technisch verhältnismässig einfach umsetzbar. Fällt für mich in die Kategorie "Gut genug", und vor allem jetzt wo der Sourceode offen liegt würde ich (wenn ich noch Entwickler wäre) sagen, wer mehr möchte muss selbst Hand anlegen.

[Kasei]

frage F:
die funktion bool vehikel_t::load_freight(halthandle_t halt) sorgt fuer das beladen eines fahrzeugs und das vereinigen mit eventuell schon beladener fracht bei gleichem ziel?



Das speedbonus system hat in seiner jetzigen Form seine macken, insbesondere das es sich immer auf die durchschnittlich mögliche geschwindigkeit bezieht und auf die min_top_speed(kleinste höchstgeschwindigkeit eines fahrzeugs des konvois zumindest laut comment im source code, auch wenn prissi irgendwo mal erwähnt hat das die tatsächlich erreichte höchstgeschwindigkeit einfluss hat).

und ich halte die änderungen am source nicht fuer allzu groß bin aber mit meiner durchsicht wie man merkt noch nicht ganz fertig

Edit:

frage G: halthandle_t zwischenziel in der class ware_t speichert den nächsten zwischenhalt, dort wo eine ware die linie verlassen muss um auf eine andere zu wechseln?

Edit 2:

Frage H: ein convoi wird fahrzeugweise beladen/entladen und nicht auf mal??

[prissi]

Ich bin auch dafür, den Speedbonus per Tabelle pro pak zu definieren, nach Jahreszahlen und transportmitteln.

Zu den Fragen:
F) denke schon

G) ja

[Kasei]

mein ziel ist es folgendes zu gewährleisten:

a wartezeit am bahnhof mit einkalkulieren (muss ich lange warten zahl ich weniger)
b umwege gewichten können (ich fahre gerne einen umweg, aber wieso soll ich dafuer soviel zahlen wie fuer die direkte strecke)
c züge zeigen immer noch an wieviel gewinn sie machen (abgerechnet wird nichtmehr bei jedem halt sondern wenn die ware ihren zwischenhalt erreicht)
d abhängig von der fahrzeit und zurueckgelegten strecke die einnahmen errechnen.

e (optional) abhängig von der wartezeit von ware an einem bahnhof werden in zukunft passagiere diese station benutzen oder eben zuhause bleiben.

ich denke ich bin weit genug durch den code gestiegen um dazu morgen einen vorschlag zu machen,

[Hajo]

zu H) Ein Convoi wird Fahrzeug für Fahrzeug beladen.

Theoretisch erlaubt Simutrans also das Umhängen von Waggons an andere Loks, ohne dass die Ware dabei hops geht. Allerdings müsste der Zwischenhalt dann angepasst werden ... ist also nicht ganz trivial. Die Datenstrukturen könnten das aber.

Viel Spass beim Tüfteln an neuen Bezahlmodellen und Routingverfahren. Seit Toyota wissen wir ja: Nichts ist unmöglich

Edit: Linksschreibung ein bischen korrigiert.