[superheatedsteam]

That is my experience as well. I don't know of a work around.

[Csantucci]

Try with Justification ( 4 ).

[ExRail]

SYogurt, on 31 March 2024 - 12:09 PM, said:

I've been having trouble with using Justification ( 5 ) to get centered digital readouts. Justification ( 6 ) correctly leads to right alignment and ( 1 ) leads to left. The manual says ( 5 ) should be center aligned but there's no change from left alignment.
Any ideas?

Looking at mine they all LeadingZeros ( 0,1,2 ) Justification ( 5 )
The 0's are left aligned, so the justification ain't working either on my 3D panel.

[SYogurt]

Csantucci, on 01 April 2024 - 08:53 AM, said:

Try with Justification ( 4 ).

This justification shifts the text over to the right, but still left aligned. (6) works fine for right alignment but everything else leads to left.

[Csantucci]

There was an incorrect formula. Try with the attached patch for ORNYMG 151.2 (always with Justification ( 4 )). Take into account however that the resolution of the alignment is 1 character; therefore, if the max number of characters in the digital box is even and the characters in the string to be displayed is odd, or vice-versa, the string will be shifted by a half character length with respect to a precisely centered position.
 Runactivity.zip (1.43MB)
Number of downloads: 12

[ExRail]

While looking at some 3DcabRender render function trying to see what it did (I don't like these ?: long conditional statements, maybe it's only a beginner thing)
in relation to alignment it downed on me what these 4,5,6 number relates to, before it was just a number, and was it 4 or 5 for center.

[superheatedsteam]

The cab view I am working on has an Accelerometer gauge that displays km/h per minute which is a unit of measure not currently supported in the unstable version.

I have added the following to the unstable source on my pc and the code compiled without error and appears to function correctly in OR.

MSTSLocomotive.cs has the following added to CABViewControlTypes.ACCELEROMETER:

case CABViewControlUnits.KM_HOUR_MIN:
data = this.AccelerationMpSS * 3.6f * 60.0f;
break;

CabViewFile.cs has the following added to public enum CABViewControlUnits

KM_HOUR_MIN,

Do I add this as a feature suggestion in Trello?

[pschlik]

Not the first person I've seen ask for that, if you send in a trello card I can take the 10 minutes needed to set that up in unstable properly. Normally I'd want to package more things in but if it's a tiny change like this with a trello card to justify the change it won't take long to approve.

[superheatedsteam]

Thanks Phillip,

Trello card created as requested.

Cheers,

Marek.

[pschlik]

KM_HOUR_MIN is now a valid cab unit in the unstable version.

To save from annoyance in the future, I also added some tokens that can be placed in a cab view control to create custom units of measure.

• ORTSUnitsScaleFactor ( x ) - Multiplies the value shown by the cab view control by a factor of x. For example, a cab view control with units of MILES_PER_HOUR can be converted to feet per second (a unit ORTS does not support) using ORTSUnitsScaleFactor ( 1.467 ). Can be any decimal number (negative, fractional, 0...all should work). If not specified, the factor is 1 (ie: no change).
• ORTSUnitsOffset ( z ) - After the scale factor is applied, adds z to the value shown by the cab view control. For example, a cab view control with units of BAR actually shows gauge pressure specifically. This can be converted to absolute pressure in BAR with ORTSUnitsOffset ( 0.987 ). This can also be any decimal number, but negative numbers will reduce the value shown by the cab view control. If not specified, the offset is 0 (ie: no change).

These can be combined to, eg, convert from Celsius to Fahrenheit (that would be ORTSUnitsScaleFactor ( 1.8 ) and ORTSUnitsOffset ( 32 ) combined, though this is a bad example as ORTS should support both units when a temperature gauge becomes a thing), and probably do some other weird things. The point is flexibility to allow for unusual units, so imagination is the limit.

That said, I'd still recommend choosing an official unit of measure if it exists (there is no reason to use MILES and ORTSUnitsScaleFactor ( 5280 ) when FEET is already a valid unit) and submitting a feature request for any units that seem important enough to add officially. If you want to measure a force in decinewtons (0.1 newtons), that's on you, but something like kiloamps is useful and might be worth adding.