YAPP - Yet Another PBS Patch (now in trunk!)

[Michi_cc]

I got a similar crash as fujitsu... see attachments.

This station setup is wrong and will cause crashes, because you dont have signals exactly behind station, but there is a gap one tile.

Which has nothing to do with the problem. It will only cause a crash if the gap is larger than the shortest train.
The problem here is just the already known problem with trains that can't find a path to their destination.

Don't worry, these thing will be fixed, you just have to pe patient

-- Michael Lutz

[anboni]

I just had a fairly strange situation in my game, most likely caused by me reversing a train. Attached are one save (autosave which I loaded and finished some track) just before I reversed that train (train #69, which is currently stopped while I'm quickly finishing the connection to its station). The other save is where train #62, quite a bit away from the reversal spot, has stopped waiting for a signal that should be clear.

Coming from the july 15th savegame, it takes the following steps to reproduce:
- Start train #69
- Reverse it
- Tell it to ignore one red signal (yes, i forced it to go through a one-way signal from the wrong side)
- Reverse it again, it'll now ride to the correct station
- wait until the next day, look for train #62 which will come to a halt at the junction nearby
- Train #62 will stop at each signal now and will also not take the track to its destination. instead, if you keep clicking the 'ignore red signal', it'll get to a point from where it'll go for a while until it'll come to another stop just past the oil refinery. From there, another bunch of 'ignore red signal' clicks will get it back to the point it got stuck earlier. When the trains comes past that spot, it seems all other trains waiting there will continue on their way.

The july 16th savegame simply shows train #62 waiting at that spot with another train coming up from behind (which does stop properly), should you be unable to reproduce my weird brainwaves

I realize this problem is mostly operator error (after all, I was warned that reversing trains has 'ample problems right now' ), but I figured I'd share this savegame as it might provide an opportunity for some debugging in a situation most likely very different from what you're testing yourself


Note that the game is running Gonozal's "minty" r12087), only default grf's.

[Tekky]

I had similar problems at one station, where a train would reserve a path to a platform even though a train was already waiting there. It could have easily used one of the other platforms. I checked if the train was probably heading for a depot (as this was discussed as a potential cause for this), but it was heading for exactly that station.

The second train behaved correctly. I think the first train was at fault because it hadn't reserved the track properly, most likely due to it trying but failing to reach the depot. Did you also check whether the first train had tried to service in the depot?

[paradigm]

I had similar problems at one station, where a train would reserve a path to a platform even though a train was already waiting there. It could have easily used one of the other platforms. I checked if the train was probably heading for a depot (as this was discussed as a potential cause for this), but it was heading for exactly that station.

The second train behaved correctly. I think the first train was at fault because it hadn't reserved the track properly, most likely due to it trying but failing to reach the depot. Did you also check whether the first train had tried to service in the depot?

Well, I replayed the situation from a savegame and as you have guessed, the waiting train didn't reserve the track correctly (it reserved it only up to the first switch, like in the other bugreports). Interestingly, another train is approaching the station right afterwards and it also fails to reserve the path correctly but somehow manages to use the next free platform. Then the unlucky third train as seen in the screenshot comes and finally crashes into the waiting first train.

A savegame about a month before the crash occurs is attached. During that month all events I described can be observed. The crash happens on january 7th.

[Rainer]

Hi,

I worked with this PBS implementation for the first time and have the impression that I've got something wrong.
I have a bidirectional circle (two one way tracks in opposite directions) through many cities. All trains have only two of the cities in their orders.

I wanted to replace all trains on the track with longer ones. So I ordered all trains to go into a depot. I have only two depots on this track and about a quarter of the trains instantly turned around ignoring all signals to enter a nearest depot behind them. There was no visible track reservation while the trains were running back.

Fortunately the order went to all trains, so no crash happened.

Question 1: Are single PBS signals supposed to be one way?
Question 2: If not, are there any one way PBS signals?
Question 3: If not, how can a train be hold up from turning around and crashing into the following train?

cu
Rainer

[paradigm]

1. No
2. Yes



But seriously, just CTRL+click on a normal PBS Signal and it will turn into a one-way signal (it has a yellow sign).

[Rainer]

Hi paradigm,

Question 2: If not, are there any one way PBS signals?

2. Yes
But seriously, just CTRL+click on a normal PBS Signal and it will turn into a one-way signal (it has a yellow sign).

But AFAIR from my pre-PBS-Time (yesterday ) a train that reached a one way signal from the wrong side, turns around.
That seems no longer be true :

Train waiting at the wrong side of a one way PBS signal

Bad Fulda Transport, 15. Okt 1928.png (34.16 KiB) Viewed 5305 times

cu
Rainer

Edit: replaced wrong screenshot

[Mchl]

This is one of the differences between traditional signalling and this new signalling method.

Basically I learned to put a one way signal in every place where train has the possibility to go wrong way, but is not supposed to do so. Helps in most cases (rest of the cases being bugs already mentioned in this topic).

[Tekky]

Maybe it would be best to change the graphics of the signals to use the same graphics as TTDPatch through-signals (click here for link). That way, single signals which are one way will look the same way as in traditional OpenTTD signalling and as in TTDPatch. And two-way single signals will be identifiable as two-way very easily.

Just a note for explanation: A two-way single PBS signal is called a through-signal in TTDPatch.

[DaleStan]

Breaking the signalling system that everyone has been using for the past 13 years: Still Not A Feature.

[Michi_cc]

Maybe it would be best to change the graphics of the signals to use the same graphics as TTDPatch through-signals (click here for link). That way, single signals which are one way will look the same way as in traditional OpenTTD signalling and as in TTDPatch. And two-way single signals will be identifiable as two-way very easily.

Signal graphics can be easily changed trough newgrfs. I'm sure there's somebody here who can make a newgrf with different signal sprites. The through (two-way) pbs signal currently uses the normal pbs graphics and the one-way pbs signal the pbs pre-signal graphics.

-- Michael Lutz

[Maedhros]

I don't know - through-signals would require someone to understand JGR's signal graphics action 2 format, which is always a daunting proposition.

[paradigm]

Breaking the signalling system that everyone has been using for the past 13 years: Still Not A Feature.

Since when is anyone forced to use this signalling system? I really like it the way it is, because it just is way more realistic and it isn't too hard to "learn" how it works.

@Rainer: I one of my games a similar situation was working as expected. I think the problem with this is, that reversing trains still isn't always working as it should and there are still some problems with the pathfinding (like causing crashes).

[DaleStan]

I don't know - through-signals would require someone to understand JGR's signal graphics action 2 format

Why is that action 2 so much harder than any other? I'm pretty sure I haven't had to change the Varaction 2 parser in NFORenum (except for adding more variables and/or operations) since July of 2005.

[peter1138]

Breaking the signalling system that everyone has been using for the past 13 years: Still Not A Feature.

The world is also flat, and this patch still allows the old signalling system.

Why is that action 2 so much harder than any other? I'm pretty sure I haven't had to change the Varaction 2 parser in NFORenum (except for adding more variables and/or operations) since July of 2005.

NFORenum doesn't have to do anything with the data. NewSignals also doesn't appear to follow the usual action 1/2/3 format and relies on action 5...

[JGR]

Newsignals uses action 5 largely because it seemed like a good idea at the time; however as you will almost never need two newsignal sprite sets in a single GRF (or if you do, they can be combined), an action 5 is perfectly acceptable and actually makes things simpler from a GRF coders POV (at least in my opinion).

As for the action 2, the complexity and length is a function of how many sprites you use for each signal and how you lay out the sprite block. A 1:1 sprite:signal combination ratio would require almost no action 2 processing.

The sample GRF I wrote uses 2 sprites per signal (head and base) and a recolour sprite for each signal (making the sprite selection code more complicated).
Another issue is that the parametrised vars basically dump bits of L5 and L3 (and I'm not sure about OTTD<-->TTDP compatibility there).

The spec may need to be changed/tweaked anyway, as I realise now that it makes coding full-tile/track signal sprites like signal gantries unnecessarily difficult, as the callback is called once for each signal, and there is not yet a per-tile/track flag/callback/variable/etc.

[DaleStan]

Why is that action 2 so much harder than any other? I'm pretty sure I haven't had to change the Varaction 2 parser in NFORenum (except for adding more variables and/or operations) since July of 2005.

NFORenum doesn't have to do anything with the data.

In basically the same sense that Open doesn't have to do anything with the data. Actually executing the thing is blasted easy. Parsing it is the hard part. This is, after all, why Open parses the actions into its own internal format, isn't it?
NFORenum has to find all the <set-id> entities, as well as <default>. To do this, it has to first find <nvar>, to determine how many <set-id>s to read before reading <default>. And <nvar> isn't at all easy to find:
1) Check <var> to determine if it is followed by <param> or <shift>.
2) Check <shift> and <type> to determine the width of <varadjust>.
3) Check <shift> again, to determine whether <varadjust> is followed by <nvar> or <op>.
4) If followed by <op>, go to the next byte and proceed at 1.

