güterverkehr mit speedbonus in pak64

[prissi]

Was mir an dem zeitabhängigen System nicht gefällt:
- Es zwingt mich, alle Bahnhöfe schnell zu bedienen. Lange Züge/große Schiffe sind demnach stark benachteiligt. (Seehe auch OTTD.)
- Sterne werden gegenüber Ringen bevorzugt.
- Das ganze wird für den Spieler undurchschaubarer.

Denkanstoß: In der Realität kostet ein Ticket immer dann weniger, wenn eine Verbindung und alle Zwischenverbindungen nicht ausgelastet sind. Das Umzusetzen ist jedoch höchst schwierig (programmtechnisch).

Dann muss man die ketzerische Frage schon stellen, was ein anderes System denn an Spieltiefe bringt? Egal was ich tue, entweder zwinge ich dem Spieler was auf oder ich schwimme eh in Geld und kann schalten und walten wie ich will.

Im Falle des individuellen Speedbonus ist m.E. die Bilanz negativ. Und ich habe mit dem obigen Posting keineswegs Totschlagargumente liefern wollen, sondern nur darauf hingewiesen, wie einfach der jetzige Speedbonus zu deaktivieren ist.

[whoami]

Original von prissi
Was mir an dem zeitabhängigen System nicht gefällt:
- Es zwingt mich, alle Bahnhöfe schnell zu bedienen. Lange Züge/große Schiffe sind demnach stark benachteiligt. (Seehe auch OTTD.)

Stimmt schon, aber das ist auch ein (gewollter) Malus für die häufig überlaufenden Knotenpunkte und zu große Taktzeiten. Wobei Züge und Flugzeuge das durch ihre Geschwindigkeit wieder wettmachen.
Schiffe haben natürlich erst recht ein Problem wegen ihrer geringen Geschwindigkeit. Deswegen ist ein Sockelbetrag nötig, oder Schiffe bekommen eine Sonderbehandlung, z.B. einfach ein Faktor nach Wegetyp oder Fahrzeugtyp (wenn sie nämlich in der Realität die einzige Verbindung darstellen, können sie geeignete Fahrpreise bekommen).

Sterne werden gegenüber Ringen bevorzugt.

Wie geschrieben: Umwege können voll oder anteilig mitberechnet werden. Man muss den Erlös auch nach gleicher Gewichtung berechnen (bei Abrechnung nach Weg), bzw. beim Zeitmodell einfach sagen: wenn der Umweg nötig ist, OK, aber einen Bonus gibt es dafür nicht.

Bei meinem Modell geht es eigentlich nur darum, dass ich nicht in jedem Warenpaket eine ganze Historie mitführen muss, sondern diese durch Zahlengewichte zu simulieren versuche.

Das ganze wird für den Spieler undurchschaubarer.

Besonders wenn das Modell bzw. die Stellgrößen nicht stimmen.

Denkanstoß: In der Realität kostet ein Ticket immer dann weniger, wenn eine Verbindung und alle Zwischenverbindungen nicht ausgelastet sind. Das Umzusetzen ist jedoch höchst schwierig (programmtechnisch).

Erst recht, wenn die Routenwahl zusätzlich abhängig werden soll von Fahrtzeit und Preis.

Dann muss man die ketzerische Frage schon stellen, was ein anderes System denn an Spieltiefe bringt?

Nee, die Ketzer sind wir anderen, weil wir das vorhandene System in Frage stellen. ;-)

Es geht um mehr Realitätsnähe. Das jetzige System hat ein paar Wirkungen, die mir nicht zusagen:
- Berechnung nach theoretischer Höchstgeschwindigkeit (leicht abzustellen)
- sehr schnelle Fahrzeuge bringen sehr viel Erlös (nicht gedeckelt), selbst wenn es sich für den Reisenden gar nicht so sehr lohnt (weil der Rest der Strecke langsam bedient wird)
- große Umwege bringen großes Geld (=> Malus für effiziente Netzwerke, z.B. auch ein Backbone mit Sternen dran)
- lange Wartezeiten (für Passagiere und zeitkritische Güter) tun dem Anbieter nicht weh

[Wurzelgnom]

Original von whoami
...

Vll habe ich Prissis Antwort nur falsch verstanden, aber fuer mich hörte sich die auch so an wie: Das System ist ok wie es ist, wems nicht gefällt der kanns ja einfach ausschalten!

