güterverkehr mit speedbonus in pak64

[Kasei]

good.x.pak läst sich recht leicht selbst erstellen, da hierfuer ja nur ein datfile gebraucht wird und makeobj.
insofern sollte das jeder der etwas am spiel ändern will, uns sich schlaumacht wie, tun können.
(im tikiwiki von frankp steht drin wie das dat file aussehen muss fuer good-paks)
ansonten gebe ich dir recht, eine plain text file ist einfacher zu ändern. eventuell könnte man die good.x.pak ja auch als datfile lassen.

ein grund fuer den speedbonus:

Eine schnellere Lok braucht mehr Leistung um schneller zu werden. (v ~ P²)
ohne speed bonus erzeugt eine schnelle Lok genauso viel Gewinn wie eine langsame (bei gleicher Frachtmenge)(das eine schnelle Lok häufiger fährt zählt nicht, da man genausogut 2 langsame einsetzen kann um die fracht zu transportieren, wichtig ist das Einnahmen/Fracht gleich sind ohne speedbonus). Jetzt braucht eine doppelt so schnelle Lok aber 4mal mehr Leistung als eine langsame, spricht sie kann bei der alten Geschwindigkeit 4mal mehr Fracht ziehen, -> 4mal Fracht bei einmal Betriebskosten(diese sind ja fuer beide gleich) -> viel viel mehr Gewinn wenn ich leistungsstarke Loks langsam fahren lasse, als wenn ich sie schnell fahren lasse.

Dank Speedbonus (der wohl quadratisch sein muss) kann man die Betriebskosten der Lok ihrer Leistung anpassen.

(PS, mir ist bewusst das diese rechnung sehr idealisiert ist, aber sie trifft den Kern der Sache)

[whoami]

Der Bonus ist natürlich sinnvoll, damit schnellere Transporte sich auch lohnen (wie Kasei darlegt). Es ist nur (m.M.n.) nicht so sinnvoll
1. mit der Zeit das ökonomische Gefüge zu verschieben (egal ob Inflation oder Deflation), weil der Spieler dann an Stellen nachbessern muss, die eigentlich noch gut funktionieren. Bei steigendem Passagieraufkommen (größere Netzabdeckung + Städtewachstum) muss man natürlich auch so die Kapazität anpassen, z.B. mit größeren oder schnelleren Fahrzeugen; wie beschrieben gibt es Fälle (Zeiträume), in denen sich die meisten Fahrzeuge nicht mehr lohnen, weil es ein besonders schnelles Gefährt gibt. Das ist ungünstig für die Vielfalt.
2. nur nach potentieller Höchstgeschwindigkeit zu berechnen (und eigentlich auch die Berechnung pro Fahrzeug auf der Route), statt nach tatsächlicher Geschwindigkeit Start-Ziel (und sei es mit Umwegen).
Edit: Es ist für die Realitätsnähe auch wünschenswert, dass eine minimale Verkürzung der Reisezeit z.B. durch ein besonders schnelles Flugzeug keine wesentlich Rolle spielt, weil Wartezeiten und Beschleunigungsabschnitte mit einberechnet werden, aber dafür muss man eben nach Reisezeitbeginn rechnen (bzw. die Geschwindigkeit entsprechend berechnen), und sei es von Halt zu Halt.

Eine Größenänderung bei ware_t ändert zunächst einmal definitiv den Hauptspeicherbedarf und auch die CPU-Cache-Nutzung. Die CPU-Last selbst ist vielleicht gar kein so großes Problem (egal ob der Inhalt umkopiert wird oder nicht).

Eine größerer Rechenaufwand sollte mit variabler Referenzgeschwindigkeit wirklich nicht entstehen, weil diese nur bei Einführung eines neuen Fahrzeugs (entsprechend mit Tabelle) neu ermittelt werden muss - globale Variable pro Wegetyp (Edit: und eine separate Bestimmung für Straba etc. ist auch möglich).

[prissi]

Mein Senf dazu:
Die variablen Speedboni gibt es nur, wenn auch mit Einführungsdaten gespielt wird. Ansonsten ist alles wie gehabt.

Ich spiele recht selten. Doch mit dem noch langsameren Zeitverlauf, den die SPieler wollten, ist es praktisch immer so, dass nach 20 Jahren eine Strecke völlig überlastet ist und ich alle Züge dort austauschen muss. Zu diesem Zeitpunkt ist der Speedbonus nur dazu da (der ja auch nur für Passagiere, Post und Medikamente was bringt), schnellere Züge zu belohnen. Die vorigen waren ja auch ok, aber haben den Durchsatz nicht gebracht. Und für Menge müssen es meist eh die teuersten und schnellten Sachen sein.

