Elvas Tower: Changes to MP signalling and Train Control - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 6 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

Changes to MP signalling and Train Control First phase now committed Rate Topic: -----

#1 User is online   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 14 December 2013 - 06:37 AM

Version X1889 sees the release of the first phase of the extensive rework for signalling, train control and dispatcher control for MultiPlayer.
Please note that this is very much still a work in progress. Further changes to train control and dispatcher control will be introduced later. This first phase likely does not provide all controls now available or required for everything players want to be able to do.

Some background information.
When the new signalling was introduced early this year, the existing multiplayer controls could no longer be used because these did not match the new signalling logic. Temporary solutions were implemented to enable MP to run in the new environment, but to make this work a large number of exceptions specific for MP had to be introduced in the signalling code. These exceptions, however, introduced some problems, like for instance the running of AI trains, which led to further exceptions etc. As a result, maintaining the signal and train control code has become increasingly difficult. Introduction of changes which are envisaged for the Activity Editor would be seriously hampered by these exceptions, in particular in applying these changes to MP. Therefor it was decided to rework the signalling and train control for MP, in order to bring it in line with single player working and thus remove most of these exceptions.

Overview of changes
The changes apply to three major areas :
  • Signalling control : all signalling control for MP is now concentrated in the server.
  • Train control : additional train control modes for MP are introduced; explorer mode is no longer used in MP.
  • Dispatcher control : all dispatcher functions have been revised, and all dispatcher actions are worked through the signalling logic.


Details
Note : the details below list all envisaged changes, that is those implemented in this first phase as well as those yet to be provided.
  • Text in italics show changes which are yet to be implemented.
  • Text in bold shows restrictions which apply in this first phase.
    These restrictions will be lifted later, partly by the items allready shown in italics, partly by further changes for which details have yet to be worked out.


Signalling control
All signalling control will now take place in the server. This process is in most parts the same as would be run in single player mode. Each train has its path, and will try and clear this path using the normal control logic.
The main difference between MP and SP mode is how trains build their path (as detailed in the train control functions below), but this does not affect the signalling as such.
To provide the clients with all required details for signalling and track states, the server now also broadcasts the track circuit states, additional to signal and switch states. This is used, for instance, in the dispatcher display window at the clients.
In clients, only a 'token' signalling process is run, for the player train related to that client only, and its only purpose is to provide information for trackmonitor window and in-cab signal and speedlimit display.

Train control
New train control modes are introduced for use in MP. These partly replace and partly overlap existing train control modes, as detailed below.

Wait dispatcher mode
When a player starts a session in Explorer mode, the train will start in Wait dispatcher mode. The train will have a valid route upto the first signal only. Only the dispatcher will be able to clear this signal. The player cannot change to any other mode, set switches, clear signals etc.
At present, the train can be taken out of this mode only when the dispatcher clears the signal ahead of the train.
MP can therefor not yet be used on unsignalled routes.
Also, it is not yet possible to take the train out of this mode by clearing the signal behind the train, i.e. to reverse the train's route.

When the dispatcher clears the signal ahead of the train, the train will move to Roam mode.

Roam mode
In roam mode, the train clears its path in a way very similar to the normal single player situation. The main difference is that the train has no preset path, but will build its path as it moves along. Signals ahead will be cleared according to the normal signal logic, and the paths as build will follow the switches as they are set - that is, either as set by dispatcher or player, or as left after passage of previous train, or the default position.
Note that deadlock control is not active in Roam mode, it is up to the dispatcher to avoid deadlocks.
When in Roam mode, the player can switch to Manual mode for shunt moves etc.
At present it is not possible to reverse the route of a train in Roam mode.
How to reverse the path of a train in this mode has yet to be decided. The most likely way is to switch the train back to Wait Dispatch mode, provided this mode has been extended to allow clearance of signals in both directions. But how the train will switch back to Wait Dispatch, and if this can be done by player and/or dispatcher, is still all to be decided.

