güterverkehr mit speedbonus in pak64

[Gotthardlok]

Von mir noch einige Gedanken zu diesem Thema:

- Falls die Null-Bonusgeschwindigkeit weiterhin anhand verfügbarer Fahrzeuge berechnet wird, löst er nicht das Problem, dass ab ca. 2000 der PV viel schneller fährt als der GV, und dass Triebzuggarnituren die Basis stark nach oben ziehen (viele angetriebene Wagentypen pro Garnitur, der jeder wie ein einzelner Loktyp gewertet wird).

- Falls es einen Malus für den Umweg gibt, müsste dieser vollständig vor dem Umsteigen bzw. "Mergen" greifen, sonst geht beim Zusammenfassen von Passagieren mit gleichen Zielen Information verloren. Noch besser, es wäre somit irrelevant, woher Teile eines gemergten Pakets kamen - das spart Information.

- Umwege werden als "Schlecht" beurteilt; aber stellt euch ein Szenario vor, wo Streckenunterhalt viel teurer als Laufkosten sind, im Gegensatz zum pak64.

- Auf Wartezeiten hat man nur bedingt Einfluss; da bräuchte es meiner Meinung nach schon ein gutes Tool für richtige Fahrpläne und Fahrstrassenbelegung (3-Minuten-Zugfolge), um wirklich organisiert Abhilfe zu schaffen, besonders, wenn Infrastruktur teuer ist.

- Ergebnisse abhängig von Variablen im Nenner sind mit Kopfrechnen nicht sonderlich gut nachvollziehbar, es ist schwieriger, ein Gefühl über den tatsächlichen Einfluss zu bekommen.

[whoami]

Original von Gotthardlok
- Falls die Null-Bonusgeschwindigkeit weiterhin anhand verfügbarer Fahrzeuge berechnet wird, löst er nicht das Problem, dass ab ca. 2000 der PV viel schneller fährt als der GV, (...)

Die Einführung einer pak-eigenen Tabelle (auch hier besprochen) würde dabei auch schon helfen. Überlegenswert wäre in der Tat, ob für bestimmte Frachttypen (auch in der Tabelle) noch eine eigene Referenzgeschwindigkeit festgelegt werden können sollte.

Falls es einen Malus für den Umweg gibt, müsste dieser vollständig vor dem Umsteigen bzw. "Mergen" greifen

Die Berechnung innerhalb eines Convois ist die am ehesten praktikable Lösung. Wenn dann der Umweg darin besteht, dass der Umsteigehalt (Übergang zum nächsten Convoi) weitab liegt, kann es sogar passieren, dass der anliefernde Convoi kein (oder sogar ein negatives) Einkommen erhält, je nachdem, wie stark man den Umweg anrechnet.

Umwege werden als "Schlecht" beurteilt; aber stellt euch ein Szenario vor, wo Streckenunterhalt viel teurer als Laufkosten sind, im Gegensatz zum pak64.

Das ist gerade ein Fall, in dem der Spieler ein effizientes Netzwerk benötigt - er kann nicht für jede Verbindung eine eigene Trasse anlegen (arme KI-Spieler), auch wenn das den Erlös pro Verbindung maximiert. Die Fahrpreise (im Verhältnis zu den Kosten) müssen hier genug Luft lassen, damit eine Verbindung auch rentabel ist ohne Verwendung der kürzesten Fahrtstrecke.

Auf Wartezeiten hat man nur bedingt Einfluss

Diese zu berücksichtigen ist eh nur mit einer Historie pro Warenpaket möglich, und sei es ein Summen-/Durchschnittsfeld.
Aus eigener Erfahrung ist es wirklich so, dass man von der Nachfrage überrollt werden kann, das ist dann aber i.d.R. lukrativ. Ohne eine Möglichkeit, etwas wie Taktzeiten zu simulieren, ist immer wieder ein Eingreifen erforderlich bei Streckenüberlastung und Aufstauen von Fahrzeugen derselben Linien (was für hohe durchschnittliche Wartezeiten sorgt).

[Kasei]