Und wenn die separate Tabelle kommt, kann man es dort abschalten oder ändern (d.h. schummeln ;-) ), ein Schalter in simuconf.tab wäre auch einfach einzurichten, aber allein auf den Bonus zu verzichten bringt ja nur Nachteile.
...

Die Tabelle liese sich auch binär mit Makeobj in eine Pak-Datei schreiben.

[Kasei]

zu whoami:

Um ehrlich zu sein: ich habe etwas Mühe, dem Thread zu folgen (genauer: Deinen Ausführungen - das liegt natürlich an mangelnder Quellenkenntnis meinerseits), daher ist mir derzeit nicht ganz klar, wie das vorgeschlagene System aussieht. Daraus entstammen auch die Überlappungen zwischen Deinen und meinen Vorschlägen - betrachte sie einfach als Zustimmung meinerseits. ;-)

Lies am besten nur den Teil ab Erläuterungen, hoffe dort alles wesendliche geschrieben zu haben. vll sollten wir ein bild machen, anhand dessen wir verschiedene modelle durchgehen können. Vll wirkt es deshalb komplizierter als es ist, weil ich mich schon mit der Programmtechnischen Umsetzung auseinander gesetzt habe.

Wenn du mal versuchst deinen Vorschlag programmtechnisch umzusetzen wirst du wohl mehr speichervariablen brauchen als ich ihn meinem.

Abrechnung am Ziel -> Fracht muss entweder startort und startzeit kennen oder gebrauchte zeit und zurückgelegte strecke.
Willst du das erst ganz am ende machen, und Zügen dann irgendwie fuer ihre leistung entlohnen kommt es zu dem problem, das bei manchen zügen ihr Auslastung hoch ist sie aber mehr oder weniger nur einem umweg fahren und so im enteffekt nichts verdienen, aber der auslastung aber profitabel aussehen.

zu Prissi:

- Es zwingt mich, alle Bahnhöfe schnell zu bedienen. Lange Züge/große Schiffe sind demnach stark benachteiligt. (Seehe auch OTTD.)

Richtig, denn wer will lange Wartezeiten. Lange Züge sind nur dort sinnvoll wo hohes Aufkommen herrscht. Aber ich gebe zu, das System würde es zumindest schwer machen Lange Züge auf kaum befahren Strecken einzusetzen. da diese dort die meiste Zeit warten.
probleme kann bei einer zu starken zeitabhängigkeit(inclusive wartezeit) der kurzstreckige nahverkehr sein, da hier die fahrtzeit kurz ist. Aber auch hier ist das in der Realität nicht anders, Nahverkehr ist seltens Profitabel.

- Sterne werden gegenüber Ringen bevorzugt.

Nicht Sterne sondern Direkte Verbindungen, aber nur wenn man einem Umweg nicht voll wertet. zählt er genauso zu Strecke dazu kommt es nur auf die geschwindigkeit an.

- Das ganze wird für den Spieler undurchschaubarer.

Das verstehe ich nicht ganz? Er sieht noch immer welche Züge gewinnmachen, und welche nicht. Ein Hinweis das sich das abrechnungssystem geändert hat und wartezeiten mit einkalkuliert werden müssen sollte man selbstverständlich geben.
Ich gebe gerne zu, im Speed Bonus System(wie auch immer man nun genau Rev_speed festlegt) kann man dank der warenliste gut entscheiden wann ein zug profitabel ist und wann nicht. Allerdings kann man selbiges (Gewinn pro Feld bei Geschwindigkeit x) auch in meinem System angeben und hat so das selbe Kriterium,

Dann muss man die ketzerische Frage schon stellen, was ein anderes System denn an Spieltiefe bringt? Egal was ich tue, entweder zwinge ich dem Spieler was auf oder ich schwimme eh in Geld und kann schalten und walten wie ich will.

Wichtig ist fuer mich bei einem System, das der Pak-Gestallter, oder der Spieler selbst entscheiden kann wie kompliziert/"zwanghaft" er es haben will.
Deshalb hatte ich bei mir 3 Faktoren, einer für Gewichtung von Umwegen, die 2 anderen zum Gewichten der zeit, zwischen reiner zeitabhängigkeit und keiner zeitabhängigkeit. All diese gibt der Pakentwickler vor, nicht das Spiel

In der Realität wird der Preis von allem diktiert aber nicht von Angebot und Nachfrage. Zumindest in Deuschland nicht. Ausserdem spielen ja noch die Kosten einer Verbindung eine Rolle. Und der Preis + Komfort einer Verbindung erzeugt auch eine Nachfrage auf einer Linie. (spätere erweiterung dahingehend das frachterzeugung von preis und komfort einer verbindung abhängt und der spieler den preis selbst bestimmen kann, dies ist allerdings noch weit komplexer)

