+- Deutsches Simutransforum (https://simutrans-forum.de/mybb)
+-- Forum: Simutrans (https://simutrans-forum.de/mybb/forumdisplay.php?fid=3)
+--- Forum: Wünsche und Anregungen (https://simutrans-forum.de/mybb/forumdisplay.php?fid=8)
+--- Thema: max_transfers Parameter entfernungsabhängig (/showthread.php?tid=2738)
max_transfers Parameter entfernungsabhängig - Mab - 09-01-2008
Um in Simutrans etwas mehr Dynamik und Realitätsnähe zu erhalten, ist mir folgende Idee gekommen:
Zur Zeit wird dem Parameter "max_transfers" in der simuconf.tab ein starrer Wert zugewiesen.
Wäre es möglich die Anzahl der Umstiege entfernungsabhängig zu gestalten (durch eine Abstandsberechnung zwischen Start- und Zielkoordinaten).
Zum Beispiel kann festgelegt werden, dass ein Umstieg immer zugelassen wird, ab 6 Kästchen Entfernung 2 Umstiege, ab 14 Kästchen Entfernung 3 Umstiege usw.
Es ist dabei zu überlegen, ob man anstatt "max_transfers" eine benutzerdefinierten Skalierungsfaktor einführt, der mit dem fest einprogrammierten Abstands-Umsteigeanzahl-Bedingungen multipliziert wird.
Dies würde das unrealistische Umherfahren von Passagieren über die halbe Karte verhindern, obwohl die Passagiere nur in den Nachbarort wollen, aber keine andere andere Route finden.
Damit verbunden würde das "Feature" des schnellen Gewinnmachens etwas eingeschränkt und der Spieler muss für eine komplette Zufriedenheit und Abdeckung "intelligentere" Verkehrsnetze entwerfen.
Für Ringrouten würden keine Einschränkungen entstehen, da die Passagiere diese ja umsteigefrei benutzen.
Was haltet ihr von diesem Vorschlag?
Grüße Mab
- DWD3072 - 09-01-2008
Grundsätzlich ist die Idee nicht schlecht, aber dann müsste man, um beim Realismus zu bleiben, auch irgendwie die Passagiere auswählen lassen welche Route die zeitschnellere ist und da kann die Längere mit einem schnelleren Zug oder weniger Wartezeit bei den Umstiegen, weil mehr Fahrzeuge auf einer Linie eingesetzt werden, durchaus gewinnen. Außerdem halte ich es für sehr schwierig bis beinnahe unmöglich das so in die Config zu schreiben das es richtig funktioniert.
Deshalb sollten wir beim bisherigen System bleiben:
Die Passagiere suchen sich die Route mit den wenigsten Umstiegen. Das kann zwar zu seltsamen Fahrwegen der Passagiere und unerwarteten Linienüberlastungen führen macht aber keine Probleme mehr sobald man ein einigermaßen dichtes Liniennetz hat.
Realistisch ist es bis zu gewissen Grenzen auch, die meisten Leute nehmen Umwege und sogar höhere Fahrpreise in Kauf wenn man dafür seltener Umsteigen muss und es macht das Passagierverhalten relativ vorhersehbar. Ein Punkt für den Simutrans vor allem außerhalb der direkt zugehörigen Foren immer wieder gelobt wird. Z. Bsp. bei Chip und anderen Sites auf denen man Freewarespiele herunterladen kann.
Gruß DWD
- gpmfuchs - 09-01-2008
Ich halte die Idee für gut.
Normalerweise baue ich beim spielen ein sternartiges Netzwerk auf.
Ein Zentralbahnhof, von dem Verbindungen zu Lokalbahnhöfen von dem Verbindungen zu Busstationen.
Das würde dazu führen das ich mehr Querverbindungen einbauen würde/müsste, was gut weil realitisch ist.
Allerdings würde ich die Anzahl der maxtransfers nicht linear sondern schwächer (wurzel(x)) steigen lassen.
Niemand fährt durch ganz Deutschland nur mit den jeweiligen ÖPNS. Und rein lineares würde sowas eben genau ermöglichen. Wenn man eine langsamere als Lineare Steigerung nimmt zwingt man zu Fernverkehr. wenn mans noch krasser mit log(x) z.b. macht zwingt man zu nem nahezu perfekten netzwerk.
Ich denke die maximalen Umsteigeverbindungen haben sich in der Realität über die Zeit gewandelt.
Früher war man viel eher bereit viele Umsteige Verbindungen in Kauf zu nehmen heute hat keiner wirklich lust 5 mal umzusteigen. Nur vlt wäre auch ne zeitliche komponente interessant also den grad der wurzel durch das Jahr festlegen zu lassen, wobei das absolut theoretisch ist, nachdem es keine passenden c/c++ aufrufe dafür gibt. (obwohl mit pow gäbs ne möglichkeit)
Die Frage ist auch ob für Passagiere und andere Güter der selbe Wert gelten sollte?
Post hat sich z.b. noch nie sonderlich daran gestört durch viele Postämter zu gehen.
Gruß gpm
- Hajo - 14-01-2008
max_transfer war nicht als Richtlinie für Spielerverhaltern gedacht, sondern ein rein technischer Parameter um den Aufwand für die Routensuche zu beschneiden (aka. "Performanceoptimierung"). Im Prinzip sollte der Parameter ein klein wenig höher sein als die höchste als sinnvoll anzunehmende Suchtiefe im Grafen.
Spieler sollten von dem Parameter nichts mitbekommen, ausser Sie haben Performanceprobleme und suchen Möglichkeiten zur Optimierung.
Edit: Den Parameter anhängig vpn Entfernung und/oder Ware zu machen läuft der Idee der Performanceoptimierung etwas zuwider da das dann extra Berechnungen erfordert.
- Mab - 14-01-2008
Zitat:Original von gpmfuchs
Allerdings würde ich die Anzahl der maxtransfers nicht linear sondern schwächer (wurzel(x)) steigen lassen.
Niemand fährt durch ganz Deutschland nur mit den jeweiligen ÖPNS. Und rein lineares würde sowas eben genau ermöglichen. Wenn man eine langsamere als Lineare Steigerung nimmt zwingt man zu Fernverkehr. wenn mans noch krasser mit log(x) z.b. macht zwingt man zu nem nahezu perfekten netzwerk.
Mein Beispiel sollte nur das von mir gemeinte Prinzip verdeutlichen. Sicherlich wäre eine mathematische Beschreibung des Abstandsverhaltens sinnvoll (linear oder quadratisch).
Zitat:Original von Hajo
Edit: Den Parameter anhängig vpn Entfernung und/oder Ware zu machen läuft der Idee der Performanceoptimierung etwas zuwider da das dann extra Berechnungen erfordert.
Dafür würde bei kurzen Verbindungen die Routensuche aber eher abgebrochen werden, was die Performance erhöhen dürfte.
- Hajo - 14-01-2008
Zitat:Original von Mab
Dafür würde bei kurzen Verbindungen die Routensuche aber eher abgebrochen werden, was die Performance erhöhen dürfte.
Stimmt auch wieder. Lassen wir Prissi darüber entscheiden, ob das programmtechnisch Sinn mach.
Für neue Spieler ist das sicherlich auch wieder ein Punkt der erst erlernt und verstanden werden muss ... inklusive Tabelle im Wiki ab wie viel Entfernung wie viele Umsteigemaneuver durchgeführt werden können, damit die Perfektionisten das ganz genau ausnutzen können
- Oliver - 04-05-2008
Nunja...
mit dem Umsteigeverhalten der Passagiere habe ich schon so meine Probleme.
Denn was die Passagiere teilweise machen, ist nicht mehr nachvollziehbar.
Beispiel aus meinem Spiel:
Passagier will von A zur Station C , die nur per U-Bahn erreichbar ist
Am Bahnhof fährt
U-Bahn 1: A-B-D
Tram: A-.....-E (E ist irgendwo am Stadtrand)
Die U-Bahn 2, die C anfährt fährt:
E-.......-B-C
Anstatt U-Bahn 1 zu nehmen, 1 Station zu B zu fahren, umzusteigen in die U-Bahn nach C macht der Passagier folgendes:
Er steigt in die Tram nach E, die ne halbe Stunde bis zum Stadtrand gurkt.
Steigt bei E dann in die U-Bahn 2 und fährt ne halbe Stunde wieder rein.
Nachdem C im Stadtzentrum liegt, ist C ein beliebter Halt. Die U-Bahn hat entsprechende Kapazität.
Leider nicht die Tram. Durch dieses Massenmanöver wird die Tram nach E gnadenlos überlastet, tausende von Passagieren sammeln sich und das Verkehrsnetz bricht zusammen, da die tausende von Passagieren, die irgendwann wieder heim fahren beim Rückweg von A die Passagiere nicht mehr befördern.
Hier müsste dringend mal etwas an der KI der Passagiere verbessert werden.
Genau das ist desöfteren in meinem Prag-Szenario zu sehen. Hier fallen solche Dinge aufgrund der Größe und des komplexen Systems sehr stark auf.
Edit P.S. Im Notfall würde es schon helfen, wenn die Priorität tatsächlich über das schnellere Fahrzeug liefe.
In meinem Spiel schauts schon so aus, dass die U-Bahnen leer bleiben, während die Straßenbahnen knallvoll sind. Hierfür müsste man wohl auch nicht so stark am Algorithmus arbeiten, oder?
- Uranor - 04-05-2008
Oha, ich seh grad in meiner simuconf.tab: max_transfers = 9. Das wäre reichlich für einen Extremfall. Wenn das Ziel mit 1 oder gar nur 0 Transfers erreicht werden konnte, wird ja hoffentlich nicht mehr höher gesucht. Auch wenn der Weg dadurch enorm weit wird, entspricht das der Wirklichkeit: Ich hab hier die Auswahl zwischen 15 min mit dem PKW oder eine U-Verbindung mit den Öffentlichen.
Dafür wird bei der Favorisierung des geringstmöglichen Umsteigens allerdings die Fernverbindung favorisiert. Genau das finde ich optimal. Die Leute steigen nur für Kurzverbindungen in die Bummelverbindung ein. Fernreisende warten auf ihren Fernzug.
@Oliver, deine Erfahrung finde ich interessant. Per Option sollte sich festlegen lassen, dass auf der Trefferebene halt doch alle verfügbaren Möglichkeiten gefunden werden. Nun findet die KI Auswahl1(Anz_Wartende), Auswahl2(Anz_Wartende)... Bei gleicher Anz_Wartende wird die erste genommen, sonst die mit dem geringeren Wert. So verteilen sich alle Reisenden zwanglos auf alle Möglichkeiten.
Das würde sich auch praktisch auf Fernzug und Bummelzug zwischen 2 Stationen auswirken. Man kann interpretieren, wer Kohle hat, wählt den Fernzug, Otto Ich steigt in den Bummelzug.
Also bei nur einer hoffentlich kleinen Variablen-Erweiterung sollte sich der max. mögliche Nutzen für (jeden(?)) Bedarf ergeben.
- Oliver - 04-05-2008
Der Aufwand dürfte so klein nicht sein, problematisch dürfte es in Punkto Rechenzeit aussehen.
Damit ich es nochmal verdeutlichen kann, zeige ich einmal im Screenshot, wie extrem das sein kann.
Gelb sind die ankommenden Passagiere in 2 Varianten.
Grün sind die beiden realen (beabsichtigten) Umsteigemöglichkeiten in die hochkapazitative Schwebebahn. Zwei Stationen, 1 Umstieg
Rot ist der gewählte Ist-Weg. Im zweiten Fall 15 Stationen, im ersten Fall 16 Stationen und ein Umstieg. Ein Umweg von etwa 200-300 Pixeln.
Der rote Weg ist totaler Schwachsinn. Kein Mensch fährt ja zur entgegengesetzten Endstation, um umsteigen zu können...
Beobachtet habe ich eines:
Gewählt wird grundsätzlich immer die Gegenrichtung beim Umstieg, obwohl es gleichsinnig meist viel kürzer ist. Da liegt der Fehler drin.
Gegenrichtung bedeutet, ich nähere mich meinem Ausgangsort wieder. In einem solchen Fall verfügt das gute Verkehrsnetz immer noch ne Tangentialverbindung. Diese sind in meinem Fall reichlich vorhanden.
Problematisch auch (man sieht es an den Rändern). Die Tramlinie wird 11 Stationen lang wegen Vollauslastung blockiert. Dadurch stauen sich an den Haltestellen die Fahrgäste, die tatsächlich mit der Linie fahren wollten.
Bitte bei aller Gegenargumentation nicht vergessen, dass wir ein Transportwesen simulieren wollen und dass die meisten, die sich damit beschäftigen mehr aufbauen wollen als Dutzende A-B-Verbindungen.
(P.S. Übrigens handelt es sich bei den Linien nicht um Ringlinien. Allerdings verkehrt die U-Bahn im Paternoster-Prinzip).
Edit: Der Zusammenbruch des Systems äußert sich darin, dass der Ist-Umstieg gar nicht statt findet, weil die Kapazität der Tramlinie durch vorhergehende, gleichartige Umsteigeaktionen bereits erreicht ist. Meist ist dies bereits schon an der Anfangshaltestelle der Fall, da einige Umstiege über die Endhaltestellen laufen.
Die Schnelligkeit scheint genauso wenig eine Rolle zu spielen, wie das Alter der Fahrzeuge. Auch die Orientierung wird hier falsch ausgelegt. Die U-Bahn ist sowohl schneller, als auch moderner (die Tram-Linien sind veraltet).
Eine Kombination zweier gegensinniger Umstiege wäre ebenfalls möglich:
Beispiel bei Route2: Passagier steigt in die Gegenrichtung der U-Bahn, fährt eine Station, steigt um (gegensinnig in die U-Bahnlinie von Route 1). Fährt zwei Stationen und ist mit insgesamt 3 Stationen und 1 Umstieg am Ziel.
Ärgerlicherweise wird selbst dieser Umstieg nicht gemacht, sondern es bleibt bei 15 Haltestellen und 1 Umstieg.
- Alexander Brose - 04-05-2008
...Wie kommt denn der Fernmeldeturm ins 128er? o.Ô
Ich meine, meine Simutrans-Grafiken sind (sofern als solche deklariert) frei aber neu ist's mir wohl. *kopf kratz*