[R H Steele]

Does the Alt-mouse control still work for switches? Mine seems to have quit. Mouse checks ok. Also the mouse uncouple (mouse+U) has also stopped working.

[Csantucci]

Alt-mouse works, however switches within the forward and backward path of the train can't be thrown (at least in explore mode). Try any switch outside of the path and you should see it working.

[markus_GE]

Can they be thrown with the keyboard shortcuts? If so, why can´t they be changed with the mouse?

Cheers, Markus

[R H Steele]

Csantucci, on 29 January 2014 - 12:53 AM, said:

Alt-mouse works, however switches within the forward and backward path of the train can't be thrown (at least in explore mode). Try any switch outside of the path and you should see it working.

Not quite true, in V09 one could switch to manual and control all switches with mouse+alt. This of course influenced signals and AI traffic, as it should. However, in some activities switching to manual is required and others where no AI is present I usually run in manual (like to throw the switches myself). Somewhere between V09 and Vx1955 this feature was changed. Why or how??. You can no longer switch to manual and control switches with mouse+alt. The attached images illustrate my point. All were taken using the WPSub, Act: NCE Mill Run. The screenshots show the activity as loaded in V09 auto mode, V09 manual with three switches thrown and lastly in Vx1955 in manual - no switches thrown - unable to do so. The feature worked with any switch, even from within the cabview - nice for rear switching.

Attached thumbnail(s)

• 
• 
• 

[R H Steele]

The loss of mouse+alt switching function is between Vx1881 and Vx1900 (build 0.05109.33132). I don't have any versions in between these two. I only download the weekly Friday experimentals. I really hope this is inadvertent, the feature is an excellent one I would hate to loose.

Edit: While using manual mode in an activity the alt+mouse switch control does not function with switches in the player path.

[roeter]