In einem Zeitabhängigen System liese sich auch recht leicht die Wartezeit durch die einstiegszeit/verladezeit ersetzen, und man hat eine genauere Ermittlung der Geschwindigkeit, als jetzt min_top_speed zu verwenden.

PS Konstanter Rev_speed ist ok fuer mich, werde später oder morgen dennoch ein bild mit einer beispielrechnung von meinem system hier rein stellen, da ich es wohl doch nicht gut beschrieben habe.

PPS, Prissi, wie messe ich in simutrans am geschicktesten die Leistung, also ob eine Änderung simutrans langsamer macht oder nicht?

Edit: Die erfassung von Umwegen ist bei weitem nicht so einfach wie ich dachte, dh sie ist rechentechnisch sehr viel aufwenidiger -> im Moment denke ich Umweg sollte genauso zur zurueckgelegten Distanz zählen wie der eigentliche Weg, kann sich aber morgen wieder ändern, falls ich ein gutes System finde Umwege zu erfassen, das von mir auf seite 2 beschrieben verfahren funktioniert auf jeden Fall nicht. Und speichern von Startkoordinaten geht auch nicht um am Ziel die zurueckgelegte Distanz zu haben, da man diese nicht vereinigen kann.
...
eventuell könnte man beim start schon die distanz ermitteln, aber dabei würden dann umwege nicht mehr bei der zurückgelegten distanz berücksichtigt.
Es scheint alles fuer einen Konstanten rev_speed zu sprechen da er am einfachsten umzusetzen ist, und programmtechnisch nicht viele Änderungen erfordert.

[whoami]

Original von Kasei
Wenn du mal versuchst deinen Vorschlag programmtechnisch umzusetzen wirst du wohl mehr speichervariablen brauchen als ich ihn meinem.

So weit liegen unsere Ansätze nicht auseinander. (Mein letztes Posting beschrieb die eigentliche Kalkulation nicht, das war vorher.)

Abrechnung am Ziel -> Fracht muss entweder startort und startzeit kennen oder gebrauchte zeit und zurückgelegte strecke.

Anders: es können (in aggregierbaren Warenpaketen) diese Variablen auftauchen:
- Fahrpreis (berechnet zu Beginn => nach oben beschränkt - verfällt mit der Zeit, Auszahlung am Ziel) -> Bonus (nur positiv)
und/oder
- bisherige Wegstrecke (gewichteter Mittelwert von Luftlinie und gefahrenem Weg) (berechnet am Ziel; nicht zu Fahrtbeginn, weil das Verlieren der Ladung bestraft werden muss, EDIT: UND weil die Route erst am Ziel definitiv bekannt ist) -> Sockelbetrag
EDIT: wenn es eine zugesicherte durchschnittliche Transportzeit gibt (festzulegen nach Warentyp, Kartengröße, Jahr), auch wahlweise:
- seit Erzeugung vergangene Zeit, besser durchschnittliche Erzeugungszeit (auch die ist aggregierbar)

Willst du das erst ganz am ende machen, und Zügen dann irgendwie fuer ihre leistung entlohnen kommt es zu dem problem, das bei manchen zügen ihr Auslastung hoch ist sie aber mehr oder weniger nur einem umweg fahren und so im enteffekt nichts verdienen, aber der auslastung aber profitabel aussehen.

Wenn der Umweg (bedingt durch das Verkehrsnetz) notwendig ist, dann muss er auch 'belohnt' werden - aber nicht durch höheren Fahrpreis, sondern durch Umschichtung zwischen den Fahrzeugen.
Und wenn das gar nicht gewünscht ist, kann die gefahrene Strecke komplett zur Preisberechnung hergenommen werden (Gewichtung 100% sowohl für Warenpaket als auch für Fahrzeug, Luftlinie 0%).

würde es zumindest schwer machen Lange Züge auf kaum befahren Strecken einzusetzen. da diese dort die meiste Zeit warten.

Wenn beliebige Wartezeiten OK sind, dann gibt es eben nur den Sockelbetrag.

Nahverkehr ist seltens Profitabel.

Richtig: der Spieler muss sich bewusst sein, dass er quersubventioniert, weil ohne die Busse seine schnellen Zügen viel weniger Auslastung hätten. Jedes einzelne Fahrzeug zum isolierten Profit Center zu machen wäre falsch.