Pathed mode
When a player starts a session using an activity, the train will start in Pathed mode. AI trains (which can be started on server only) will always start in Pathed mode.
Pathed mode control is similar to control when starting an activity in single player mode. The train clears its path ahead, setting switches according to its preset path.
Trains in Pathed mode cannot be taken off their path. If a switch is locked by the dispatcher in a position which does not correspond with the train's path, the train will be stopped as the signal will not clear.
In Pathed mode, the player can switch to Manual mode for shunt work.
The dispatcher can switch a train in Pathed mode to either TempRoam mode (player trains only), or Full Dispatcher mode (player and AI trains) - see below.
When a player train reaches the end of the preset path, the train mode will change to Wait Dispatcher mode, allowing the player to continue in Roam mode.
When an AI train reaches the end of its path it will be removed.

Manual mode
Manual mode working in MP is similar to the working in SP.
The only difference is when the player ends Manual mode and switches back to controlled mode :
  • When switching back if train was started in Pathed mode, and the train is on the preset path, the train will return to Pathed mode.
  • In all other situations, the train will switch to Wait Dispatcher mode - the dispatcher must clear the signal ahead of the train to allow the train to continue, which it then will do in Roam mode.


Temp Roam mode
When in Pathed mode, the dispatcher can switch a train to Temp Roam mode. This will allow the dispatcher to take the train off its preset path. In Temp Roam mode, the train control is similar as to the Roam mode. When the train is back on its preset path, the dispatcher (or perhaps the player as well) can switch back to Pathed mode.
This mode is available only for player trains.


Full Dispatch mode
When in Pathed mode, the dispatcher can switch a train to Full Dispatch mode. In this mode, the train will not build a path or attempt to clear signals - it is up to the dispatcher to clear all signals ahead of this train (except for signals with fixed routes or signals set to automatic [see below]; as these signals have no choice of route they will cleared by default). This mode is available for both player and AI trains. When the train is back on its path, the dispatcher can reset the mode to Pathed mode.

Dispatcher control
Both display and control have been fully reworked.

General remark on display
As the server broadcasts sections states as well as signal and switch states, all dispatcher windows (at server or at clients) will always show the same information, based on these broadcasts.

Track display
The dispatcher display now shows the actual track circuit states, not the (plausible) route based on signal and switch states.
The following states are shown :
  • Red : track occupied.
    The track circuit section is occupied by one or more train(s). Note that the full section is always shown in red, so not only in front of the train but also behind the train.
  • Dark green : track reserved.
    The track circuit section is reserved by an approaching train and a signal has been cleared over this section.
  • Light green : track reserved by signal.
    A signal has been cleared manually over this section, but no train is as yet approaching that signal.


Note that the display is still based on MSTS track sections, while track circuit sections are based on node and signal positions. These latter will not coincide with MSTS track section positions, so track circuit section display will either stop short or overlap the signal positions.

A change in the position calculation has improved the general layout of tracks in the dispatcher display window, making it more smooth.

Signal display
Signals are displayed in colour according to their state :
  • Red : state STOP.
  • Green : state CLEAR_1 or CLEAR_2.
  • Orange : any other state.

Difference with present display is that states STOP_AND_PROCEED and RESTRICTING will now be shown in orange rather than red.

When a signal is set to Hold by dispatcher, the head of the signal is shown as a line and not as a circle.
There is a slight miscalculation of this line, making it look a bit awkward at the moment.

Switch display
Switches are displayed as black circles if main route is set, or grey circles if diverging route is set.

Dispatcher controls
As the control windows now contain multiple selectable options, the window is not removed when a selection is made, but only when the mouse is moved out of the window.

Switch controls
Switches can be set as follows :
  • System Control
  • Main path
  • Side path