Original von Gotthardlok
- Auf Wartezeiten hat man nur bedingt Einfluss; da bräuchte es meiner Meinung nach schon ein gutes Tool für richtige Fahrpläne und Fahrstrassenbelegung (3-Minuten-Zugfolge), um wirklich organisiert Abhilfe zu schaffen, besonders, wenn Infrastruktur teuer ist.

- Ergebnisse abhängig von Variablen im Nenner sind mit Kopfrechnen nicht sonderlich gut nachvollziehbar, es ist schwieriger, ein Gefühl über den tatsächlichen Einfluss zu bekommen.

Wartezeiten kann man allgemein recht gut abschätzen.
siehe hier:

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.

wartezeit in sekunden. ^^ unabhängig von beschleunigungszeiten.
Besser noch: bei einem Zug ist Wartezeit etwa halbe zeit bis zum wieder eintreffen eines zuges am bahnhof.
2Züge wartezeit nur noch halbe fahrzeit(zeit von A->B),
4Züge wartezeit nur noch ein viertel der fahrzeit, oder eben 20% der gesamtzeit.

Erstmal terminologiesachen: Ziwschenhalt ist der Umstiegshalt. nicht der nächste stop eines zuges!
Umweg ist die strecke die im gegensatz zu einer direkten verbindung zuviel gefahren wird. diese felder zählen dann vll nur 90% zum weg dazu oder so. eben ein bischen das es etwas bringt direkter zu bauen, aber nicht soviel das ein convoi der umwege fährt, weil es schöner aussieht oder die karte nicht anders hergibt. immer noch gewinn macht.

Orignal von Whoami
Aus eigener Erfahrung ist es wirklich so, dass man von der Nachfrage überrollt werden kann, das ist dann aber i.d.R. lukrativ. Ohne eine Möglichkeit, etwas wie Taktzeiten zu simulieren, ist immer wieder ein Eingreifen erforderlich bei Streckenüberlastung und Aufstauen von Fahrzeugen derselben Linien (was für hohe durchschnittliche Wartezeiten sorgt).

naja das erfordert nur ein höheres mas an streckenplanung, schon mal überlegt warum vor haubtbahnhöfen wo sich mehrere linien treffen (siehe mannheim,frankfurt zb) so riesige gleisanlagen liegen? das hat ganz entscheidend was mit dem problemlosen störungsfreien verkehrsfluss zu tun. und sowas darzustellen ist doch gerade auch ein ziel einer transportsimulation. Vorzu haben wir nun auch die schönen endofchoose signale

dsas die gängige praxis einer bahnhofgestalltung aus parallen linien mit einer querverbindung vor und hinter den bahnsteigen dann nicht mehr ideal ist sollte man einsehen. Wartegleise vor bahnhöfen, oder mehr bahnsteige in banhöfen geben dann vll auch ein realistieres bild eine bahnhofsanlage.

Die Einführung einer pak-eigenen Tabelle (auch hier besprochen) würde dabei auch schon helfen. Überlegenswert wäre in der Tat, ob für bestimmte Frachttypen (auch in der Tabelle) noch eine eigene Referenzgeschwindigkeit festgelegt werden können sollte.

fuer unterschiedliche frachtarten unterschiedliche revgeschwindigkeiten festzulegen ist durchaus sinnvoll, ist in einem system mit vergleich der aktuellen zu einer revgeschwindigkeit, durchaus sinnvoll.
Kohle mir 200kmh zu transportieren erscheint mir nicht sinnvoll. Passagiere würden das doch bevorzugen.
Was man nicht braucht sind unterschiedliche revgeschwindigkeiten der selben fracht fuer unterschiedliche wegtypen. bekommt ein bus der 40kmh fährt nur 0.1 $ pro passagier der zug der 160 fährt aber 0.4$ gibt man dem bus eben nur betriebskosten von 0.06*kapazität und der zug 0.32$*kapazität. bus macht dann bei 60%auslastung gewinn, der zug bei 80%, dafuer wenn er voll fährt doppelt soviel gewinn pro fahrgast wie der bus.

Noch ein kleines zitat von prissi aus dem englischen forum :

No, the speed bonus does not depends on the time it took to travel (although I would think this would be much more interesting), but on the vehicles topsspeed, al written in the cited topic.

hier der beitrag(von 2005)

[whoami]

Original von Kasei
Wartezeiten kann man allgemein recht gut abschätzen.

