[Weter]

Hello.
I only would suggest, that having increment equal to 0,1 for each lever's step, it seems for me, using third number such big, as 0.1 will put your control at risk to be switched inaccurate between adjacent positions. Hence, in case of problem with precicion throttle positions setting, try to decrease 3-rd value, say to 0,05 or so.

[jonas]

Hi, the brake lever of the MSTS steam locomotive "Flying Scotsman":


OR interprets the original Kuju code to "NumPositions" and "NumValues" differently, although it looks reasonable and works as expected in MSTS.

cvf file

		Lever (
			Type ( TRAIN_BRAKE LEVER )
			Position ( 549 251 60 139 )
			Graphic ( TrainBrake.ace )
			Style ( SPRUNG )
			MouseControl ( 1 )
			NumFrames ( 12 6 2 )
			NumPositions ( 3 0 4 6 )
			NumValues ( 3 0 0.4 0.5 )
			Orientation ( 1 )
			DirIncrease ( 0 )
			ScaleRange ( 0 1 )
		)

eng file

            Brake_Train ( 0 1 0.01 0.65 
                NumNotches( 3
                    Notch(0 	1 TrainBrakesControllerReleaseStart )
                    Notch(0.4   1 TrainBrakesControllerRunningStart )
                    Notch(0.5   1 TrainBrakesControllerApplyStart )
                )
            )

If you change the num-lines in cvf to:

			NumPositions ( 0 )
			NumValues ( 0 )

the train brake lever will also be displayed correctly in ORTS.

[Weter]

Hello.
I can only suppose, that ORTS stops on 6-th frame, tied with 3-rd position, with value 0,5 and token "ApplyStart". Note, that here we have ranges defined, not notches only (which means, every frame should be shown, but not only three). And, I've no idea, why "sprung" then.
Does MSTS and ORTS show intermediate frames, while handle is being moved? (I mean 1,2,3,5,7-11)
What if to define every frame, tiding it to corresponding value?

[jonas]

Hi Weter,
Thanks for your immediate detailed solution-oriented post into the specific topic of the "Flying Scotsman".

Weter, on 02 March 2023 - 06:16 PM, said:

...What if to define every frame, tiding it to corresponding value?

There are surely a few working ways to accurately run the scotsman's break lever succesfully in OR.
Note, I am not looking to "fix" the Scotsman for myself in Open Rails here.

The Scotsman is an original MSTS locomotive by Kuju from 2001 and so is its code in the cvf file. Therefor the important sentence in my previous post is:

jonas, on 02 March 2023 - 04:54 PM, said:

... OR interprets the original Kuju code to "NumPositions" and "NumValues" differently, ...

And everyone can try it out for themselves on the "Flying Scotsman"...at least, those who still have MSTS :-)

Greetings
Jonas

[Weter]

Hello.
Actually, out of being sure, was that positive, or negative feedback to my thoughts...
Well, I definitely have analyzed given code and possible reasons of such outcomes.
No matter, Scotsman or Bavarian, or Kabardino-Balkarian. We discuss control's animation.
This is rare for me case, as most controls, being in use, are notched, so "one position-one frame" law acts:
No ranges, no smooth movement between notches... No intermediate frames - that means.
"MSTS original locomotives" are written in different ways, and also have quite serious mistakes in code.
Other question, that MSTS swallows that. ORTS - not. And You are totally right: some things are being interpreted in different way by ORTS.
If we are looking for general solutions about right control animation - that were my humble thoughts. I may be wrong certainly.
Having MSTS no errors - no need for MSTS Bin to correct them.

[jonas]

Sorry, I didn't want to give any negative feedback in my last post, but just draw out to what is important to me. This should prevent further suggestions about changing the cvf-code.

I don't see the cvf code of the "Flying Scotsman" steam loco as errored. The cvf code was written for MSTS in the days of MSTS and it works well there.
So I conclude that ORTS misinterprets this cvf code (or at least interprets it significantly different) and that's why I posted it here under "Maybe it's a bug". So, maybe it's a bug, in the ORTS code when interpreting the "NumPosition" information.