Deshalb hatte ich bei mir 3 Faktoren, einer für Gewichtung von Umwegen, die 2 anderen zum Gewichten der zeit, zwischen reiner zeitabhängigkeit und keiner zeitabhängigkeit.

Wir sind in der Tat nicht weit auseinander.

Es scheint alles fuer einen Konstanten rev_speed zu sprechen da er am einfachsten umzusetzen ist, und programmtechnisch nicht viele Änderungen erfordert.

Ich dachte, Du magst komplizierte Aufgabenstellungen?

P.S.: ;-)

Original von FrankP
Die Tabelle liese sich auch binär mit Makeobj in eine Pak-Datei schreiben.

Das wäre aber unfair gegenüber denjenigen, die keine Hex-Editor haben. ;-)

[Kasei]

Orginal von Whoami
Zitat:
Deshalb hatte ich bei mir 3 Faktoren, einer für Gewichtung von Umwegen, die 2 anderen zum Gewichten der Zeit, zwischen reiner zeitabhängigkeit und keiner zeitabhängigkeit.

Wir sind in der Tat nicht weit auseinander.

Das dachte ich mir auch, allerdings kam es mir so vor als brauchtest du mehr speicher als ich. *schulterzuck*

Orginal von Whoami
Zitat:
Es scheint alles fuer einen Konstanten rev_speed zu sprechen da er am einfachsten umzusetzen ist, und programmtechnisch nicht viele Änderungen erfordert.

Ich dachte, Du magst komplizierte Aufgabenstellungen?

Stimmt, daher habe ich mich nochmal dran gesetzt und eine möglichkeit gefunden

"Zum Ziel führender" Weg wird voll gewertet, umweg-felder zählen nur wayfactor mal zum weg hinzu. (denke 0,8-0,9 ist ok, dann bleibt auch beim umweg noch was hängen, aber eben nicht mehr soviel).

Hier erstmal die Erleuterungen , hinterher kommen der Programmcode.
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. Deshalb folgendes System:
Erläuterungen:
Richtung ist hier Strecke in X richtung oder Strecke in Y Richtung, nicht die Luftlinie.
Umweg ist sind die felder die ich mich entweder in die falsche richtung vom Ziel wechbewege, oder wenn ich mich in die richtige Richtung bewege aber über das ziel hinausschiese.
Bewege ich mich in die richtige Richtung Zählt einfach der Weg zur distanz dazu.
Nun der komplizierteste Teil, der mir beim ersten mal durch die lappen ging
Bewege ich mich in die richtige Richtung aber übers Ziel hinaus, so Zählt zu der Distanz hinzu, der Weg den ich mich tatsächlich aufs ziel zubewegt habe + (2*wayfactor-1) mal der zuweit uber das ziel hinaus bewegte Weg Dieser Faktor kommt daher das ich den Teil den ich über das ziel hinaus fahre ja irgendwann wieder zurueckfahre auf meinem entgültigen weg, und er dort dann als tatsächliche annäherung zählt, und ich so schon auf dem hinweg den wayfactor malus fuer den rückweg mit abziehen muss.
Am besten ein kleines Beispiel:
Halt A (0,0) , Halt B bei (100,0) und Halt C bei (50,0)
Fahrweg ist A->B->C
Von A nach B fahre ich ja in die richtige X-Richtung aber eben 50 Felder zu weit, diese 50 Felder fahre ich nachdem ich bei B war wieder zurueck, für eine Fahrt von B->C in die richtige Richtung, daher wird der Weg B->C ganz hinzuaddiert.
Weil wir aber wissen das die Fracht ja aus A kam und B->C auch Umweg ist wird auf dem Hinweg von den 50 Feldern zuviel 2mal der wayfactor-malus (1-wayfactor) abgezogen, einmal fuer den Hinweg und einmal fuer den Rückweg. Daher kommt der Faktor (2*wayfactor - 1).

