YAPF - Testers needed!
Moderator: OpenTTD Developers
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
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
- Attachments
-
- Look-Ahead Merge.png
- rough, quick explaination (paint :)
- (164.22 KiB) Downloaded 185 times
-
- Look-Ahead Merger Test.sav
- EDIT: noticed in the first upload the normal merger was deadlocked. probably happen again anyway
- (142.05 KiB) Downloaded 317 times
-
- -
- Assert failed upon negative look-ahead penalty (I think).PNG (13.84 KiB) Viewed 6247 times
Last edited by DannyA on 13 Nov 2006 14:55, edited 1 time in total.
Attachment
- Attachments
-
- OTTD Stuff.xls
- Excel spreadsheet for look-ahead calcs. (which I hope is correct)
- (101 KiB) Downloaded 277 times
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.
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.
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.
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.
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
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
DannyA: yes, i understand what you want to do, but it seem to me like you want the exactly opposite way of load balancing behavior: "look around and if you see any traffic jam, go there". Such "Traffic jammer" could be powerful weapon when used against competitors.
If you convince me, that it could be useful feature, I can for example add another polynomial (3 values, default = 0) for green signals. Or i can treat negative polynomial results as the positive penalties for green signals. Then you will be able to do what you want. But don't forget, that this will cause traffic jams to happen more often and last much longer (all trains will try to attend, not avoid traffic jams).
If you convince me, that it could be useful feature, I can for example add another polynomial (3 values, default = 0) for green signals. Or i can treat negative polynomial results as the positive penalties for green signals. Then you will be able to do what you want. But don't forget, that this will cause traffic jams to happen more often and last much longer (all trains will try to attend, not avoid traffic jams).
Spot on! In the wrong hands, it could indeed be quite nasty I think. :)
I was a little bit bored before, and went for a bit more graphical aproach - attached png. There's some notes there about jams etc.
I think which ever way is the simplest and has the lowest impact on performance would be best. Having a seccond polynomial would probably allow more control over exactly which signals behavied this way, and their importance, but it could become very complicated to predict how the two formulas would combine in all circumstances - to know what the penalty would be. As far as I can see, there is no difference between having a constant penalty for green signals as I suggested before, or treating negative penalties as the positive penalty for green. Increasing the constant green penalty would be the same as reducing the p0 of the red polynomial.
Some sort of programable signals, or perhaps call back script may be a better way to handle anything requiring a more complicated solution. Learning bit of lua might be on the cards for me too...
I tried to test this idea when it looked like it was working in 7130 (save), but I don't think it is a good way to test a merger - with the loops etc, but here's the results anyway:
I was a little bit bored before, and went for a bit more graphical aproach - attached png. There's some notes there about jams etc.
I think which ever way is the simplest and has the lowest impact on performance would be best. Having a seccond polynomial would probably allow more control over exactly which signals behavied this way, and their importance, but it could become very complicated to predict how the two formulas would combine in all circumstances - to know what the penalty would be. As far as I can see, there is no difference between having a constant penalty for green signals as I suggested before, or treating negative penalties as the positive penalty for green. Increasing the constant green penalty would be the same as reducing the p0 of the red polynomial.
Some sort of programable signals, or perhaps call back script may be a better way to handle anything requiring a more complicated solution. Learning bit of lua might be on the cards for me too...
I tried to test this idea when it looked like it was working in 7130 (save), but I don't think it is a good way to test a merger - with the loops etc, but here's the results anyway:
Code: Select all
Good Production Trains on track
Year Month Jammer Normal Jammer Normal
Avg Avg 4,095 3,885 55 / 70 52 / 70
2076 Jan 4200 3780 55 / 70 51 / 70
2076 Feb 3195 4290 55 / 70 50 / 70
2076 Mar 3525 2850 54 / 70 49 / 70
2076 Apr 5460 3360 54 / 70 50 / 70
2076 May 4200 4200 54 / 70 51 / 70
2076 Jun 3360 3780 56 / 70 52 / 70
2076 Jul 4035 4035 57 / 70 51 / 70
2076 Aug 4365 3525 58 / 70 51 / 70
2076 Sep 4200 4620 57 / 70 51 / 70
2076 Oct 4200 3360 57 / 70 52 / 70
2076 Nov 4875 4035 57 / 70 52 / 70
2076 Dec 4365 3945 56 / 70 52 / 70
2077 Jan 3360 3360 56 / 70 53 / 70
2077 Feb 4455 3780 55 / 70 54 / 70
2077 Mar 4785 3780 54 / 70 54 / 70
2077 Apr 3780 4620 53 / 70 55 / 70
2077 May 4200 4200 53 / 70 55 / 70
2077 Jun 3360 3780 53 / 70 54 / 70
2077 Jul 3360 3780 54 / 70 54 / 70
2077 Aug 4710 4200 55 / 70 54 / 70
2077 Sep 4110 4290 56 / 70 54 / 70
2077 Oct 4200 3690 55 / 70 53 / 70
2077 Nov 3780 4875 54 / 70 52 / 70
2077 Dec 4200 3105 55 / 70 52 / 70
- Attachments
-
- Write.YAPF.Settings.txt
- This script needs to be run in the save game to change from defaults YAPF settings to the 'Jammer/Assert' settings.
(exec write.yapf.settings.txt) - (2.07 KiB) Downloaded 302 times
-
- Look-Ahead Merger Test.sav
- The implementaion... (Don't mind my spelling)
- (215.59 KiB) Downloaded 322 times
-
- Look-Ahead Merger Idea.PNG
- The convincing...
- (373.66 KiB) Downloaded 297 times
DannyA: ok, you have convinced me that you probably know what you are doing, although i don't fully understand your merger (ie. the purpose of the loop with two way red sig.).
So I'll try to collect some pieces of time and will do it for you. Don't you want to help me with newsignals project? There I want to use LUA script for defining signal behavior. Then YAPF should only read some info from the signals and be able to decide properly. Something like "global train coordinator".
The first part should be tile edge signals. Then LUA and play with scripts until we have built the prototype.
So I'll try to collect some pieces of time and will do it for you. Don't you want to help me with newsignals project? There I want to use LUA script for defining signal behavior. Then YAPF should only read some info from the signals and be able to decide properly. Something like "global train coordinator".
The first part should be tile edge signals. Then LUA and play with scripts until we have built the prototype.
KUDr Thanks, that would be great.
The two way in a loop was just a little trick I used to allow the pathfinder to see a valid path (from a distance) which trains could never actually go down.
I'm starting to wonder a little bit about you, KUDr, and what this new signal project is really about. First you see the jammer as a weapon, then ask about me helping with something to do with LUA, who acording to the wiki "was a goddess to whom soldiers sacrificed captured weapons"! It all sounds a little bit sus to me...
Nah, just kidding. ;)
I'm sure I would enjoy helping with the new signals project very much actually - it sounds very interesting & exciting.
I've always been a bit facinated with AI programming, and wanted to learn more about it, but have never really got around to it. (no thanks to people making games like OpenTTD:) )
From reading the other wiki article on LUA, it sounds like it would be perfect for the job. Being able to customise signal behaviour with even the simplest logic could be used in place of huge bird's nests of track I think.
I suppose I had better get this bloody visual studio install fixed so I can at least compile the thing - something I've been procrastinating about for a while now.
If you could let me how I might be able to find out some more about new signals, or how I might be able to help, that would be great.
P.S - Although I don't always know what I'm doing, I always know exactly what I'm trying to do... ;)
The two way in a loop was just a little trick I used to allow the pathfinder to see a valid path (from a distance) which trains could never actually go down.
I'm starting to wonder a little bit about you, KUDr, and what this new signal project is really about. First you see the jammer as a weapon, then ask about me helping with something to do with LUA, who acording to the wiki "was a goddess to whom soldiers sacrificed captured weapons"! It all sounds a little bit sus to me...
Nah, just kidding. ;)
I'm sure I would enjoy helping with the new signals project very much actually - it sounds very interesting & exciting.
I've always been a bit facinated with AI programming, and wanted to learn more about it, but have never really got around to it. (no thanks to people making games like OpenTTD:) )
From reading the other wiki article on LUA, it sounds like it would be perfect for the job. Being able to customise signal behaviour with even the simplest logic could be used in place of huge bird's nests of track I think.
I suppose I had better get this bloody visual studio install fixed so I can at least compile the thing - something I've been procrastinating about for a while now.
If you could let me how I might be able to find out some more about new signals, or how I might be able to help, that would be great.
P.S - Although I don't always know what I'm doing, I always know exactly what I'm trying to do... ;)
That's the correct way it should work. I think that the bridge itself gives (or has to give) the penalty because of the max. speed the bridge has. The max. speed of a bridge can make fast trains to slow down on the bridge. Therefor I would prefer the choice to take the fast way and that's not the bridge.DannyA wrote:When I was looking at that in r7176, I noticed flat bridges over slopes still have the slope penalty applied.
I have read all your recent topics and the replies of KUDr. I think I know what you want but you make it to complex. What you need is a handy choice between two things:
1. The shortest route from A to B and
2. The fastest route form A to B.
The first one is a (heavy) calculation but can be made one time at the start of the train. The second one is more complex because the train has to deal with traffic on the route. It's almost impossible to calculate this at the start of the train. The only option is that the total railroad network is constantly being monitored (with very heavy load on computer memory) that the train on way can constantly make new discissions. But that is not how it works in normal railway live. In normal live it's not the train that makes discissions but a route planner (a human being with the help of a computer). The route planner makes for every train on the network the planning (where to go, what time, where to stop, which route, etc.). He has to deal with the question of cargo at stations, the railroadnetwork, the amount of trains and the type of trains. That's you're job to in game and in general not the job of the pathfinder. You can influence that by making a good network and a good signal system and using way-points to force you're trains to take a certain route. What you really need is a timetable for you're trains. By sending trains on a specific time on route you have what you want and then you're the merger (not the pathfinder). That would make the whole game more complex for the player but with a lot of extra fun.
Keep life simple...
Thanks for the comments Riti.
I like your idea of a route planner too.
The way those bridges are handled is not correct though, as the train chooses to go around the flat bridge, and over the raised one. I found that only bridges which have a speed limit lower than the max speed of the vehicle have a pathfinder penalty applied - (TrainMaxSpeed - BridgeMaxSpeed) / TrainMaxSpeed * 100 per tile.
Since I got visual studio working again I thought I'de have a crack at fixing the bridge slope bug myself. It's not immediatly obvious to me what a good way of working out if going through a tile in a cirtain direction with a bridge involves climbing a ramp or not. First impressions are that there are several ways of defining directions, slopes, etc some related with rail, some more landscape related etc, so will have to look a bit further.
I like your idea of a route planner too.
The way those bridges are handled is not correct though, as the train chooses to go around the flat bridge, and over the raised one. I found that only bridges which have a speed limit lower than the max speed of the vehicle have a pathfinder penalty applied - (TrainMaxSpeed - BridgeMaxSpeed) / TrainMaxSpeed * 100 per tile.
Since I got visual studio working again I thought I'de have a crack at fixing the bridge slope bug myself. It's not immediatly obvious to me what a good way of working out if going through a tile in a cirtain direction with a bridge involves climbing a ramp or not. First impressions are that there are several ways of defining directions, slopes, etc some related with rail, some more landscape related etc, so will have to look a bit further.
Thanks. Now how to move on? What kind of (what's in it) route planner and how do we get a route planner? Maybe first starting a new topic because this goes beyond Yapf (or KUDr doesn't mind we go on in this topic)?DannyA wrote:Thanks for the comments Riti. I like your idea of a route planner too.
Keep life simple...
RiTi:
Yeah, I reckon a new topic, maybe in suggestions if there is not already something similar would be the best way to follow that up. I need to get my head around how the existing stuff works a bit better before I can suggest new stuff or changes, so might look at fixing some other bugs - since KUDr beat me to this one...
Yeah, I reckon a new topic, maybe in suggestions if there is not already something similar would be the best way to follow that up. I need to get my head around how the existing stuff works a bit better before I can suggest new stuff or changes, so might look at fixing some other bugs - since KUDr beat me to this one...
Who is online
Users browsing this forum: No registered users and 14 guests