güterverkehr mit speedbonus in pak64

[whoami]

Original von Kasei
durchschnittliche x/y koordinate wird nicht gehen, (...) legst du nun bei B die kooridinaten von A und C zusammen hebt sich diese strecke auf.
also ist es nicht so einfach.

Ja, deswegen auch der Smiley.

Die Zielgröße ist: "Geld für mich". Zeit und Weg sind dabei nur Hilfsgrößen, daher mein abgewandelter Vorschlag.

durch den einbau der zeit würde der speedbonus ja wegfallen.

Ja, man kann beide zusammenlegen, aber den Bonus auch in einer getrennten Variable mitführen. Dann hat man immer noch einen Sockelbetrag, und nur den können z.B. Schiffe bekommen, wenn die Kalkulation über den ganzen Weg geht. Bei verderblichen Gütern (und ungeduldigen Fahrgästen) könnte der Sockel sehr klein sein. Bei Kohle könnte dagegen der variable Teil entfallen.

denn je schneller der zug desto kleiner die gebrauchte zeit und desto höher die einnahmen.

Extrem schnelle Züge/Flugzeuge hätten aber keinen so großen Vorteil mehr. Das bißchen Reisezeit noch weiter zu optimieren lohnt sich dann nicht (so wie in der Realität auch.)

eine idee wäre um das durch umwege mehr gewinn machen zu unterbinden folgendes: (...)

Entschuldige bitte, dass ich den Teil nicht richtig gelesen habe - Kopfschmerzen und die Rettung einer wichtigen Datenbank lenken mich derzeit ab.

[Kasei]

es sollte durch St, und D auch möglich sein diese faktoren in die passagier/fracht generierung einzubauen.
z.B. könnte man auch haltestellen eine Variable St zuweisen, die die gemittelte Wartezeit der Ware an der Station enthält. je weiter diese Zeit in der Vergangenheit liegt desto weniger Passagiere/Fracht werden an dieser Station erzeugt:

jetzt := aktuelle Zeit
St := gemittelte Startzeit (ab wann sie warten) aller waren an der station (oder auch nur passagiere/Post)
T := die Erlaubte Wartezeit ohne Malus auf die passagiererzeugung.

dt=(jetzt-St) := Wartezeit.
if(T<dt) f=T/dt else f=1

f:= Malusfaktor: werden an dieser station normalerweise N Waren erzeugt, werden nun noch f*N oder wurzel(f)*N waren erzeugt. wurzel sagt aus warten passagiere doppelt solange wie erlaubt, werden immer noch 71% der waren an die Station übergeben.

Man könnte auch fuer jede Ware ein St an einem Halt speichern und dann fuer jede Ware unterschiedliche T heranziehen. Post muss ganz schnell abgeholt werden, Passagiere relativ schnell, z.B. Autos, Bretter oder Stahl können dagegen sehr viel länger lagern.

[Wurzelgnom]

zum Umweg

Die Entfernung selber braucht eigentlich nicht berücksichtigt zu werden.

Es ist eine Tatsache, das der kürzesete Weg nicht der Schnellste sein muss.

Terminfracht heist praktisch: bring meine Waren bis Zeit X an ihr Ziel
Womit und über welchen Weg ist dabei irrelevant.

Je schneller nun ein Fahrzeug ist, desto größere Umwege kann ich fahren und bekomm trotsdem noch genügend Einnahmen, wenn ich in der vorgegebenen Zeit liefere.
Hier bekommen dann Schnellfahrstrecken (Autobahn, Hochgeschwindigkeitsgleise) als Hauptachsen auf der Karte ihre Berrechtigung.

Wird die Lieferzeit überschritten, kanns auch einen negativen Bonus geben. Analog den Vertragsstrafen bei zu später Lieferung.

die Bezugszeit wäre: langsamstes Fahrzeug auf kürzesten Weg