When the switch is not under system control (i.e. it is controlled by the dispatcher), the following further options are available :
  • Facing lock all.
    The switch is locked in the selected position, but only in facing direction.
    The switch may be set as required by trains approaching the switch in trailing direction.
  • Facing lock notPathed.
    As above, except that it only applies to not-pathed trains. Pathed trains can set the switch as required according to their preset path.
  • Trailing lock.
    Switch is locked for trains approaching in trailing direction.
  • Release switch.
    When a route has been cleared over a switch (line shown as red, dark or light green), the switch is locked and can no longer be operated.
    This function will release the switch lock, but only under certain conditions :
    • If locked by signal route (light green, no train approaching), the signal will be reset.
    • If locked by train (dark green or red ahead of train) : train must be at standstill, or must be clear of last signal ahead of switch and far enough away from that signal to be able to stop in time.
    • If locked by train (red behind train) : train is not clear of switch overlap position (train is therefor still fauling the switch), switch can not be released.



Signalling control
The following options are available for signalling control :
  • System control.
  • Hold all.
    The signal is held at state STOP for all trains.
  • Hold notPathed.
    The signal is held at state STOP for not-pathed trains only. Pathed trains can clear the signal as if it were under system control.
  • Clear once.
    Available both when in System control or when in either Hold state.
    The signal will clear but only within the contraints of the normal signal rules.
    If, for instance, the track ahead is occupied or reserved, or a route is selected which does not match the signals routing condition, the signal will not clear.
    At present, there is no feedback to the dispatcher if a signal will not clear.
    After the train has passed the signal it will revert to the previous state.
  • Clear once, overrule.
    As above, but any switch locks will be overruled.
  • Grant Permission.
    Permission will be granted for a train to pass the signal at danger. Only has effect when a train is actually waiting for that signal, it cannot be set beforehand.
    Permission will always be granted, regardless of the signal control rules. It is up to the dispatcher to ensure the 'safety' of the train(s).
  • Additional functions - see list below.


Additional functions (all yet to be implemented) :
  • Test.
    This will show the route (in orange) if the signal was to be cleared at this moment.
    Can be used by the dispatcher to verify the correct switch settings in complex areas.

  • Set route manual.
    Rather than clearing the signal and set switches using switch control, the dispatcher can 'build' a route by selecting the nodes in sequence on the path the train is to take.
    Unlike normal signal clearing, the route can be terminated short of the next signal.
    This control can be used to take trains into unsignalled yards etc., stopping short of the next signal.

  • Automatic.
    This will set the signal to System Control, using the present route from the signal as 'fixed' route.
    All switches in the route from this signal will be locked.
    This can be used for signals which controls switches into or out of little used sidings etc., allowing the signals to clear by default on the fixed path thus reducing the workload for the dispatcher.


Train Control
No train control functions are yet available, and the way these will be made available has yet to be decided.

Regards,
Rob Roeterdink

#2 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,862
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 14 December 2013 - 08:44 AM

Sounds like great News :)

But allow me one question and one proposal:

Q: Does this update also include a solution to the Loop Problem I brought up in another thread? (System.ArgumentOutOfRange Exception)

P: Re

Quote

Switch display
Switches are displayed as black circles if main route is set, or grey circles if diverging route is set.


As of what I have seen from the old Dispatcher Window, it can at times be hard to determine, which route will be the main, which the diverging one of a Switch. So, I feel, colour differences might at times not be enough to really determine which way is set. I would propose some arrow-based method o be added to this (keeping the black / Grey info). But, as said, just a proposal :)

CHeers, Markus

#3 User is online   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 14 December 2013 - 09:01 AM

View Postmarkus_GE, on 14 December 2013 - 08:44 AM, said:

Does this update also include a solution to the Loop Problem I brought up in another thread? (System.ArgumentOutOfRange Exception)


Yep - one of a whole series of small corrections and changes which somehow got caught up in all this.

Quote

As of what I have seen from the old Dispatcher Window, it can at times be hard to determine, which route will be the main, which the diverging one of a Switch. So, I feel, colour differences might at times not be enough to really determine which way is set. I would propose some arrow-based method o be added to this (keeping the black / Grey info). But, as said, just a proposal :)