It's a bit more complicated than that the function was just 'removed'.
In fact, it still works for facing points (as seen in the direction of the train's path, and even if a signal is cleared over that switch) - the problem lies mainly with trailing points.

First some background - in particular to the difference of control with Alt+Mouse and with G/Shift-G.

When using G/Shift-G, it is clear that the switch to be operated is the first switch ahead / behind the train. When the switch is thrown, the train's path is reset accordingly but if there was a cleared signal over the switch that signal is now reset. This applies to both facing and trailing switches.

When using Alt+Mouse, and assuming the switch is in the train's path, it can be anywhere along that path. In particular, Alt+Mouse is often used in more complex areas where using G/Shift-G would be problematic due to the close proximity of various switches etc. Therefor, it was decided that the train's path should be maintained and realigned, so any signals which were cleared will be cleared again but over the new path. And that's where the trouble starts.

This difference may be debatable but let's stick with it for the time being.

So, what's happening?
Well, as indicated, the path of the train will be reset, and any signals which were cleared will be cleared again. In resetting the route, the manual position of switches is taking into account, and the switches will be set accordingly - but that applies only to facing switches. For trailing switches, it was checked if the switch was properly aligned (and it was for the path ran over it), and if so no further action was taken. That is wrong, and that has been corrected in version X1971.
However, that is not the end of it.
For it has been agreed that if a signal is cleared in manual or explorer mode, any trailing switches beyond the signal will be automatically aligned. That makes sense - if the train has a clear signal one must assume there is a clear path.
So - that leads to a dilemma : if the route is reset after a trailing switch is thrown, and signals are cleared again - then that trailing switch will be automatically realigned by the signal. Adding to this problem is that once a signal is cleared in Manual or Explorer mode, it cannot be reset.
This latter point is now also tackled in X1971 - new commands have been added (CTRL-TAB and CTRL-SHIFT-TAB) which will reset a cleared signal in Manual and Explorer mode.

So, to summarize it all, as of version X1971 :

• Using G/Shift-G :
  
  • Switch will always be thrown.
    
  • Train's path is adjusted accordingly.
    
  • Any cleared signals with path leading over that switch will be reset.
  
  
• Using Alt+Mouse :
  
  • Switch will be thrown if it is not in the train's path.
    
  • Switch will be thrown if it is in the train's path but is not part of a path cleared by a signal.
    The train's path will be adjusted.
    
  • If the switch is part of a path cleared by a signal, and it is a facing switch (as seen in the direction of the signal path), it will be thrown and the signal path and signal aspect (if applicable) will be adjusted accordingly.
    
  • If the switch is part of a path cleared by a signal and it is a trailing switch, it can not be thrown using Alt+Mouse.
    In that situation, the signal must first be reset using CTRL-TAB or CTRL-SHIFT-TAB.

Regards,
Rob Roeterdink

[cjakeman]

roeter, on 30 January 2014 - 02:38 AM, said:

Using Alt+Mouse :

• • Switch will be thrown if it is not in the train's path.
  • Switch will be thrown if it is in the train's path but is not part of a path cleared by a signal.
    The train's path will be adjusted.
  • If the switch is part of a path cleared by a signal, and it is a facing switch (as seen in the direction of the signal path), it will be thrown and the signal path and signal aspect (if applicable) will be adjusted accordingly.
  • If the switch is part of a path cleared by a signal and it is a trailing switch, it can not be thrown using Alt+Mouse.
    In that situation, the signal must first be reset using CTRL-TAB or CTRL-SHIFT-TAB.

Should we add some Confirmer messages to say why the switch has not been thrown?

[R H Steele]

roeter, on 30 January 2014 - 02:38 AM, said:

It's a bit more complicated than that the function was just 'removed'.

In particular, Alt+Mouse is often used in more complex areas where using G/Shift-G would be problematic due to the close proximity of various switches etc.

Regards,
Rob Roeterdink

I'll say. Taking more time to digest this information. Alt+Mouse in complex areas is exactly where I found it most useful. I thought it was wonderful that it worked from the cabview, hope that will be kept.

Your time in making this response is gratefully appreciated!
Rob, Thanks very much.

[Eldorado.Railroad]

From 30 January 2014 - 02:38 AM:

It's a bit more complicated than that the function was just 'removed'.
In fact, it still works for facing points (as seen in the direction of the train's path, and even if a signal is cleared over that switch) - the problem lies mainly with trailing points.

First some background - in particular to the difference of control with Alt+Mouse and with G/Shift-G.

When using G/Shift-G, it is clear that the switch to be operated is the first switch ahead / behind the train. When the switch is thrown, the train's path is reset accordingly but if there was a cleared signal over the switch that signal is now reset. This applies to both facing and trailing switches.

When using Alt+Mouse, and assuming the switch is in the train's path, it can be anywhere along that path. In particular, Alt+Mouse is often used in more complex areas where using G/Shift-G would be problematic due to the close proximity of various switches etc. Therefor, it was decided that the train's path should be maintained and realigned, so any signals which were cleared will be cleared again but over the new path. And that's where the trouble starts.

This difference may be debatable but let's stick with it for the time being.

So, what's happening?
Well, as indicated, the path of the train will be reset, and any signals which were cleared will be cleared again. In resetting the route, the manual position of switches is taking into account, and the switches will be set accordingly - but that applies only to facing switches. For trailing switches, it was checked if the switch was properly aligned (and it was for the path ran over it), and if so no further action was taken. That is wrong, and that has been corrected in version X1971.
However, that is not the end of it.
For it has been agreed that if a signal is cleared in manual or explorer mode, any trailing switches beyond the signal will be automatically aligned. That makes sense - if the train has a clear signal one must assume there is a clear path.
So - that leads to a dilemma : if the route is reset after a trailing switch is thrown, and signals are cleared again - then that trailing switch will be automatically realigned by the signal. Adding to this problem is that once a signal is cleared in Manual or Explorer mode, it cannot be reset.
This latter point is now also tackled in X1971 - new commands have been added (CTRL-TAB and CTRL-SHIFT-TAB) which will reset a cleared signal in Manual and Explorer mode.

So, to summarize it all, as of version X1971 :

• Using G/Shift-G :
  
  • Switch will always be thrown.
    
  • Train's path is adjusted accordingly.
    
  • Any cleared signals with path leading over that switch will be reset.
  
  
• Using Alt+Mouse :
  
  • Switch will be thrown if it is not in the train's path.
    
  • Switch will be thrown if it is in the train's path but is not part of a path cleared by a signal.
    The train's path will be adjusted.
    
  • If the switch is part of a path cleared by a signal, and it is a facing switch (as seen in the direction of the signal path), it will be thrown and the signal path and signal aspect (if applicable) will be adjusted accordingly.
    
  • If the switch is part of a path cleared by a signal and it is a trailing switch, it can not be thrown using Alt+Mouse.
    In that situation, the signal must first be reset using CTRL-TAB or CTRL-SHIFT-TAB.

Regards,
Rob Roeterdink

Should this not be "SPIKED"?

[roeter]

cjakeman, on 30 January 2014 - 10:48 AM, said:

Should we add some Confirmer messages to say why the switch has not been thrown?

The problem is that the action is not actually blocked. The switch is thrown when Alt+Mouse is clicked - but it is immediately reset again by the signal. It would require additional flags in order to know that the switch has just been thrown by the player - but that flag might also be set for other switches which have also been set in this sequence but before the routing was changed by the last set switch etc. - all pretty complicated. Also, some of the 'lower' routines where these actions are performed have no 'link' to the viewer to be able to send a confirm message - that further complicates matters.

Regards,
Rob Roeterdink