Da Passagiere und Post Einzelfracht ist, ist eine Trennung von Passagieren/Post und Gütern beim Bonussystem möglicherweise nötig.

[prissi]

Die Zeit, die ein Zug braucht, ist aber leider von der Zahl der Bildschirmupdates abhängig; je weniger je schneller. (Im Extremfall kann es sein, dass ein Zug einen Hang überhaupt nicht mitbekommt, sondern dort einfach rüberspringt.) Aber die Diskussion geht vermutlich in die richtige Richtung.

Nur den Bonus auf das langsamste Fahrzeug zu beziehen macht meiner Meinung wenig Sinn. Ich wollte sowieso die Boni auf eine Tabelle umstellen, die dann pakspezifisch ist in nicht mehr von der Zahl der gerade installierten Lokomotiven abhängt. Dann sollte man den Bonus auf die Tabelle beziehen.

Die Idee, den Timer mit der mittleren Wartezeit zu starten, finde ich gut. Das lässt sich dann auch programmtechnisch recht leicht umsetzen.

[Hajo]

Original von prissi
Die Zeit, die ein Zug braucht, ist aber leider von der Zahl der Bildschirmupdates abhängig; je weniger je schneller.

Das darf eigentlich nicht sein. Aktionen waren an die vergangene Zeit gekoppelt, mit Absicht, und nicht die Darstellungsrate. D.h. egal ob eine hohe oder niedrige Framerate, der Zug ist immer gleich schnell in Kacheln pro Sekunden (wobei hier echte Sekunden gemeint sind, nicht Spielzeit).

Wurde das geändert? Ich fand es wichtig, dass aktionen im Spiel nicht von der geschwindigkeit des PCs eines Spielers abhängig sind, sondern nur von der real verstrichenen Zeit. Das hat nicht mit allem 100%ig geklappt, aber Fahrezugbewegung war an die Echtzeit gekoppelt, da bin ich sicher, und zumindest die späten meiner Versionen sollten fast alle Aktionen an Echtzeit gekoppelt gehabt haben.

Das problem Start und Ziel pro Ware zu speichern ist aber immer noch ungelöst, da es die Gruppierung der Waren nach Ziel egal von welchem Start unmöglich macht, und das wirklich die Komplexität sehr erhöht. Aber es kann bei jeder Vereinigung von Warenpaketen eine Aktion ausführen (Also Start A und Start B mit Ziel Z treffen sich in C, werden dort vereinigt -> in diesem Moment kann für den Unterschied A/B eine Aktion ausgeführt werden). Bislang ist das eine Auszahlung, könnte für das vereinigte Paket aber auch eine Datenänderung sein die weiter mitgeführt wird. Eventuell hilft das, eine brauchbare Lösung zu finden?

[Kasei]

prissi: das spiel gibt unten links doch ein datum mit tag und uhrzeit aus, draus sollte sich doch ein zeitwert berechnen lassen, der immer gleich ist egal wie schnell das spiel in realtime läuft (Hänger etc)

frank, wenn ich dirch richtig verstehe meinst du sowas: es wird fracht erzeugt,wir haben jetzt zeit J, ziel ist X entfernt, daraus rechnet sich dann eine Zeit T zu der die fracht am ziel angekommen sein muss, sind wir früher gibt es mehr geld sind wir später müssen wir vll sogar was zahlen?

Zielzeitmodell:

Zielzeit:

T könnte man aus J+X/(mindesttransportgeschwindigkeit fuer eine frachtart) berechnen und diese mindestgeschwindigkeit dann in einer tabelle speichern und aus werten in den good.x.pak auslesen. damit wäre es dann sache der pakdesigner wie schnell sie die jeweilige Ware transportiert haben wollen.

das ist garnicht schlecht, spart die distanzregelung.

T wird dann wieder gewichtet gemittelt wenn man pakete zusammenfasst, also T_neu=(N_alt*T_alt+N_dazu*T_dazu)/(N_alt+N_dazu);