Du gehst davon aus, dass der jeweils abfahrende Convoi alle mitnehmen kann. Das ist bei einem überlaufenden Knotenpunkt nicht gegeben.
Es sollte zwar auch ein Anreiz für 'echte' gute Taktzeiten bestehen, statt nur einen Mittelwert zu nehmen, aber diese sind derzeit wiederum nur mit manuellen Eingriffen (oder bestimmten anderen Maßnahmen) möglich, also erstmal zurückstellen.

Vorzu haben wir nun auch die schönen endofchoose signale

Wichtig für realistische Bahnhöfe war/ist Einführung des PBS.

Was man nicht braucht sind unterschiedliche revgeschwindigkeiten der selben fracht fuer unterschiedliche wegtypen.

Zumindest Schiffe brauchen eine Sonderbehandlung, sonst sind z.B. Fähren sinnlos oder unrealistisch (ist natürlich eine Frage dessen, was im Pak steht).

No, the speed bonus does not depends on the time it took to travel (although I would think this would be much more interesting), but on the vehicles topsspeed, al written in the cited topic.

Sag´ ich doch.

(Vor Benutzen eines Forums sollten einem die "Rechte verlesen werden", insbesondere der Teil "alles, was sie schreiben, kann für alle Zeiten in jedem erdenklichen Kontext gegen sie verwendet werden".)

;-)

[Kasei]

ich gebe zu die abschätzungen gelten nur unter gewissen bedingungen, allerdings sollten abweichungen bei einem großzügigen gewichtung von S1 gegenüber den Betriebskosten auch etwas größere wartezeiten zulassen.
Ansonten kann man auch abschätzen was bei einer gewissen grundmenge an wartender fracht passiert.
Prinzipiel liese sich auch die wartezeit ausklammern und nur die reine fahrzeit benutzen, eventuell könnte der pakersteller auch zwischen beiden varianten umschalten.

[Bown]

* Bown wirft ein Frage in den Raum

Ist es möglichüber die Settings/Optionen beide System, also das Akutelle sowie das "Kasei" System, verfügbar zu machen....

dann können die spieler inform von feedback mitteilungen entscheiden was besser ist... zumal Kasei sich ja bereit erklärt hat die Programmierarbeit komplett zu übernehmen weshalb ich da kein Problem für die weiterentwicklung Simurtans sehe...

wie seht ihr das denne???

[whoami]

Original von Bown
Ist es möglich über die Settings/Optionen beide System (...)

Wie Prissi schon schrieb: die Kalkulation umzustellen (in welcher Art auch immer) macht das Pak-Set zur Baustelle. Daher muss die Berechnung konfigurierbar sein, inkl. den Gewichtungen etc..

[Kasei]

ja es ist möglich, allerdings kann der user das nicht entscheiden, sondern der pak_entwickler, den der muss ja die betriebskosten, good.x.paks ändern und eventuell an das neue system anpassen. ich sollte es so hinbekommen können das per default das alte system benutzt wird, so kann man dann immer noch mit den aktuellen pak_sets spielen. und in der simuconf oder über die versionsnummer des paksets wird dann umgeschalten, es ist dann nur etwas mehr code, und den "nachteil" das ware_t etwas mehr daten enthält, und dadurch das spiel etwas langsamer laufen wird.

Das Kasei system braucht auf jeden Fall neue good.paks denn dort werden ja die factoren festgelegt. Wobei man Werte finden kann so das man erstmal spielen kann ohne das sich die fahrzeugbetriebskosten ändern.
Da die good.pak nur einfach umgewandelte datfiles sind kann die mit einer erklärung auch jeder selbst ändern.

[Bown]

es währe also möglich mit entsprechender "arbeit"...

hört sich zumindest gut an... stellt sich dann die frage ob die pakentwickler bereit sind "zwei" goods anzulegen... (zumin. in den hauptpaks)

[Kasei]

2 good.paks reichen nicht, man muss bei anderen einnahmen auch die betriebskosten und so weiter ändern.
im enteffekt ist es dann dem pakentwickler überlassen ob er das eine oder das andere system benutzt und der spieler kann dann indem er zwischen paksets wählt das system wählen.