Routing und Überholen

[cfds]

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]

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

leider funktioniert hier keine bbcode Tabelle

Was haltet Ihr von einem Malus für sehr schnelle Strecken?

[cfds]

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]

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)

Dann sollte die Berechnung mit Fliesskomma erfolgen und erst am Schluss abgerundet werden, was einiges harmloser ist.

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]

Original von kohlenschaufler
Dann sollte die Berechnung mit Fliesskomma erfolgen und erst am Schluss abgerundet werden, was einiges harmloser ist.

*hust*
Mein Rechner wird schon warm genug.

[kohlenschaufler]

Original von dom700
Mein Rechner wird schon warm genug.

Dein Rechner sollte eine FPU haben, die auch eine Fliesskomma-Division schnell ausführen kann.
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]

Jetzt rundest du beim Casten auf int effektiv auf, das wird so nicht besser...

[prissi]

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]

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          600

55 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          600

Ok, hier würde so eine "Mindestgeschwindigkeitsregel" nicht wriklich funnktionieren, wahrscheinlich müsste man 5 und 4 statt 4 und 3 verwenden.

[kohlenschaufler]

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