Skip to main content ↑ ↓
Topic: shedule problem (ONCE AGAIN ...) (Read 15392 times) previous topic - next topic

shedule problem (ONCE AGAIN ...)

Some time ago I reported a problem of a bus doing strange trajectories ... but here I think there's a more annoying problem !
In this screenshot, a train prefers taking the red trajectory than the green one, I know there's one more slope in the green schedule than in the red one (and on this bridge, the down slope compensates the up one) but there ... it's a bit bothering to put a p****age point in the schedule after sending three long trains to unlock the situation.

Re: shedule problem (ONCE AGAIN ...)

Reply #1 –
Slopes are always counted as bad, not matter if up or down. Also the green one has 3 90° turns, while the red one has only one. That are a hell more tiles to go (25 tiles per tile, 6 tiles per 90° bend), thus the red way.

Re: shedule problem (ONCE AGAIN ...)

Reply #2 –
Have you just compared the lenght of each one ???
I timed the same train on the two shedules and the green one is much faster than the red one, the way of calculating paths is wrong.

This is a most representative example, counting curves is useless this time ...

Re: shedule problem (ONCE AGAIN ...)

Reply #3 –
CHoosesignals involved somewhere? No single way signals?

YOu can choose the malus for curves anyway by adjusting simuconf.tab. Not sure if pak128 still yuses the first old set. Try with pak64 values then.
 

Re: shedule problem (ONCE AGAIN ...)

Reply #4 –
ok I will test by modifying simuconf ;)

no choose_signal involved, single ways are allowing the two shedules.

EDIT : can you explain me each malus value refers to by some screenshots ? I don't understand everything ...