Topic: [BUG] one_train_staff clearing too many tiles

[Freahk]

What happened?
When a one train staff controlled train toggles back to drive_by_sight at a cabinet, it will immediately clear the whole reservation except for the front of the train.

See the attached reproduction case and watch the train moving.


Observations:
- The train will properly enter the onr train staff controlled section.
- The train will continue to the dead-end and reverse there.
- After reversal it will properly continue to the exit.
- When leaving the one train staff controlled section, the whole reservation except for one tile will be cleared
- - This will leave unreserved tiles underneath the train

This will not cause any issues on its own but can be used for some exploitation and currently will lead proper one train staff layouts to deadlock when unluckily combined with two further one train staff bugs.
To see this happening, simply start the two trains from the depot in the other track layout.

I will give a short description of how the 3 mentioned bugs interact here:
Observations (combined):
- The train will enter the one train staff controlled section reservating up to the dead-end but up to the exiting cabinet.
- The train will continue to the dead-end, reverse and continue to the exit.
- At the exit, the train will clear the whole reservation except for one tile. (the bug described above)
- The next train will immediately enter the one train staff controlled section, reservating up to the dead-end. (See one_one_train_staff reserves too few tiles in some cases)
- - This train will pass through the other one.
- The Train that just left the one train staff controlled section will now unreservate each tile it leaves, although it's not its own reservation!
- - There will be an unreservated area within the one train staff controlled section left behind.
- The train that just left the section will pass the loop and continue to the entering cabinet.
- At the entering cabinet it will immediately greedily reservate as many tiles as possible, although it can not yet enter the section as it is still occupied. (See one_train_staff greedily reservating tiles it can not yet enter)
- The train in the one train staff controlled section reversed in the meantime and will continue up to the reservation of the other train, which it is not allowed to enter!
- Happy deadlockickng!

[jamespetts]

Thank you for the report: I believe that I have now fixed this. I should be grateful if you could re-test with the next nightly build.

[Freahk]

As for any other one train staff bug, apart of the exploit bug and the greedy reservation bug, I cannot confirm if it was fixed in last nights build nor if it remains, due to another (or a set of other?) new bugs is hiding that kind of information.
So this post is deputy for the other one_train_staff related bugs that had been fixed before last nights build.

As I expect you had roughly tested this on your own, when you fixed it, there may be some sideffect in any one_train_staff fix you have made after this one.
I currently cannot try this out as I am not at my developement machine.

I am wondering how to manage that situation. Post a new bugreport for every single bug I observe here?
Simply reply here? I don't know, so for now I will simply reply here:

Open the above attached save again.
- You will see the train moving towards the cabinet.
- On entering the section, it will reservate by-far too many tiles.
- On passing the exit cabinet of that section, it will simply remain in one_train_staff working, not clearing any reservations.

Start one train from the upper depot.
- You will see the train moving towards the cabinet.
- On entering the section, it will reservate too few tiles.
- On moving further, the reservated tiles reservated before entering the section will remain reservated.
- On passing the exit cabinet, it will again ignore the exit cabinet, remaining in one_train_staff and reservation further tiles while moving along.

Btw. from these observations, it seems that one_train_staff working is implemented entirely on its own, however I know there is no real "on it's own" for any woking method in the code. They are all mixed across multiple functions in the code. Maybe, for maintainance and consistency reasons, we should refactor the code to better share the common logic of working methods on a more abstract level, e.g. moving current woking method logic into classes.
Token block and one train staff currently seem to be implemented quite differently, whilst they should behave exactly the same apart from enforcing to leave the working method at an adjacent one train staff cabinet (currently, but imho we should not enforce a second cabinet at the exit and instead accept any adjacent signal or end of signalling sign) for one train staff working method.

The logic of entering a block for one train staff would then be
- When attempting to enter a block, it will try to reservate up to (included) the next signal, end of signalling sign or cabinet (same logic as for token block)
- Additionally, it will check if that exit is adjacent to the entry (which in behavior should be the only difference to token block)
- Leaving the block works just the same as token block apart from not entering one train working method but falling back to drive by sight if the exit is a cabinet.

[jamespetts]

Thank you for the report. In so far as this is a single issue, I believe that I have fixed this. I should be grateful if you could re-test with the next nightly build.

[Freahk]

The bug described in the first place (trains clearing too many tile on leave) and any deadlocking was fixed.

[jamespetts]

Splendid, thank you for confirming.