güterverkehr mit speedbonus in pak64

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