Further details:
The train brake lever texture of the "Flying Scotsman" includes 12 frames (I'm afraid to upload the texture here for copyright reasons).
The eng file specifies 3 notch ranges, ReleaseStart, RunningStart and ApplyStart. The cvf-file NumPosition entry specifies the textur frames 0, 4 and 6 for these 3 notches.
For me this means in MSTS that for the first notch (ReleaseStart) from 0% - 40% the frames 0 to 3 are shown. Then for the second notch (RunningStart) from 40% - 50% the frames 4 to 5, and finally for the third and last notch (ApplyStart) from 50% - 100% the frames 6 - 11 are shown.

Since this is how it works in MSTS, i.e. every 12 frames (from 0 to 11) are displayed continuously with the brake lever movement, I assume that the cvf code of the brake lever does not contain any error.

In fact, when I write "MSTS", I usually mean the MSTS Bin patch. In the special case here with the "Flying Scotsman" I even tested both versions, MSTS and MSTS Bin.

[Weter]

Hello and thank You.
Sorry too: since I'm not a programming-minded, my thoughts are constrained by configuration-files and my own experience/vision.

I have as a base, the statement, that "MSTS was a black box (no one, maybe exept George Vansa knew, how it's code works, as disassembling was prohibited by copyright), but there were some signs, pointing, that program was raw/unfinished, and very likely had some workarounds, added just before release, forgiving some errors in external files, like content configuration-files - for making game workable. At the same time, another errors (external and internal) caused either crashing to desktop, either "phone home" dialog's popping-up, either dialog, asking for confirmation by user"
Although ORTS certainly cAn contain its own bugs and errors, I believe, that it's true, that developing team trying hard to keep the code algorithms consequent and "fair", In handling everything, as it have to be in real life and doing so everywhere in the same way.

Summing these two assumptions, I offer to leave-out the habit of usage MSTS as an etalon, or as reliable verifying/debudding environment.
We still have to use configuration syntax, designed in MSTS times, though, what gives us simultaneously - familiar files and constrains.

That's why, answering You (who quoted *.cvf-files excerpts as an example) I've fell into analysing of that, in reference with *.eng-file's configuration (fairly quoted by You too)
We still uncertain about true reason, why some results doesn't match our expectations, so I thought it right to search an answer everywhere, we can.

I understand the "idea" of brake lever's animation in most, the same way, as You've described above: no any objections/corrections for now.
But I can argue with Your statement, that "if it works under MSTS(Bin) - that always means, that configuration files are error-free": see above for the reasons.

As an example, which I already have mentioned, ORTS sometimes "mess" numbers in num frames () parameter, swapping rows and columns numbers.
It refuses to accept different arrangement of frames for tri-state control's graphics. So I never stated, everything is perfect there.

I wish it very much, that some programmers come and join our discussion for clarifying us the actual code "laws", related to control's animation handling.
We would document it for reference then every time, we configure some cabview, and we could get an answer, what was actually right, and wrong there.

Another variant - to gain enough of courage and to investigate source code by ourselves.

[Weter]

This does work:

		Lever (		Comment( THROTTLE )
 			Type ( THROTTLE LEVER )
 			Position ( 213 298 144 139 )
 			Graphic ( CV_THROTTLE_Jm.ace )
 			Style ( SPRUNG )
 			MouseControl ( 1 )
 			NumFrames ( 12 4 3 )
 			NumPositions ( 12 0 1 2 3 4 5 6 7 8 9 10 11)
 			NumValues ( 12 0 0.01 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 )
 			Orientation ( 1 )
 			DirIncrease ( 0 )
 			ScaleRange ( 0 1 )
 		)

[jonas]

Thanks again Weter for your detailed engagement with the original problem of the thread here! I'm now fit again as far as NumPosition and NumValue are concerned. In principle as written in this post #9.

[Weter]

So, I've tested Your model, which I have downloaded here, then made its throttle working.
Consequence: although zeros for NumPositions() and NumFramse() seem enough for simple cases in ORTS, detailed data within these blocks is steel needed otherwise.
I'll try and remember that; then, I feel myself satisfied and have deleted model, consist and downloaded *.zip: Initial problem is investigated for me now.