YAPF - Testers needed!

[peter1138]

Going straight ahead it encounters 1 turn and 1 slope up.
Going left it would encounter 3 turns.

Try tweaking the penalties.

[KUDr]

Yes:
a) 4 more 45-deg curves means +400 penalty (100 for one 45-deg curve)
b) One slope up is +200 penalty - so this one is cheaper

[RiTi]

Going straight ahead it encounters 1 turn and 1 slope up. Going left it would encounter 3 turns. Try tweaking the penalties.

Yes:
a) 4 more 45-deg curves means +400 penalty (100 for one 45-deg curve)
b) One slope up is +200 penalty - so this one is cheaper

I understand. But why an extra penalty for slope up because the train is also slowing down, and why not a penalty for slope down?

[KUDr]

But why an extra penalty for slope up because the train is also slowing down, and why not a penalty for slope down?

I don't understand. Try to watch what your trains do when they go up and down. When going uphill they slow down (sometimes) but if they go downhill, they never slowdown (and sometimes they accelerate there). So why to penalize downhill slopes?

[RiTi]

I don't understand. Try to watch what your trains do when they go up and down. When going uphill they slow down (sometimes) but if they go downhill, they never slowdown (and sometimes they accelerate there). So why to penalize downhill slopes?

When a trains goes slope up the speed is down (penalty 1) and there is a penalty of +200 by Yapf (penalty 2). When a trains goes slope down the speed is the same (no penalty) and there is no Yapf penalty. So the total score by slope up is 2 and by slope down is 0.

Am I correct counting, or am I missing something?

[KUDr]

correct. Only i don't understand your (penalty 1) and (penalyty 2). Why 1 in the first case and then 2?

[RiTi]

correct. Only i don't understand your (penalty 1) and (penalyty 2). Why 1 in the first case and then 2?

You wrote "b) One slope up is +200 penalty". I asked why is this because the train that goes slope up slows down. But I misunderstand myself. It's not a double penalty.

What I tried to say is that in normal ways the train should take the left turn. It's the penalty system (the Yapf total "penalty" for 3 corners for a left turn counts heavier then the total for a rigth turn) that the train turns right and doesn't take the best route. I really think that the train needs to take the quickest and most save route and that is to turn left. It's quiker (no slowdowns by slopes up) and, as you see in the picture, there could be a hold up by a leaving train at the right station (not if it turns left). Therefor I think that a train also needs to consider if there is a possible hold up on the track in front, so it chooses the more save route.

[Dave]

correct. Only i don't understand your (penalty 1) and (penalyty 2). Why 1 in the first case and then 2?

You wrote "b) One slope up is +200 penalty". I asked why is this because the train that goes slope up slows down. But I misunderstand myself. It's not a double penalty.

I know this issue may be done with, but what it looks like he's saying is that he's unsure why YAPF penalises on an uphill slope when a train is already losing speed by going up the hill anyway?

[peter1138]

YAPF (and NPF) penalise paths, not vehicles.

Anyway, I suspect the issue here is that YAPF (and NPF) penalties are tweaked to work with realistic acceleration. With this on, those 3 sharp turns will be much slower than the single turn and slope.

But who plays without 'realistic' acceleration anyway...

[KUDr]

RiTi i still don't understand. As peter1138 said, the left way is slower than the right one, so it has bigger penalties. Is that what you are asking for?

If you want to customize those penalties, look into your openttd.cfg / section [yapf]. It is not problem to increase rail slope penalty to 2000 for example and you will have what you like. But it is useless.

[RiTi]

But who plays without 'realistic' acceleration anyway...

I.

[RiTi]

RiTi i still don't understand. As peter1138 said, the left way is slower than the right one, so it has bigger penalties. Is that what you are asking for?

If you want to customize those penalties, look into your openttd.cfg / section [yapf]. It is not problem to increase rail slope penalty to 2000 for example and you will have what you like. But it is useless.

It's hard to explain what I mean. What Dave Worley just wrote was exact one of my points and I know I can set the Yapf settings in the config file. But that was not all. What I don't understand is that trains go for, in my opinion, the way that isn't the most fast/sure one. Like I wrote before if the train goes right (and I know with/without realistic acceleration on the penalty is lower for the right turn) it can meet another train coming out of the right station. The train is then on hold, while the left turn has no such possible obstacle. Therefor the train should take this in consideration (maybe +200 penalty) so the total of both penalties (left versus right turn) could result in another choice.

[KUDr]

Aha. Finally understood.
Yes, you are right, theoretically we can make pathfinder that will predict movement of all other trains and will find the optimal routes for all of them taking into consideration also their power / weight and so on.

The only drawbacks of such smart pathfinder would be:
1. Would never be finished (soooo complicated)
2. Many bugs (more complicated => more bugs)
3. Would be too slow
4. Hard to maintain
5. I am too lazy to start such big project.

If the shortest path will become full (stopped train) the next train will choose the other way. This is simplest load balancing. But predicate that there could potentially be traffic jam? Hmm, i was never thinking of it. Any feature could be only as smart as its author or less. This rule would be broken if i did that.

[RiTi]