Und wie gesagt: wen der variable Speedbonus stört, schaltet einfach die Timeline ab und gut ist.

[Wurzelgnom]

Original von prissi
...
Und wie gesagt: wen der variable Speedbonus stört, schaltet einfach die Timeline ab und gut ist.

oder nimmt das pak.german bzw. die good-Dateien daraus, sofern vorhanden

[Bown]

Ich muß zugeben das ich persöhnlich die zwei letzten antwort als absoluten blödsinn ansehe ... nur weil bonus nicht so funktioniert wieer soll... wird er nicht repariert oder geändert sondern einfach "gelöscht" in dem man sich der wichtigen datein dafür entledigt...

meinter nicht das ihr euch da bissel zu einfach macht...??? denkt ihr jeder simutrans spieler ist nen profi und weis wie er mit sowas umgehen muß???.. ich wage zu behaupten das 50% der spieler laien sind das sie evtl erst angefangen haben oder zumin. nur spielen wollen und sich wenig für die hintergründe inetressieren... wie wollt ihr für die den eine akzeptable lösung schaffen???

finds nur bissel unfair wie labidar ihr mit ideen umgeht ... da kann man im grunde auch gleich gar nix sagen das hilft evtl. mehr auch wenn das simutrans ansich wenig bringt... aber genau so sah ich das im thread bisher...

idee angesehn... für schlecht befunden... keine disskussionen oder erläuterungen zugelassen ... am ende labidar einen satz hingehauen... wenn es einen stört... man köntne es ja löschen... problem erledigt... wenn ihr so mit allen ideen umgeht dann sag ich jetzt schon gute nacht simutrans... weil 100%ig das engament das jetzt schon großteils einegschlafen ist noch mehr abebt und warum?...

denkt mal drüber nach...

[Wurzelgnom]

Original von Bown
Ich muß zugeben das ich persöhnlich die zwei letzten antwort als absoluten blödsinn ansehe ... nur weil bonus nicht so funktioniert wieer soll... wird er nicht repariert oder geändert sondern einfach "gelöscht" in dem man sich der wichtigen datein dafür entledigt...
...

Danke Bown. Ich hab nur eine Möglichkeit aufgezeigt, mit Timeline aber ohne Bonus zu spielen.


Zum einen funktioniert der Bonus wie er von prissi angedacht war. Also ist er von daher nicht kaputt.

Zum anderen ist eine Änderung ja angedacht. Ob diese Änderung die Lösung ist, wird sich zeigen müssen.
Auf jeden Fall ist eine Verlagerung aus dem Programm hin zum Pakset von Vorteil. Dies ermöglicht eine bessere Abstimmung der einzelnen Paksets.

Ausserdem
Mehr Meinungen und Kommentare bzw. Lösungsvorschläge von Anderen wären der Sache bestimmt auch dienlicher.

Kaseis Variante ist nun mal recht Komplex. Je komplexer was zu programmieren ist, des so mehr Fehler können entstehen. Und komplexe Sachen zu programmieren ist öde und macht keinen Spaß.

[Kasei]

Orginal von FrankP
Kaseis Variante ist nun mal recht Komplex. Je komplexer was zu programmieren ist, des so mehr Fehler können entstehen. Und komplexe Sachen zu programmieren ist öde und macht keinen Spaß.

mir persönlich macht es viel Spass komplexe System zu erfassen und sie zu versuchen im Rechner nachzubilden, diese zu Programmiern.

Wenn mein System für gut befunden worden wäre, hätte ich es auch selbst umgesetzt.
Bisher hat sich nur Whoami, sofern ich sein Posting richtig verstehe für etwas komplexeres ausgesprochen.
Ich akzeptiere das mein Vorschlag das Spiel wohl langsamer machen würde, und das es einfachere Möglichkeiten gibt die je nach Einschätzung "gut genug" bis "brauchbar" sind und an der Leistung vom Spiel nichts ändern.

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!
@Prissi:
Wenn du keine Lust oder Zeit hat es selbst zu programmiern, weil du genug mit bugbeheben beschäftigt bist, aber einen Patch vom jemanden der es Programmiert einfügst, sag das so. Ich hätte dazu Lust ihn zu schreiben.
Nur dazu müssen wir uns eben erstmal einigen, wie es geändert werden soll. Deshalb schreibe ich meine Ideen hier rein und Programmier nicht einfach darauf los.

