+- Deutsches Simutransforum (https://simutrans-forum.de/mybb)
+-- Forum: Simutrans (https://simutrans-forum.de/mybb/forumdisplay.php?fid=3)
+--- Forum: Wie spiele ich Simutrans? (https://simutrans-forum.de/mybb/forumdisplay.php?fid=6)
+--- Thema: Routing und Überholen (/showthread.php?tid=6635)
- cfds - 20-05-2012
Mal sehen wie sich das verhält. Ich fürchte aber dass die verwendete Formel zu extrem ist und z.B. im Standard-Pak 130 km/h-Züge auf biegen und Brechen eine 200km/h Strecke suchen werden statt die 120er zu verwenden. Es würde sich schließlich eine fast dreimal so lange Strecke immer noch lohnen.
- kohlenschaufler - 20-05-2012
Danke erstmal für die Änderung
Laut Code sollte es sich jetzt in etwa so verhalten:
Code:
int costs = (max_speed<=max_tile_speed) ? 1 : 5-(3*max_tile_speed)/(max_speed-1)
v_Strecke in
% von v_Zug Malus neu Malus alt
100.00% 1 1
90.00% 2 1
80.00% 2 1
70.00% 2 1
60.00% 3 1
50.00% 3 2
40.00% 3 2
30.00% 4 3
20.00% 4 5
10.00% 4 10
Was haltet Ihr von einem Malus für sehr schnelle Strecken?
- cfds - 20-05-2012
Du musst bei den Werten bedenken dass Computer bei Rechnungen mit Integers abrunden.
Bei einer 120km/h Strecke ergibt sich also:
Code:
v_zug neuer malus
121 5-360/120=5-3.0=2
122 5-360/121=5-2..=3
130 3
140 3
180 3
190 4- kohlenschaufler - 20-05-2012
Stimmt, wenn schon die Division abgerundet wird, wird das ganze massiv (zu sehr) verschärft.
Man könnte die Formel etwas abändern:
Code:
int costs = (max_speed<=max_tile_speed) ? 1 : 5.0-(3*max_tile_speed)/(max_speed-1)Allerdings wäre ich für eine weniger starke Bestrafung von langsamen Strecken und für einen zusätzlichen Malus bei sehr schnellen Strecken, etwa so:
Code:
int costs =(max_speed > max_tile_speed) ? 5.0-4*max_tile_speed/max_speed : 1+max_tile_speed/max_speed- dom700 - 20-05-2012
Zitat:Original von kohlenschaufler*hust*
Dann sollte die Berechnung mit Fliesskomma erfolgen und erst am Schluss abgerundet werden, was einiges harmloser ist.
Mein Rechner wird schon warm genug.
- kohlenschaufler - 20-05-2012
Zitat:Original von dom700Dein Rechner sollte eine FPU haben, die auch eine Fliesskomma-Division schnell ausführen kann.
Mein Rechner wird schon warm genug.
Bin nicht sicher, ob auch Integer-Divisionen optimiert sind, die werden selten gebraucht.
Ausserdem wäre 1/max_speed pro Zug konstant, das könnte man abspeichern. Der Rest sind FP Additionen und Multiplikationen, die sind hochoptimiert.
- cfds - 20-05-2012
Jetzt rundest du beim Casten auf int effektiv auf, das wird so nicht besser...
- prissi - 20-05-2012
4-(3*max_tile_speed)/(max_speed)
ergibt genau das gewünschte Verhalten mit Ganzzahlen (Schande auf mein Haupt, die Rundung hatte ich auch erst nachher gemacht ... )
- cfds - 21-05-2012
Und wenn man lustig ist kann man jetzt für den inversen Fall max_speed < max_tile_speed noch 4-(3*max_speed)/max_tile_speed verwenden und sichert so die Strecken noch nach unten ab.
Das hätte für pak64 folgende Auswirkungen (Geschwindigkeitsbereich für Routingmalus 2):
Code:
Gleis v_a v_b
55 37 82
120 80 180
200 134 300
400 267 60055 und 120 trennen fast perfekt, bei 120 und 200 ist der überlapp schon beachtlich.
Für pak128
Code:
65 44 97
110 74 165
160 107 240
280 187 420
400 267 600Ok, hier würde so eine "Mindestgeschwindigkeitsregel" nicht wriklich funnktionieren, wahrscheinlich müsste man 5 und 4 statt 4 und 3 verwenden.
- kohlenschaufler - 21-05-2012
Juhuu, ein Kommentar zum Langsam-Malus :-)
Ich würde diesen weniger stark ansetzen, mit
1+max_tile_speed/max_speed
Das ergäbe einen Malus von 2 ab doppelt so schnellem Gleis