[gpz]

Just for the other developers information: Currently there is a problem with mouse operated notch controllers repeatability. (There are a lot of them: throttle, brake, engine brake, dynamic brake, gearbox, cutoff, blower, damper, firebox door, water injector 1 and 2.) The problem is that with mouse control it is not possible to use the various NotchedCommands and ContinuousCommands used for keyboard operation, because with mouse one can set any value almost immediately, and can hold the control active for indefinitely long time. Ad absurdum, one can grab the brake controller at the start of the activity, and keep it grabbed with his mouse till the end.) So there is no definite end of command, when the ContinuousCommand could be called. Alternatively, if a new ControllerSetValueCommand would be defined, calling that could easily flood the command buffer. I'm not sure about the solution, so I would ask for advice about it. The solution would be similar to how the RailDriver commands are stored for repeatability, but I'm afraid that functionality was also unimplemented...

[James Ross]

gpz, on 27 December 2014 - 11:13 AM, said:

Just for the other developers information: Currently there is a problem with mouse operated notch controllers repeatability.

I don't know if it's possible in the current scheme of things, but could we have specific locomotive controls/inputs be manipulated by two different controllers? One is continuous and one is discrete - like you mentioned, the discrete one could be used for mouse and RailDriver input. It just needs to record current time and the new value. Are there any serious problems with that? Other than "what happens when you use both at once" which to be honest is never going to work well (using keyboard and mouse or keyboard and RailDriver on the same control).

[copperpen]

James Ross, on 27 December 2014 - 12:30 PM, said:

{...................................}is never going to work well (using keyboard and mouse or keyboard and RailDriver on the same control).

MSTS has that capability, keyboard or mouse on the same control. Personally I never use mouse control, except for steam throttle when in the cab.

[gpz]

James Ross, on 27 December 2014 - 12:30 PM, said:

I don't know if it's possible in the current scheme of things, but could we have specific locomotive controls/inputs be manipulated by two different controllers? One is continuous and one is discrete - like you mentioned, the discrete one could be used for mouse and RailDriver input. It just needs to record current time and the new value. Are there any serious problems with that? Other than "what happens when you use both at once" which to be honest is never going to work well (using keyboard and mouse or keyboard and RailDriver on the same control).

Generally it's a good idea. Maybe it is not necessary to use two controllers, maybe it is enough if a new command was buffered every time the smooth controller change exceeds a given threshold, e.g. 10%. The replay will never be perfect this way, but maybe good enough. I'll have a go.

[James Ross]

copperpen, on 27 December 2014 - 01:57 PM, said:

MSTS has that capability, keyboard or mouse on the same control. Personally I never use mouse control, except for steam throttle when in the cab.

I meant on the same control at the same time, i.e. hitting a key for the control you're currently dragging with the mouse. I don't think we should really mind what happens in this case, as long as it doesn't completely break/crash, that's all.

[gpz]

Sid P., on 27 December 2014 - 09:54 AM, said:

GP-38 has reversed mouse control of the direction lever, I think.

You are right. But I don't understand how it is set up, since both throttle and reverser have the control setting

Orientation ( 0 )
DirIncrease ( 1 )

which means they are horizontal and increasing from right to left. This seems like a quest, solution is appreciated.

[Sid P.]

Hi Peter,
I'm thinking out loud here...
I am beginning to think there is another aspect to cabview files - how does MSTS know which picture in the set of images has the control at the left ?
Note that the throttle lever's first picture is a lever to the right, and the direction lever's first picture is a lever to the left, but they both have the same indicated direction of increase = 1.
The MSTS cabview editor says they both "increase to the left". How does it know which picture is which? I must be overlooking something.
Also, I notice MSTS has a different mouse behavior when there are only three positions, or two positions, or multiple positions - sometimes it shows a + or - sign to indicate what will happen when you move the mouse.
It reminds me of some head scratching when we were trying to make the needles on the dials move correctly.

Cheers,
Sid

[Csantucci]

I'm here to add a further element of confusion...
In my country they made some tests about the MSTS behaviour for specific command Types() and specific Style() types.
What came out is that, for specific commands, MSTS does not consider the Style() and considers only the command.
To be more specific with some example: for Type ( PANTOGRAPH TWO_STATE ) you can put either Style(ONOFF) or Style(PRESSED) : in both cases MSTS behaves the same, that is with a single click and release you change panto position. For Types (SANDERS TWO_STATE) or (HORN TWO_STATE) instead the command remains active from the moment you press the mouse (or the keyboard key) to the moment you release it, and this both with a Style(PRESSED) and a Style(ONOFF).
As there is a large installed basis of trainsets, it would not be bad if ORTS could behave the same way (maybe under the Enhanced MSTS Compatibility option, if one wants to keep also the "pure" version).

[Sid P.]

Csantucci, on 28 December 2014 - 12:18 AM, said:

What came out is that, for specific commands, MSTS does not consider the Style() and considers only the command.

Yes, I just did some tests with MSTS on the direction lever data in the .cvf file. MSTS knows that it is working on the direction control from the name, I assume.
It knows that there are three images; it does not care if the definition is ( 3 1 3 ) or ( 3 3 1 ) - it draws the lever positions correctly !
Even if you enter the wrong value for the dirIncrease, it shows a + sign when a key press will move to a forward condition, a - sign when moving backwards
and works as you would expect. So I can make the values correct for ORTS and they still work fine for MSTS...
So one has to be careful in studying .cvf files to determine what the rules are.

MSTS also includes detents for the train brake, so that it takes an extra click to move to release, for example.

Cheers,
Sid.

[gpz]

In r2744 I added the MSTS specialities as exceptions/overrides. Now GP38 reveser, horns, and others listed in this topic should work as in MSTS. Carlo, if you have some more of these, please feel free to add them to CVFFile.cs at about line 870.