Aha. Finally understood.
Yes, you are right, theoretically we can make pathfinder that will predict movement of all other trains and will find the optimal routes for all of them taking into consideration also their power / weight and so on.

The only drawbacks of such smart pathfinder would be:
1. Would never be finished (soooo complicated)
2. Many bugs (more complicated => more bugs)
3. Would be too slow
4. Hard to maintain
5. I am too lazy to start such big project.

If the shortest path will become full (stopped train) the next train will choose the other way. This is simplest load balancing. But predicate that there could potentially be traffic jam? Hmm, i was never thinking of it. Any feature could be only as smart as its author or less. This rule would be broken if i did that.

I'll accept the 5th option. Just joking. Thanks for your reaction.

[DannyA]

Howdy,

I think I might have another bug for you KUDr, but it's a bit strange, because it only occurs when I'm using the openttd_7130_151 Build Templates exe. The nightlies and MiniN work fine, which makes me think you've already changed/fixed it. If you load the attached save it will error in 5-10 sec.

I got a 4 track mainline merger working (trying to test at the mo) where trains use the look-ahead to chose the track where it will fit most closely amongst existing trafic.

These are the penalties (excel), I am hoping to use, but have no way of really knowing. Is there any way I can see the current penalty for the path a train has chosen - paused?

rail_look_ahead_max_signals 19
rail_look_ahead_signal_p0 160
rail_look_ahead_signal_p1 -46
rail_look_ahead_signal_p2 2
rail_slope_penalty 5000

Signal Penalty (I think) Merger signals
0 0 eol 2way
1 116 pre-signal path break 2way
2 76 clear zone presig input (1way combo)
3 40 2way combo in path
4 8 1way combo in path
5 -20 Rear gap 5
6 -44 Rear gap 4
7 -64 Rear gap 3
8 -80 Rear gap 2
9 -92 Rear gap 1
10 -100 clear zone 1
11 -104 clear zone 2
12 -104 clear zone 3
13 -100 clear zone 4
14 -92 Front gap 1
15 -80 Front gap 2
16 -64 Front gap 3
17 -44 Front gap 4
18 -20 Front gap 5

So far the test has looked pretty promising, but is not set up well, and is hard to change since I can't copy and paste. Maybe something similar can be done naitively by future signals etc...

Another thing, it seems that any slope penalty below 5000 does not work well when trying to set cirtain routes to be more preferable than others.
Can someone please explain the logic behind how the slope penalty is applied?
- affect of rail type
- if slope penalty is 10,000, and a choice between a path with 11 slopes and 12 slopes is required, what happens? - max out at 100,000?

Perhaps this is what was causing RiTi some grief as well.

Edit: tried to update attachement

[DannyA]

Attachment

[KUDr]

DannyA: correct. Negative penalties are not supported. They won't work so therefore i added those asserts. Simply you must use non-negative numbers there.

No. Penalties used by train are not easily accessible. Only if you use debugger.

[DannyA]

KUDr: That's disappointing.
The look ahead could be used to do some really neat stuff with load balancing & merging etc. if it was not for this limitation.
It’s strange that you say the negative penalties won’t work when they did in the tests I ran. When given a choice between two identical paths, one with a red signal somewhere with negative look-ahead penalty, trains head down the path towards red.

Is there any way I can use the look-ahead to make a particular path more appealing based upon traffic conditions?

Or could you allow for negative penalties to exist for look-ahead values, and cap the total look-ahead penalty at 0?

Don’t want to be a pain in the butt, using something in way it was not intended, but it would be a real shame to deny these possibilities when it is so close to working now.

[KUDr]

DannyA: Yes. I can implement clamping of those values into range 0..MAX_INT. But definitelly they can't be negative - whole concept of node lists would be much more complicated and slower if nodes that are already closed could be reopened. You can look for some articles how A* works and you will understand me.

And don't try to convince me that it worked. If you build your openttd with asserts disabled, it will pretend that it works (will not crash). But the behavior will be undefined when negative penalties used. It was designed so because the performance was requirement #1. And YAPF is now fastest pathfinder we have. So the main mission goal was met.

[DannyA]

KUDr Thanks for another quick response, I completly agree, and let me just way I'm not critisising YAPF in any way - it's worked exceptionally well for me. Also, I'am not fluent in C, can not compile OpenTTD (or even a new empty project) and am sure I don't fully understand how YAPF works or A* searches, but I think I got the jist of things from reading the A* wiki article anyway.
If I had to explain it in one sentance I would say it starts at a spot looks at all the ways it can get to another spot, then goes the way it thinks is best over and over untill it gets to the destination, or it has been everywhere.

What I am trying to do does not involve reopening closed nodes or giving negitive weights or estimates to nodes. It is simply having having the lookahead tell the pathfinder that a node is a bit better than the normal. Since the look-ahead penalty for green signals is 0 (I assume), and only positive look-ahead values are allowed, there is no way to make a node more appealing when it is red than it is when it is green.

I was trying to do this by setting negative penalties, but it's clear that is not the way to go.
A much easier way would be to be able to set a default look ahead for green signals which is greater than 0. eg. 50. This way, if the look-ahead polynomial works out it should apply 25 that node will be more apealing due to the red signal.
Hope this make a little sense - gotta go.

Danny