die einnahmen würden dann nur noch ausgezahlt wenn die fracht ihr letztes ziel erreicht.
dh es wird sehr schwer zu sagen ob ein einzeler zug nun gewinn macht oder nicht, da die einnahmen nur das letzte verkehrsmittel bekommt. dies bedeutet das viele infos die jetzt ermittelt werden nichtmehr passen, so werden zb die hauptzuglinien nur verlust machen, da sie ja nur sehr selten fracht an ihrem letztendlichen zielort bringen.

bei solchen zügen muss man dann mehr auf die auslastung schauen ob sie vernünftig fahren.

Einnahmen könnten wenn wir uns fuer das system entscheiden so berechnet werden:

G=geldfaktor, gemessen in Geld pro fracht und zeit

Einfachste methode:
Linear:
E=(T-J)*G*N //linearer verlauf. für jede zeiteinheit die man vor T da ist bekommt man G*N geld; für jede die man zuspät ist muss man G*N zahlen.

etwas bessere Methode:
Linear+Grundbetrag:
E=((T-J)*G+G_grund)*N linearer verlauf wie oben. allerdings bekommt man fuer jede frachteinheit auf jeden fall G_grund an Geld, und kann sich somit auch erlauben ein wenig später zu kommen, allerdings wird damit schneller sein nicht mehr ganz so stark bewertet.

es gibt noch ein paar andere möglichkeiten.

Fazit
prinzipiel ist diese möglichkeit nicht so aufwenig, als das verwenden von Zeit und Distanz, allerdings dürften dann die ganzen Einnahmen bei den Zwischenverkehrsmitteln nichtmehr aussagekräftig sein, da diese keine Einnahmen bekommen.

[prissi]

@Hajo:
Nein, das wurde nicht geändert. Nur, wenn das Spiel mit 10 fps läuft, ist die vergangene Zeit eine andere als mit 30 fps. Daher kann es sein, das mit 30 fps der Zug sechsmal auf der Neigung ist und mit 10 fps nur viermal (übertrieben), was zu unterschiedlichen Zeiten für die Gesamtstrecke führt. Das war schon immer so, nur fällt es nicht auf, bis ich mal für Netzwerkvorstudien zwei Spiele auf unterschiedlichen Rechner laufen ließ: In den langsameren Rechner hatte dann ein Bus die Kreuzung einen Tick eher erreicht und damit das ganze Spielgeschehen leicht verändert. Dramatisch ist der Effekt nicht.

Für alle anderen
Der Effekt kommt dadurch zustande, das eine Geschwindigkeit berechnet wird und dann der Fahrzeugverband entsprechend dieser Geschwindigkeit weiterbewegt wird. Bei häufigen Bildschirmupdates wird es oft nur ein Schitt sein, bei hängern (oder nach dem Speichern) sind es manchmal ganze Kacheln. War das gerade ein Hand im Weg, dann geht es den auch mit konstanter Geschwindikeit hinauf, während mit vielen Bildschirmupdates der Zug wesentlich schneller langsamer wird.

Ich denke, wenn man für jede Warenverbindung einen mittlere Zeit für alle Pakete nimmt, dann kann man auch damit Pakete vereinigen. Dann haben die zusteigenden Passagiere/Waren halt schon zusätzlich zur Fahrzeit diese Zeit gewartet für die Bonusberechnung.

Nur fürchte ich, dass so praktisch alle Passagiervebindungen am unteren Limit hängen werden, es sei denn Direktverbindungen. Auch würde das Sternverbindungen stark gegenüber Ringverbindungen bevorzugen.

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?

[Hajo]

@Prissi:

Ok, ich habs begriffen ... das ist knifflig, da die Geschwindigkeit zuerst berechnet wird und dann der Zug bewegt. Eine einfache Lösung will mir nicht einfallen, ausser die ganze Berechnung in einen simulierten Raum zu verlegen wo der Zug in idealer Geschwindigkeit fährt und die Darstellung komplett davon zu entkoppeln.