Bewege ich mich in die falsche(entgegengesetzte) Richtung zählt wie eben beim zuweit gefahren Weg wieder das (2*Wayfactor-1)fache des Weges zur Distanz hinzu. (selbe Überlegung ich fahre den Weg ja später wieder zurueck.
Prgrammcodeumsetzung:

Code:

G=2*ware.gib_typ()->gib_wayfactor()-1;

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

Dx=zielkoord.x-start.x // Abstand in X Richtung,
Dy=zielkoord.y-start.y

if(dx*Dx>0)
{
if(dx/Dx>1) ware.Dist+=Dx+G*(dx-Dx);
else ware.Dist+=abs(dx);
}
else ware.Dist+=G*abs(dx);

if(dy*Dy>0)
{
if(dy/Dy>1) ware.Dist+=Dy+G*(dy-Dy);
else ware.Dist+=abs(dy);
}
else ware.Dist+=G*abs(dy);

Noch was zu der Sache mit dem Umwegen, schon jetzt werden Umwege zwischen 2 haltestellen garnicht gewertet, da in die Berechnung nur die direkte entfernung dx+dy eingeht. Dh zwischen 2 Haltstellen wird schon jetzt die Direktverbindung besser bewertet als etwaige Umwege um Hügel, Häuser etc. Und der Umweg geht hier garnicht ein, bei der rechnung oben wird er immerhin wayfactor-mal gewertet.

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

[prissi]

Also, der Erloes wird nur die Luftlinie zwischen den Stationschwerpunkten gewertet. Umwege sind daher teuer, da Fahrzeuge darauf ausgelegt sind, bei 70% Auslastung gewinn zu machen. Es sei denn, die Linie ist nahezu ausgelastet, dann lohnen sich die Umwege auf dem Ring.

Wer an diesem System ruetteln will, muss nur alle Fahrzeuge und alles was mit dranhaengt neu berechnen. Beim letzten Mal habe ich ca. 2 Wochen jeweils 4-5 Stunden pro Tag dran gesessen, bis es vernueftig war. Daher bin ich Aenderungen sehr reserviert.

@whoami
Mit der Durchschnittsgeschwindigkeit habe ich ein Problem: Ich finde nicht, dass Wartezeiten an Signalen bestraft werden sollen. Ich finde es schon richtig, dass der Spieler vorher weiss, wieviel der Zug einbringt. Das geht bei der Durchschnittsgeschwindigkeit nicht.

In der Realitaet bringt ein schneller/luxurioeser Zug mehr. Die Wartungskosten sind auch unabhaengig von der Durschnittsgeschwindigkeit.

[Kasei]

whoami, mein system macht mehr oder weniger ganz genau das, was du ,denke ich zumindest, beschreibst.

Ich rechne Ware nur zum Zwischenziel hin ab und dort bekommt das Fahrzeug sein Geld. Dies mach ich damit da es einfacher ist und am jetzigen system nicht viel geändert wird und ich nicht sehe was es bringt wenn am Ende abgerechnet wird,die summe wird sich nicht ändern ob man nach jedem zwischenziel oder erst am endziel abrechnet . Nichts kompliziertes wie Umlage von Endpreis auf alle vorher beteiligeten fahrzeuge/convois nötig.

Ich versuch es nun noch einmal ganz einfach zu beschreiben.

Für eine Ware bekommt ein Convoi sobald er diese Ware abliefert Einnahmen, diese berechnen sich aus Menge*Distanz*(S1*Distanz/(fahrzeit+wartezeit)+S2)

Über die Distanz haben wir ja nun schon mehr als genug gehört, die anderen Größen:

Distanz/(Fahrzeit+Wartezeit)= D/(J-ST)=Vr entspricht der Reisegeschwindigkeit der Ware.
Ein paar Beispiele zum einschätzen der Größe:

Vr=1 Feld/1024 ticks bei 80kmh Geschwindigkeit ohne Wartezeit.
Dies ergibt sich aus dem Programmcode, prissi hat sie stelle gesagt an der man dafuer nachschauen muss. Sprich 80kmh werden als 1Feld/Sekunde dargestellt. Alles weitere folgt daraus:

Vr=0,5 Feld/1024ticks bei 80kmh und Wartezeit(in Sekunden)=Weglänge in Feldern

Vr=2 Feld/1024ticks bei 160kmh
Vr=1 Feld/1024ticks bei 160kmh und Wartezeit(in Sekunden)=0,5*Weglänge
Vr=0,66 Feld/1024ticks bei 160kmh und Wartezeit(in Sekunden)=Weglänge

Vr=0.5 Feld/1024ticks bei 40kmh
Vr=0,25 Feld/1024ticks bei 40kmh und Wartezeit(in Sekunden)=2*Weglänge

S1 ist also sowas wie Preis pro Menge pro zurueckgelegtes Feld pro Geschwindigkeit.
S2 ist Preis pro Menge pro zurueckgelegtes Feld.

ist doch garnicht so kompliziert. alles andere dreht sich nur darum wie man verschiedene Größen im Programm ermittelt, und wie man Vereinigung von Warenpacketen hinbekommt, sodas das oben immer noch gültig ist.

Orignal von Prissi
In der Realitaet bringt ein schneller/luxurioeser Zug mehr. Die Wartungskosten sind auch unabhaengig von der Durschnittsgeschwindigkeit.

In der Realität zahlt die bahn entschädigungen wenn eine verbindung zuviel verspätung hat. Ich zahle sicher nicht den ice preis wenn der zug wegen ständigem warten an Signalen so schnell ist wie ein regionalzug. Das warten ist auch ein komfort abzug, und der sollte dann doch bestraft werden.

Orignal von Prissi
Mit der Durchschnittsgeschwindigkeit habe ich ein Problem: Ich finde nicht, dass Wartezeiten an Signalen bestraft werden sollen. Ich finde es schon richtig, dass der Spieler vorher weiss, wieviel der Zug einbringt. Das geht bei der Durchschnittsgeschwindigkeit nicht.

Wie du oben siehst, kann man sehr genau sagen wie viel man bei verschiedenen Geschwindigkeiten bekommt.
Bei einem Zug auf einer Linie gilt Wartezeit im Schnitt in etwa fahrzeit, 2 Züge: Wartezeit etwa gleich halbe fahrzeit.
bei 80kmh ist wartezeit in etwa Weglänge, bei 160 halbe weglänge, bei 40kmh doppelte weglänge.

[whoami]

Original von prissi
Also, der Erloes wird nur die Luftlinie zwischen den Stationschwerpunkten gewertet. Umwege sind daher teuer, (...)

Umweg ist m.A.n. aber auch das Fahren über einen Halt (mit oder ohne Umsteigen/Umladen), der abseits der Luftlinie liegt (bzw. mit Manhattan-Metrik: außerhalb des Rechtecks, das von Start- und Zielpunkt festgelegt wird).

Wer an diesem System ruetteln will, muss nur alle Fahrzeuge und alles was mit dranhaengt neu berechnen.

Das ist wahrlich ein Problem. Wenn nur am Bonus gedreht wird (z.B. auch mit der möglichen Umstellung auf Tabelle), sind vielleicht nur die schnellsten Fahrzeuge anzupassen.
Ansonsten gibt es bei den Vorschlägen noch einige grobe Stellschrauben:
- global und pro Warentyp
- - Erlösfaktor für Sockel und Bonus
- global:
- - Gewichtung Umweg
- - Formel für Verfall des Fahrpreises oder für eine Vertragsstrafe
- - mögliche Spezialbehandlung von Schiffen, Flugzeugen, oder Komfortbonus

In der Realitaet bringt ein schneller/luxurioeser Zug mehr. Die Wartungskosten sind auch unabhaengig von der Durschnittsgeschwindigkeit.

Es ist doch so, dass besonders schnelle Fahrzeuge tendenziell deutlich mehr im Kaufpreis und Kilometerpreis kosten - dafür braucht man dann den Bonus. Soll unterschieden werden zwischen Langsamkeit durch
- Streckennetz: Überlastung, zuviele Kurven/Steigungen, Geschwindigkeitsbegrenzungen
- andere Fahrzeuge blockieren Fahrwege
- überladenes, zu langes oder zu schwach motorisiertes Fahrzeug?
Herausrechnen könnte man das teilweise, aber das Ergebnis ist für den Kunden/Fahrgast gleich: es dauert länger. Der Spieler hat genügend Einfluß auf alle diese Bereiche, daher ist eine Unterscheidung IMO nicht nötig.

Original von Kasei
(...) und ich nicht sehe was es bringt wenn am Ende abgerechnet wird,die summe wird sich nicht ändern ob man nach jedem zwischenziel oder erst am endziel abrechnet .

Ich meine, dies gilt nur für die Berechnung nach Strecke (egal wie berechnet), oder Geschwindigkeit auf einer Teilstrecke. Das kommt mir doch bekannt vor... Das ist nämlich das, was schon implementiert ist.

Nichts kompliziertes wie Umlage von Endpreis auf alle vorher beteiligten fahrzeuge/convois nötig.

EDIT: Das genau zu berechnen ginge auch nur, wenn das Warenpaket detaillierte Informationen enthielte, und die werden je nach Modell nach oben begrenzt durch die Anzahl Fahrzeuge, also bei großen Netzen nicht akzeptabel. Bei Waren (ohne Cross-Connect-All natürlich) wäre es hingegen möglich (Franks Vorschlag).