YAPF - Testers needed!
Moderator: OpenTTD Developers
Mindrila: thanks for testing YAPF.
1. Even you set YAPF type 2, you still need to switch on NPF to disable distance checking when making order list. Later it will be switched off automatically. Sorry for inconvenience.
2. As you can see from previous discussions (page 1), the ships will need some different algorithm to improve performance. They are still very slow.
DW: looks like you have found a new bug. I will need your savegame in order to deal with it. Thanks.
1. Even you set YAPF type 2, you still need to switch on NPF to disable distance checking when making order list. Later it will be switched off automatically. Sorry for inconvenience.
2. As you can see from previous discussions (page 1), the ships will need some different algorithm to improve performance. They are still very slow.
DW: looks like you have found a new bug. I will need your savegame in order to deal with it. Thanks.
KUDr (or any other knowledgeable individual),
I first want to say I'm excited about this YAPF feature and the implication that PBS will be rebuilt from the ground up using YAPF! Thanks a million.
If you have some time, I was wondering if you would answer some questions for the curious.
1. Would it be possible to describe the algorithm itself? How does it work, and what kind of things does it take into account? I'm not looking for a novel here, but just the short 1 or two paragraph version.
2. Is YAPF being developed with PBS in mind?
3. KUDr, I'm pretty sure this is your project, but are you the only programmer on it right now? Will you (or your team) be working on PBS too?
Hope these questions aren't too annoying!
-Hazelrah
I first want to say I'm excited about this YAPF feature and the implication that PBS will be rebuilt from the ground up using YAPF! Thanks a million.
If you have some time, I was wondering if you would answer some questions for the curious.
1. Would it be possible to describe the algorithm itself? How does it work, and what kind of things does it take into account? I'm not looking for a novel here, but just the short 1 or two paragraph version.
2. Is YAPF being developed with PBS in mind?
3. KUDr, I'm pretty sure this is your project, but are you the only programmer on it right now? Will you (or your team) be working on PBS too?
Hope these questions aren't too annoying!
-Hazelrah
True.Brianetta wrote:In answer to 3, KUDr is the only programmer working on YAPF, but he does communicate extensively with other devs (and occasionally lesser beings such as myself) on the IRC channel.
For 2:
YAPF is designed to be extendable with more signal types, including PBS. YAPF actually evolved from the attempts to improve NPF's performance (also done by KUDr).
If someone comes up with another signal type you could easily implement it into YAPF, it is way harder to do that with NPF or NTP.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
Hazelrah: thanks for your post and for testing YAPF protoype. Thanks to Brianetta and XeryusTC for their answers.
1. The algorithm used by YAPF is known as A* (A-star) - the same as OPF, NTP or NPF. There are some differences in the cost calculation, so each PF can behave differently in some cases. Another differences you can see in the modularity, flexibility (NPF is the best PF from that point of view) and in some additional features (i.e. YAPF records the path node by node as well as NPF does, but OPF and NTP don't).
2. The only requirement that is mandatory for PBS is path recording (see above) - so after the best path is found, you can walk through the path back to the origin (train tile/trackdir) and do some additional tasks (change signal states, reserve path for PBS, etc.). Currently only NPF and YAPF have this ability.
I should clarify a bit the answer from XeryusTC:
3. Currently I am the only one who is coding it. It was the easiest way.
But I often need to consult some issues with regular ottd developers as they have much deeper knowledge of the product than me. I do it on IRC #openttd (freenode). They also help me with OS specific issues.
1. The algorithm used by YAPF is known as A* (A-star) - the same as OPF, NTP or NPF. There are some differences in the cost calculation, so each PF can behave differently in some cases. Another differences you can see in the modularity, flexibility (NPF is the best PF from that point of view) and in some additional features (i.e. YAPF records the path node by node as well as NPF does, but OPF and NTP don't).
2. The only requirement that is mandatory for PBS is path recording (see above) - so after the best path is found, you can walk through the path back to the origin (train tile/trackdir) and do some additional tasks (change signal states, reserve path for PBS, etc.). Currently only NPF and YAPF have this ability.
I should clarify a bit the answer from XeryusTC:
This is valid for NTP (as it is a bit over-optimized and therefore not so flexible). NPF on the other side is very well designed and therefore flexible and easily extensible. Afaik only the performance is the issue with NPF.If someone comes up with another signal type you could easily implement it into YAPF, it is way harder to do that with NPF or NTP
3. Currently I am the only one who is coding it. It was the easiest way.
But I often need to consult some issues with regular ottd developers as they have much deeper knowledge of the product than me. I do it on IRC #openttd (freenode). They also help me with OS specific issues.
Wow, this is really quite interesting. It must be a heck of an undertaking to do this all by yourself. I hope you don't mind a couple more.
1. OPF - "Original Path Finder"?
2. You say that all of the PF's use the same basic A* algorithm. So what exactly is it that YAPF has that NPF doesn't have (or vice-versa). Basically why does YAPF run so much more efficiently?
3. Say someone came up with Yet Another Signal. How easy do you think it would be to implement using YAPF?
1. OPF - "Original Path Finder"?
2. You say that all of the PF's use the same basic A* algorithm. So what exactly is it that YAPF has that NPF doesn't have (or vice-versa). Basically why does YAPF run so much more efficiently?
3. Say someone came up with Yet Another Signal. How easy do you think it would be to implement using YAPF?
Hazelrah:
1. Yes
2. YAPF is similar to NPF with few minor technical differencies (C++ vs. C, static module binding instead of function pointers) and some improvements (segment cost cache, cost limits, etc.)
3. This is difficult to generalize. Depends on requirements to PF. Both NPF and YAPF should have no problem with that.
1. Yes
2. YAPF is similar to NPF with few minor technical differencies (C++ vs. C, static module binding instead of function pointers) and some improvements (segment cost cache, cost limits, etc.)
3. This is difficult to generalize. Depends on requirements to PF. Both NPF and YAPF should have no problem with that.
DW: yes, i have it. Upload your savegames to the URL i gave you and then let me know.
Edit: it is always good to tell me here about PM (otherwise i can overlook it).
Edit: thanks for the savegames. Look at the first post (on page 1) for the updated (fixed) executable (r4833).
The problem was that YAPF adds the total penalty +145 for the first red signal (approx straight 14 tiles or 3-5 curves) that was not enough for the shorter path to be more expensive (logically longer), than the longer path with green signal. It will need to rebalance the default penalties somehow. The biggest difference from NPF was that NPF treats first red COMBO signal as EXIT (which is correct) with much higher penalty. So for now I fixed it using the same logic. But if the red signal was not COMBO, but NORMAL or ENTRY, the problem persists. Then I can recommend making that signal two-way type, which (in case of first-red signal) is treated as "no way".
Edit: it is always good to tell me here about PM (otherwise i can overlook it).
Edit: thanks for the savegames. Look at the first post (on page 1) for the updated (fixed) executable (r4833).
The problem was that YAPF adds the total penalty +145 for the first red signal (approx straight 14 tiles or 3-5 curves) that was not enough for the shorter path to be more expensive (logically longer), than the longer path with green signal. It will need to rebalance the default penalties somehow. The biggest difference from NPF was that NPF treats first red COMBO signal as EXIT (which is correct) with much higher penalty. So for now I fixed it using the same logic. But if the red signal was not COMBO, but NORMAL or ENTRY, the problem persists. Then I can recommend making that signal two-way type, which (in case of first-red signal) is treated as "no way".
I have some problems when compiling the YAPF code. My MSVC6 compiler gives the following errors:
Unfortunately it quits, so there may be more errors than shown.
I don't know if the problem exists with other compilers as well (I guess not, since otherwise it wouldn't have been merged with trunk at this time).
Is there any way to fix the compiler errors?
(Note: Code is revision 4990)
Code: Select all
yapf_rail.cpp
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_costrail.hpp(23) : error C2258: illegal pure syntax, must be '= 0'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_costrail.hpp(327) : see reference to class template instantiation 'CYapfCostRailT<Types>' being compiled
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_costrail.hpp(23) : error C2252: 's_max_segment_cost' : pure specifier can only be specified for functions
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_costrail.hpp(327) : see reference to class template instantiation 'CYapfCostRailT<Types>' being compiled
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(163) : error C2954: template definitions cannot nest
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(163) : error C2951: template declarations are only permitted at global or namespace scope
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(163) : error C2226: syntax error : unexpected type 'TdestinationT'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(165) : error C2143: syntax error : missing '>' before '{'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(177) : error C2059: syntax error : '<end Parse>'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_rail.cpp(189) : fatal error C1903: unable to recover from previous error(s); stopping compilation
yapf_road.cpp
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(298) : error C2954: template definitions cannot nest
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(298) : error C2951: template declarations are only permitted at global or namespace scope
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(298) : error C2226: syntax error : unexpected type 'Tdestination'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(300) : error C2143: syntax error : missing '>' before '{'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(312) : error C2059: syntax error : '<end Parse>'
D:\dev\cpp-files\openttd-src-tmp-a\yapf\yapf_road.cpp(322) : fatal error C1903: unable to recover from previous error(s); stopping compilation
I don't know if the problem exists with other compilers as well (I guess not, since otherwise it wouldn't have been merged with trunk at this time).
Is there any way to fix the compiler errors?
(Note: Code is revision 4990)
Re: Update?
As of r4978 it is.Hazelrah wrote:Thanks for the info, and I'm looking forward to the day it can be merged back into the main branch!
-Hazelrah
OTTDCoop NewGRF Pack|Different sets of GRFs for TTDPatch (some of them work in OTTD) - 1|- 2|GRF sets for OTTD|OTTD nightly
I hooked up my accelerator to my brake lights. I hit the gas, people behind me stop, and I'm gone.
Understeer is when you hit the wall with the front of the car. Oversteer is when you hit the wall with the rear of the car. Horsepower is how fast you hit the wall. Torque is how far you take the wall with you. Spoilers and bodykits are how much of the wall you take with you. Rollcages and windownets are how much of a mess you leave on the wall.
I hooked up my accelerator to my brake lights. I hit the gas, people behind me stop, and I'm gone.
Understeer is when you hit the wall with the front of the car. Oversteer is when you hit the wall with the rear of the car. Horsepower is how fast you hit the wall. Torque is how far you take the wall with you. Spoilers and bodykits are how much of the wall you take with you. Rollcages and windownets are how much of a mess you leave on the wall.
Re: Update?
Yes, and it broke the nightlies .gkirilov wrote:As of r4978 it is.Hazelrah wrote:Thanks for the info, and I'm looking forward to the day it can be merged back into the main branch!
-Hazelrah
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
I compiled it myself.
But anyway the executables are available now .... 3 hours later.
But anyway the executables are available now .... 3 hours later.
OTTDCoop NewGRF Pack|Different sets of GRFs for TTDPatch (some of them work in OTTD) - 1|- 2|GRF sets for OTTD|OTTD nightly
I hooked up my accelerator to my brake lights. I hit the gas, people behind me stop, and I'm gone.
Understeer is when you hit the wall with the front of the car. Oversteer is when you hit the wall with the rear of the car. Horsepower is how fast you hit the wall. Torque is how far you take the wall with you. Spoilers and bodykits are how much of the wall you take with you. Rollcages and windownets are how much of a mess you leave on the wall.
I hooked up my accelerator to my brake lights. I hit the gas, people behind me stop, and I'm gone.
Understeer is when you hit the wall with the front of the car. Oversteer is when you hit the wall with the rear of the car. Horsepower is how fast you hit the wall. Torque is how far you take the wall with you. Spoilers and bodykits are how much of the wall you take with you. Rollcages and windownets are how much of a mess you leave on the wall.
Yes it was my mistake. I didn't know that compile farm is so different from what devs use. Nobody reported compilation errors except Watcom and VC6 (that are no longer supported due to very bad C++ support).
Thank to all of you for testing and reporting bugs! Further bug reports on http://bugs.openttd.org/ please.
Thank to all of you for testing and reporting bugs! Further bug reports on http://bugs.openttd.org/ please.
- White Rabbit
- Tycoon
- Posts: 1734
- Joined: 22 Jun 2005 19:15
Who is online
Users browsing this forum: No registered users and 2 guests