Also statt sync_step() mit der Bildschirmate einen fixed_step() der z.B. 10ms entspricht und in sync_step() dann so oft aufgerufen wird, wie in echt an Vielfachen von 10ms vergangen sind ... oder so ähnlich.

Hmm ... Design Fehler von mir o.o

[whoami]

Original von Kasei
die einnahmen würden dann nur noch ausgezahlt wenn die fracht ihr letztes ziel erreicht. (...) bei solchen zügen muss man dann mehr auf die auslastung schauen ob sie vernünftig fahren.

Ja, das alte Problem der richtigen Zuweisung von Kosten und Leistungen. Hatte ich mal wieder vergessen.

also noch ein paar Überlegungen:
1. Entkopplung von Standardtarif und (Speed-)Bonus:
- Standardtarif: nach Entfernung; Berechnung+Auszahlung bei Umsteigen/Umladen (oder wie jetzt bei jedem Zwischenhalt)
- Bonus wie schon vorgeschlagen: Berechnung nach Entfernung; verfällt mit der Zeit; Auszahlung am Ziel (wird aber nicht dem Gewinn des letzten Fahrzeugs zugeschlagen)
Vorteil: realistische Berechnung des Speed-Bonus
Nachteil: Zusatzertrag durch schnelle Fahrzeuge ist nicht bei diesen sichtbar

2. Entkopplung von Fahrkartenerlösen und Rentabilitätsberechnung:
- ein Fahrzeug erhält bei Transportleistung für eine Teilstrecke nicht Geld, sondern Punkte je nach Fahrleistung (=Distanz), Kapazität, Auslastung, Geschwindigkeit, Frachttyp (wie bisherige Erlösberechnung, mit Bonus)
- der Gesamt-Transporterlös des Unternehmens wird nach Punkten auf die Fahrzeuge verteilt (neue Fahrzeuge/Linien zunächst weglassen)

Schöner wäre natürlich eine Art Rückverteilung des Erlöses eines Pakets auf die leistungserbringenden Fahrzeuge, aber da finde ich keine (Näherungs-)Lösung, die das Datenvolumen nicht deutlich aufbläht.
Nachzuweisen, daß die Verteilung aus einem großen Topf sinnvolle Ergebnisse liefert, ist auch schwer.

[Wurzelgnom]

Original von Kasei
...
frank, wenn ich dirch richtig verstehe meinst du sowas: es wird fracht erzeugt,wir haben jetzt zeit J, ziel ist X entfernt, daraus rechnet sich dann eine Zeit T zu der die fracht am ziel angekommen sein muss, sind wir früher gibt es mehr geld sind wir später müssen wir vll sogar was zahlen?
...

so in etwa
___________________________________

Da immer wider die Passagiere angeführt werden.

Grundlegend ist es doch so,

Passagiere/Post - Einzelfracht mit vielen Einzelquellen und -zielen
Waren - Massenfracht mit recht wenigen Quellen und Zielen.

Deshalb sollte hier eine Trennung erfolgen.
___________________________________

Was spricht eigentlich dagegen, für den Bonus einen extra Kontoposten zu schaffen.

Für die Teilstrecken bleibt das jetzige Verhalten mit der Teilauszahlung bestehen. Nur das vom Preis ohne Bonus ausgegangen wird.

Die Ware sucht sich einen Weg zu Ihrem Ziel. Diese Daten werden wohl so lange festgehalten, wie die Verbindung besteht. Zumindest vermute ich mal, das das jetzt schon so ist.

Nun liese sich diese Verbindung anzeigen und ihr der Bonus zurechnen.

Kohle Grube XY -> KKW ZH = Bonus: +/-
oder
Kohle Station A -> Station X -> Station Z = Bonus: +/-

Bei Variante B kann der Spieler dann auch Fehlleitungen von Ware erkennen und eingreifen.