[R H Steele]

I've had no problems since this issue was fixed some months ago. I don't consider it a problem or bug now, just found a fluke. In MLT CP AC4400CW 9505 (folder name RP_CP9505) the needle is out of alignment in the Open Rails, yet appears in the correct place in the cabview editor. See attached pix. Are there any other choices besides making the alignment appear wrong in the editor so that it appears correct in Open Rails or manually massaging the numbers in the cvf file? This cabview appears like this is all the versions of OR I've tried (X2168 and X2027 plus a few in between)

Attached thumbnail(s)

• 
• 

[gpz]

I played with it a lot, and although I am not at my computer currently, IIRC the problem was as follows:

MLT needle texture has a very strange behavior. While it is asked by the .cvf file to scale up the needle, MSTS for some strange reason refuses it, and draws it unscaled. That's why it looks right in MSTS. However in an other vehicle I found (one of the Bernina Bahn consists) the .cvf file has the same type of configuration with the request for scaling up, and that texture is scaled up correctly by MSTS, and that one looks right there.

So I came to conclusion that the decision by MSTS for scaling or not-scaling is done based on the texture format. I haven't investigated it further, but it must be some DXT vs. non-DXT or mipmap vs. no-mipmap thing, or something else.

One thing is sure: The needle scaling algorithm in OR is now correct, the only thing missing is that the resizing request by .cvf must be denied in some strange and unknown circumstances.

Again IIRC, you should be able to fix the issue by modifying the .cvf not to try to scale the texture, because this is how MSTS handles it implicitly.

[gpz]

I looked into the cvf, and now I can be more specific:

Find the lines in file TRAINSET\RP_CP9505\CABVIEW\CP_AC44.cvf

		Dial (
			Type ( SPEEDOMETER DIAL )
			Position ( 315 237 2 18 )
			Graphic ( "..\\..\\MLT_Required\\MLT_Cabs\\CP_AC44\\needlegreen.ace" )

The last number (18) in Position line must be changed to 32, to reflect the needlegreen.ace texture pixel height correctly. Looks like MSTS ignores the value 18, and implicitly uses 32 instead. While OR of course tries to use value 18, and this leads to the misalignment above.

[R H Steele]

gpz, on 15 April 2014 - 08:48 AM, said:

I looked into the cvf, and now I can be more specific:

Find the lines in file TRAINSET\RP_CP9505\CABVIEW\CP_AC44.cvf

		Dial (
			Type ( SPEEDOMETER DIAL )
			Position ( 315 237 2 18 )
			Graphic ( "..\\..\\MLT_Required\\MLT_Cabs\\CP_AC44\\needlegreen.ace" )

The last number (18) in Position line must be changed to 32, to reflect the needlegreen.ace texture pixel height correctly. Looks like MSTS ignores the value 18, and implicitly uses 32 instead. While OR of course tries to use value 18, and this leads to the misalignment above.

Thanks Peter, I understand. This is going in my reference file. Good to know, it may come up again in other posts. I had a feeling that it was not a bug but an interpretation phenom.

Attached is the proof.

Attached thumbnail(s)

• 

[gpz]

Interesting thing is, on my computer the needle doesn't overhang out of the dial circle. But I tested it unstretched, will look at it stretched too. (The proof of MSTS not using that scaling value is that by altering it nothing changes in MSTS.)

[R H Steele]

I was pondering that. I've got a couple of needles that do that.

Recently I found a mismatch in my Open Rails windowed size vs the res of my system that distorted the windowed version of OR. I had picked in Option/Video 1920x1200 when my system was at 1920x1080. I am wondering if I've got some other mismatch going on that could cause the needle length to distort. Of course, I could always edit it shorter, but I don't think that's the best course until I see if it is something else.
n likely,
Rereading the above --- that's just silly, any supposed mismatches would affect far more than just the needle length.

I'm due to change over to WIN 7 Pro in two weeks (running XP now) so maybe I will wait and see if it still appears this way in Win7. Any ideas?


(The proof MSTS doesn't use that scaling value is that by altering it nothing changes in MSTS.)

That's the unseen element that I like about OR. It actually reads the data of the content file and uses that data to construct the sim. Instead of ignoring this or that, fudging something else, etc, etc. it actually will provide a dependable platform to build upon, something hopefully much more predictable and less cryptic than MSTS.