While all this is going on, NFORenum also checks all <var>s, <param>s, and <op>s for validity, even to the extent of disallowing the operation 10 for varactions that are neither type 81/85/89 industry 2s nor type 82/86/8A industry tile 2s and checking that the parameter for var 7E is a defined ID. It also objects if it finds extraneous trailing bytes.

Except for the different variables, there's nothing in those var action 2s that wouldn't be valid for vehicles or stations. Yeah, one of them's 226 bytes long, but that's just long, not invalid.

NewSignals also doesn't appear to follow the usual action 1/2/3 format and relies on action 5...

Well, the action 2 returns a callback result, not a sprite. This is not unprecedented. There are, in fact, several other generic callbacks: 18, 33, 34, and 144. The index-into-action-5-block is strange, but doesn't seem like it's the end of the world. I'll grant the multiple action-5 blocks thing is interesting, though.

Another issue is that the parametrised vars basically dump bits of L5 and L3 (and I'm not sure about OTTD<-->TTDP compatibility there).

Pretty good, I expect. The information all still has to be there, after all. Surely it can't be as bad as the 80+x vehicle variables.

[peter1138]

In basically the same sense that Open doesn't have to do anything with the data. Actually executing the thing is blasted easy. Parsing it is the hard part. This is, after all, why Open parses the actions into its own internal format, isn't it?

Sure. If it didn't do anything with the data, then nothing would happen. The data is there for a reason, after all. OpenTTD only parses the data from the read-only bitpacked little-endian arrangement in the GRF file into a C struct, with the system's endianness and mostly unpacked...

I'm pretty sure Maedhros is talking about the data in the 0x20 - 0x2F / 0x30 area, not the actual Action 2 chain. While that data is not particularly complex, it is non-standard, in that it looks like a list of sprites to draw with offsets, much like industry and house tiles.

Which is all irrevelant to a PBS patch.

[sc79]

Having played with the patch for a few hours, I have to say it seems to work very well; both in terms of implementation and lack of bugs. It takes a bit to get used to (breaking old methods, mostly), but it quickly gets very simple to use. I've even managed to convert the majority of my network in my current game, with only the occasional problem, which I expect are user error or possibly known bugs; still need to test more, but its runs pretty flawlessly, considering. Good job

[tijnttd]

http://www.skagset.no/openttd/r12072_yapp_v3_win32.rar

took the svn-friendly filed and compiled with buildottd. It failed against latest rev (I'm a bit stressed before work, so didn't see against what file) but compiled fine against latest nightly rev.

So If I'm understanding it right: this patch does not work unless you have the nightly? Cause I copied it over the latest beta (3) and it the YAPP PBS doesn't seem to work... Or am I missing something important?

Dont know how to compile, otherwise I would do it myself!