[Wurzelgnom]

Leider weis man erst hinterher, ob ein System was taugt.

Ein kleiner Denkfehler und es funktioniert nicht so wies soll.
Oder etwas ausser acht gelassen, hat den gleichen Effekt.

Absturzbugs haben nun mal eine höhere Priorität. Das sollte auch nicht ausser acht gelassen werden.

[Kasei]

ich finde es super das Prissi bugbeheben Priorität einräumt. Dies ist auch wichtiger als neue Sachen einzubauen.
Und Bugs die ein Spielcrash verursachen sind schlimmer, als welche die ein spielen unter gewissen Bedingungen erschweren. (zu letzteren zählt fuer mich persönlich das jetztige System) Deshalb ist es ok, wenn er lieber Crash-Bugs behebt.

[whoami]

Original von Kasei
Bisher hat sich nur Whoami, sofern ich sein Posting richtig verstehe für etwas komplexeres ausgesprochen.

Eigentlich nicht, d.h. ich hab's nicht gerne komplex in der Implementierung (auch ich mag KISS - und damit meine ich nicht diese exzentrisch angezogene Band).
Ich favorisiere den schon beschriebenen Ansatz, den Erlös am Ziel zu berechnen, diesen in einem globalen Konto zu summieren, und den Convois ihren Anteil nach normierter Fahrleistung zuzuweisen: z.B. Gewichtung(Warentyp)*Menge*Entfernung_eff*Geschwindigkeitsbonus(Warentyp,v_eff). Umwege können, wenn gewollt, mit einer bestimmten Gewichtung positiv in die Entfernung einfließen, z.B. Entfernung_eff = (x*Luftlinie + y*Umweg)/(x+y) (<- natürlich normieren, um nur mit Integer und ohne Division auszukommen). Geschwindigkeitsbonus ist vielleicht unnötig - schnelle Fahrzeuge verwendet man am besten über lange Strecken. Und ein Komfortbonus für Passagiere wäre auch möglich. ;-)

Die Überlegung dahinter ist das Komplexe (exakter Beweis eines angenommenen sinnvollen Verhaltens ist mindestens aufwendig), und mit falscher Gewichtung pro Convoi kann man den Spieler ziemlich aufs Glatteis führen (so dass er profitable Fahrzeuge außer Dienst stellen könnte), aber die Umsetzung ließe sich m.E. mit jeweils einem Summenfeld pro Warenpaket (gewichtet durchschnittliches Erzeugungsdatum => Wartezeiten zählen mit) und Fahrzeug (Transportleistung, mit vielen Faktoren gewichtbar) erreichen, so dass auch die Rechenzeit und der Speicherbedarf akzeptabel wären.
Für das Speichern von Zeitstempeln müsste natürlich ein Lösung gefunden werden.

Edit: Unprofitable Fahrzeuge/Linien erkennt man daran, dass sie auf ihren Kosten sitzenbleiben - es geht oben um die Erlösverteilung nach Leistung.

Edit^2: Wenn man zwischen zeitkritischen (je schneller, desto mehr Erlös, aber gedeckelt, im Gegensatz zum jetzigen Bonus) und kostenkritischen (fixer Preis nach Luftlinie) Warentypen unterscheidet, gibt es für das Summenfeld im Warenpaket zwei verschiedene Bedeutungen (und zwei Berechnungsverfahren). Will man beide verwenden, dann sind halt zwei Variablen pro Paket notwendig.
Weil die Werte nicht exakt erfasst werden müssen, reicht vielleicht auch ein 2-Byte Integer pro Variable. (Das hattest Du ja vor einigen Dutzend Posts schon ausführlicher beschrieben.)

Edit^3: Und wenn man die Erlösverteilung genauer halten will, kann man global und pro Convoi den Erlös nach Warentyp separat speichern. (Zur Not auch noch pro Einzelfahrzeug, wenn man pro Wagon eine Profitabilitätsanalyse haben will, aber da genügt vielleicht die maximale Auslastung in einem bestimmten Zeitraum.)

Wenn mein System für gut befunden worden wäre, hätte ich es auch selbst umgesetzt.

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. ;-)

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.

Nur dazu müssen wir uns eben erstmal einigen, wie es geändert werden soll. Deshalb schreibe ich meine Ideen hier rein und Programmier nicht einfach darauf los.

Beim Programmieren wäre ein #ifdef für die Erlösberechnung sinnvoll.