Very hard to do and would also not be very clear either when switches are close together.
But this is why the 'test' function for signals will be added : it shows where the route is going, and by changing a switch you will see the effect this has on the route.

Regards,
Rob Roeterdink

#4 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,862
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:ORTS / MSTS
  • Country:

Posted 14 December 2013 - 09:03 AM

REALLY good News then :) :)

Ah, sorry, must have overread the Test funvtion. Skipped back, and saw that it should actually just help in determining These Information :)

Cheers, Markus

#5 User is offline   captain_bazza 

  • Chairman, Board of Directors
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 13,927
  • Joined: 21-February 06
  • Gender:Male
  • Location:Way, way, way, South
  • Simulator:MSTS & OR
  • Country:

Posted 14 December 2013 - 01:07 PM

A very comprehensive update, thank you.

Cheers Bazza

#6 User is offline   PA1930 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 782
  • Joined: 16-December 12
  • Gender:Male
  • Simulator:-
  • Country:

Posted 14 December 2013 - 04:43 PM

Really great work, Rob! I am quite happy with the "new interface" on the dispatcher window. :) Pretty amazing even for just single player simulation...

Though as for MP, I don't know if this is a known issue or not, but I got a weird bug with it on MP. I was running a train and I wanted to change a junction, but it was telling me something like "Switching Request Denied" - I don't know why...
And when I was reversing the train, something odd happen... the train froze, I couldn't brake it and it stood there at 51km/h and I don't really know what happen... The only thing I remember was that it passed through that same junction where it was being denied my request to change it. So, I don't really know...

#7 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 15 December 2013 - 03:31 AM

Rob,
you had a big job!
I agree with Pedro that there is some useful improvement in the interface.
However I found also some problems in my test. You can find a bug report in Launchpad, where maybe not all problems reported are bugs.

#8 User is online   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,420
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 16 December 2013 - 06:04 AM

Gents, you're taking far too great a byte out of this cake for now.
Please read again the first paragraph of my introduction - things are far from completed.
So, as also stated above, reversing doesn't work yet. Also, throwing in complex shunt moves at this stage (and it's not clear if you switched to manual mode for that) is also too much of a good thing.

So can we please take this from the start : let's see if it is possible to get a train from start to finish over the required route just moving forward - and then check on what problems this is still causing?
When that's done, we can move a bit further on - allthough still limited by what is implemented so far.

Thanks,
Rob Roeterdink

#9 User is offline   APK-LVDZ 

  • Apprentice
  • Group: Status: Inactive
  • Posts: 44
  • Joined: 10-November 12
  • Gender:Male
  • Location:Riga, Latvia
  • Simulator:MSTS, OpenRails
  • Country:

Posted 16 December 2013 - 02:01 PM

Very big thanks! :clapping:

I have one suggestion:
- for any aspect dispatcher can use individual color. This will resolve problems with "Orange" for STOP_AND_PROCEED (or others) for russian or any other country signals, and helps to peoples, which cannot watch the changing red and green signal in dispatcher window. Can be make properties of multilayer signal working with all others functions. For example, for using colors: Red, Green, Yellow, Orange, Blue, Gray, or all RGB colors.

We all thank You :D
http://www.imghost.in/thumbs/2013-10/06/fgxm2y4lply2w5erflpmykeyh.jpg

#10 User is offline   JTang 

  • Open Rails Developer
  • Group: Status: Active Member
  • Posts: 643
  • Joined: 18-November 10
  • Gender:Male
  • Country:

Posted 17 December 2013 - 05:23 AM

There are some suggestions:
1. Please restore the red cross when a train path is not valid (i.e. passing through a misaligned switch), which will help the dispatcher to quickly identify problems.
2. Currently switch and signal are connected, i.e. change signals will change switches, but not the other way. I think this is too much a restriction. Dispatcher should be able to throw switches, and signals should be computed from signal scripts based on route_set and next_signal.

  • 6 Pages +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users