News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Time interval flagmen showing "clear" when danger is evident

Started by AP, January 14, 2018, 10:38:23 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

AP

It seems that when using flagmen to do the earliest "time interval" signalling, this operates on a 'pure' time interval system. Initially this seems logical.

However, I have noticed that this includes them happily showing "all clear" when they are standing right next to a stationary train they have earlier let through, but which has been unable to move on very far (whether due to timetabling or other circumstance such as being held at the next flag or staff cabinet), which seems a bit silly.


It is established that drivers in game can see up to 875m ahead, when in drive-by-sight mode.  I can only imagine that standard operating practice in that era required signallers to show a danger flag whenever they could "see a danger".  I would imagine flagmen could see about the same distance as drivers. I think  therefore a flag signal should monitor the tiles immediately following them for waiting trains (to the same 875m distance), which it presently seems not to do.

I also think that if a series of flagmen is established so that each can see the next (e.g. just 4 or 5 tiles apart on a long intensively worked main line), and one shows a danger flag in that situation, the preceding one should show caution (irrespective of timing).

So it needs to monitor ahead for 2 things - causes for danger and causes for caution.

jamespetts

This would require a major rewrite of the time interval signalling system, and would require each time interval signal to be able to check the requisite number of tiles ahead (and also check for corners, tunnels and over-bridges), which would require entirely new logic for pathfinding (the existing system for the trains themselves uses the paths already found for their journeys; doing this independently of trains would need a whole new pathfinding system), as well as very complex issues arising where there are junctions.

The amount of work involved in such a major rewrite means that it is likely to be many years before this issue exceeds the priority of any other thing that I could be spending my Simutrans time doing, and I should also be concerned about the computational overhead that so much extra pathfinding is likely to have.

I should note that I did read in some detail some early rulebooks for time interval signalling, which described a number of very complex divergent methods of signalling that evolved quickly over time, including such things as a train, once stopped at a time interval signal, pulling forward to as to be just beyond it so that the next approaching train could then stop in time for the signal and not collide with the rear of the initially stopped train, but decided that simulating that sort of thing would be infeasibly complex and that a much simpler implementation would be necessary if the system were to be completed within any reasonable amount of time.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

AP

Fair enough.  I understand the need to prioritise. Just thought I should report in case it was unexpected. 

jamespetts

Thank you for your feedback - it is always useful to know what issues that players are having.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.