Something I noticed a while ago already, but some one else on a dutch forum complained about it too.
The F8 switch window dos not allow you to throw switches.
G, Alt-Click and the Dispatch view work fine. But the "old" msts style of trowing a switch doesn't work anymore in OR.
I've no idea since when this problem is in OR.
Cheers Jordi
Page 1 of 1
Switch window not working (F8)
#2
Posted 03 February 2014 - 11:08 AM
Dear Jordi and others
I agree with you. It is not working correctly. I have found why. In SwitchWindow.cs the following code is present, that is being called when you click on the switch window.
The
Since the RequestSetSwitch code has been introduced with NEW_SIGNALLING, I think that this is indeed the reason why the working of the switch window changed and is no longer working. Unfortunately, I do not know the exact idea behind RequestSetSwitch, so I can also not fix it. I guess Rob has to do this.
Best regards, Jeroen.
I agree with you. It is not working correctly. I have found why. In SwitchWindow.cs the following code is present, that is being called when you click on the switch window.
void SwitchForwards_Click(Control arg1, Point arg2) { #if !NEW_SIGNALLING if( Owner.Viewer.Simulator.SwitchTrackAhead(Owner.Viewer.PlayerTrain) ) #else if (Signals.RequestSetSwitch(Owner.Viewer.PlayerTrain, Direction.Forward) ) #endif { new ToggleSwitchAheadCommand(Owner.Viewer.Log); } }
The
Signals.RequestSetSwitch(Owner.Viewer.PlayerTrain, Direction.Forward)toggles the switch. Then
new ToggleSwitchAheadCommand(Owner.Viewer.Log);does two things: toggle the switch (again), and show a line on screen that the switch has been toggled. The last command is the same command that is being called also when pressing G. But the end-effect is that the switch is toggled twice. Which in the end means no net effect. Something similar happens for toggling switch behind.
Since the RequestSetSwitch code has been introduced with NEW_SIGNALLING, I think that this is indeed the reason why the working of the switch window changed and is no longer working. Unfortunately, I do not know the exact idea behind RequestSetSwitch, so I can also not fix it. I guess Rob has to do this.
Best regards, Jeroen.
#3
Posted 04 February 2014 - 01:34 AM
The switch is not set twice - the construction with the "ToggleSwitchAheadCommand" and "new ToggleSwitchAheadCommand" has to do with generating the required replay commands.
Setting switched manually is blocked when the player train is in AUTO mode. The player will have to switch to MANUAL mode (using CTRL-M) if setting switches manually is required.
The reason behind this is that the player train path is the main element used in signalling and deadlock processing. Throwing switches while paths and 'deadlock' traps have been set would seriously undermine the stability of this process. The processing in MANUAL mode is different from AUTO mode, for instance there is no 'deadlock' processing in MANUAL mode.
This required mode change from AUTO to MANUAL is different from MSTS - but the entire processing of signalling and train control is different. Probably everybody has run into a 'deadlock' situation in MSTS, sitting face to face with an opposite train in the middle of nowhere. OR has extensive processing to avoid that - the required toggle between AUTO and MANUAL mode is the price to pay.
Regards,
Rob Roeterdink
Setting switched manually is blocked when the player train is in AUTO mode. The player will have to switch to MANUAL mode (using CTRL-M) if setting switches manually is required.
The reason behind this is that the player train path is the main element used in signalling and deadlock processing. Throwing switches while paths and 'deadlock' traps have been set would seriously undermine the stability of this process. The processing in MANUAL mode is different from AUTO mode, for instance there is no 'deadlock' processing in MANUAL mode.
This required mode change from AUTO to MANUAL is different from MSTS - but the entire processing of signalling and train control is different. Probably everybody has run into a 'deadlock' situation in MSTS, sitting face to face with an opposite train in the middle of nowhere. OR has extensive processing to avoid that - the required toggle between AUTO and MANUAL mode is the price to pay.
Regards,
Rob Roeterdink
#4
Posted 04 February 2014 - 02:13 AM
roeter, on 04 February 2014 - 01:34 AM, said:
The switch is not set twice - the construction with the "ToggleSwitchAheadCommand" and "new ToggleSwitchAheadCommand" has to do with generating the required replay commands.
Are you absolutely sure it's not switching twice? All the commands I've looked at in the past do indeed execute their 'action' locally as well as in a replay.
#5
Posted 04 February 2014 - 02:55 AM
Dear Rob,
I ran through it with the debugger, and I did find it switching twice. And yes, it was in manual mode, and G was working as expected (switching only once, also in the debugger).
Jeroen.
I ran through it with the debugger, and I did find it switching twice. And yes, it was in manual mode, and G was working as expected (switching only once, also in the debugger).
Jeroen.
#6
Posted 04 February 2014 - 12:50 PM
Dear all,
let me try to make the situation a bit clearer on what I am doing and not doing.
So I moved to manual mode. I opened the switch window (F8). In that case there are two ways to toggle the switch.
1: Press G. This works. You see a message on screen 'Switch ahead change'
2: Press the left mouse button on top of the forward switch picture in the switch window. Also now the message 'switch ahead change' appears, but nothing seems to happen.
When I do the same with a breakpoint in the method ProcessRequestManualSetSwitch, I see the following:
In case 1, the method ProcessRequestManualSetSwitch in Train.cs is called once.
In case 2 it is called twice.
This is not related at all to the issues you described in some other post related to alt-mouse clicks on the game window itself (and where apparently recent updates have been added). This is really only about the switch window which does not work as expected.
A bit more details.
Signals.RequestSetSwitch contains
Looking at this, I am still very strongly convinced that the switching is done twice. I cannot judge the exact relation to replay, but it seems to me that the
Best regards, Jeroen.
let me try to make the situation a bit clearer on what I am doing and not doing.
So I moved to manual mode. I opened the switch window (F8). In that case there are two ways to toggle the switch.
1: Press G. This works. You see a message on screen 'Switch ahead change'
2: Press the left mouse button on top of the forward switch picture in the switch window. Also now the message 'switch ahead change' appears, but nothing seems to happen.
When I do the same with a breakpoint in the method ProcessRequestManualSetSwitch, I see the following:
In case 1, the method ProcessRequestManualSetSwitch in Train.cs is called once.
In case 2 it is called twice.
This is not related at all to the issues you described in some other post related to alt-mouse clicks on the game window itself (and where apparently recent updates have been added). This is really only about the switch window which does not work as expected.
A bit more details.
Signals.RequestSetSwitch contains
if (thisTrain.ControlMode == Train.TRAIN_CONTROL.MANUAL) { return (thisTrain.ProcessRequestManualSetSwitch(direction)); } else if (thisTrain.ControlMode == Train.TRAIN_CONTROL.EXPLORER) { return (thisTrain.ProcessRequestExplorerSetSwitch(direction)); } return (false);ToggleSwitchAhead will call, amongst others, from Viewer3D
public void ToggleSwitchAhead() { if (PlayerTrain.ControlMode == Train.TRAIN_CONTROL.MANUAL) { PlayerTrain.ProcessRequestManualSetSwitch(Direction.Forward); } else if (PlayerTrain.ControlMode == Train.TRAIN_CONTROL.EXPLORER) { PlayerTrain.ProcessRequestExplorerSetSwitch(Direction.Forward); } }
Looking at this, I am still very strongly convinced that the switching is done twice. I cannot judge the exact relation to replay, but it seems to me that the
if (Signals.RequestSetSwitch(Owner.Viewer.PlayerTrain, Direction.Forward) )is no longer needed.
Best regards, Jeroen.
Page 1 of 1