[James Ross]

markus_GE, on 18 April 2014 - 02:34 AM, said:

I know, I know, someone will now say, we have too many options already :cool3:

What about making the font.size user-adjustable, as a temporary solution? (-> Experimental Tab) I too feel, fonts are way too big, especially with some of the high resolution, wide angle photo.realistic cabs I use...

If any options are useful, it would be one in the cab view file itself (and specific to that cab control). Alas, the height information in there is too unreliable to be useful but we might be able to add a custom option.

[ATW]

Any chance that bogus unreliable option back as an option placed in cvf file?

[James Ross]

ATW, on 19 April 2014 - 12:59 PM, said:

Any chance that bogus unreliable option back as an option placed in cvf file?

That's what the custom option would do; either by specifying that "you can trust the height of this control to set the font size" or by actually specifying a font size (relative to the MSTS default font).

[Sid P.]

James Ross, on 19 April 2014 - 01:22 PM, said:

That's what the custom option would do; either by specifying that "you can trust the height of this control to set the font size" or by actually specifying a font size (relative to the MSTS default font)....
Alas, the height information in there is too unreliable to be useful but we might be able to add a custom option.

Some thoughts on this (sorry if it is long-winded) ---
The code in ORTS that produces the digital lettering is fine- it does a great job of looking after the color, decimal point display, etc. The font size problem arises from the use of a single font size for all cabviews. This choice may have resulted (see James quote above) from the wide variation in the parameters of digital display boxes in the cabview (.cvf) files, in particular the values used in the .cvf file to define the size of the digital box.

In MSTS, as was observed earlier, the values of "Width" and "Height" in the .cvf file are ignored by MSTS. (That may explain the wide range of values found.) Instead, the font size of digital displays is modified by changing an entry in the "gui_fnts.dat" file; unfortunately this changes the digital fonts in all locomotive cabview digital displays, regardless of their cab layout details.

In ORTS, the method "CabViewDigitalRenderer(...)" in MSTSLocomotiveViewer.cs uses the values of the width and height of the box in the .cvf file to set up the DrawPosition parameters to draw the digital digits, using normalizing values ( apparently of a 640x480 display). But it choses the font size based on a constant "FontScale" which is, I assume, a best-guess to cover the wide range of values found in the .cvf files.
However, this produces some sub-optimum fits for some locomotive displays, as reported above.

I suggest that ORTS should use the "Height" of each digital box to set the font size for that box, and that the values in the .cvf file be adjusted to make the display acceptable. This has the following advantages:
1. The adjustments for a particular cab require only text editing of the .cvf file, with the result immediately visible by restarting ORTS; (The MSTS Cab Editor is NOT required, except optionally to see what the boxes look like). I would be happy to write some notes on editing the files.
2. These changes in the .cvf file do not have any effect on the MSTS display;
3. The resulting font size is appropriate for the particular cab;
4. It produces an appropriate font size for varying sizes of digital boxes in a single cabview (I notice that the clock and speedometer displays are typically significantly different from the displays of brake line pressures, for instance.)
5. IMHO, it works quite well and looks good.

The disadvantage ?
1. Some .cvf files would have to be modified to get an acceptable display.
2. Some users are not comfortable editing simulator support files.

If this is seen as a serious problem, an additional option (!!!) to retain the current calculation of font size could be added for those who prefer not to modify any files; i.e "Calculate Cab View Digital Font Sizes YES/NO".

My suggested changes to the code to calculate the font size:
"FontScale" would no longer be a const in the CabViewDigitalRenderer class, but would be replaced by a float value within the method CabViewDigitalRenderer(...) so that it is calculated for each digital box. The value would be simply based on the value of 'Control.Height', with a minimum value to guarantee visibility, e.g.

float fScale = Math.Max(8f, (float)Control.Height;

The line:

DrawFont = Viewer.WindowManager.TextManager.Get("Courier New", Viewer.CabHeightPixels * FontScale, System.Drawing.FontStyle.Regular);

would then become:

DrawFont = Viewer.WindowManager.TextManager.Get("Courier New", fScale, System.Drawing.FontStyle.Regular);

(Note that this gets rid of a multiplication by 'Viewer.CabHeightPixels'.)
Edit: I used the raw value of Control.Height because that worked for the first couple of .cvf that I tried.

Cheers,
Sid.

[markus_GE]

Long story short, we were missing one keyword in the previous discussion: Option!

I think, it´s a good idea. My two cents, FWIW :sign_sorry:

Cheers, Markus

[James Ross]

markus_GE, on 14 May 2014 - 08:41 AM, said:

Long story short, we were missing one keyword in the previous discussion: Option!

That's a bad word.

As for the use of the height, I like how Sid quoted me saying it didn't work and still proposed it. One primary motivator for not using it was that it broke in-box content, which is a red flag for me in most cases. I'll need some good evidence that we can use the suggested code without breaking more than a tiny fraction of cabs (and I'll still be unhappy if we break in-box content).

[Csantucci]

I add two points:
First, thanks to this http://www.elvastowe...msts-behaviour/ one could generate an ORTS-specific cabview file without hurting MSTS operation.
Second, as explained in a document I wrote some time ago, additional parameters can be added within the cabview control blocks of the .cvf file, and MSTS won't consider them. As an example

Digital (
			Type ( SPEEDLIMIT DIGITAL )
			Position ( 290 287 24 12 )
			ScaleRange ( 0 120 )
			Accuracy ( 0 )
			AccuracySwitch ( 0 )
			LeadingZeros ( 0 )
			Justification ( 3 )
			PositiveColour ( 0
				ControlColour ( 128 255 128 )
			)
			NegativeColour ( 0 )
			DecreaseColour ( 0 )
			Units ( KM_PER_HOUR )
			ORTSFont ( 8 )
)

So this would not hurt MSTS operation and would also be a clean solution.

[Sid P.]

James Ross, on 14 May 2014 - 02:08 PM, said:

As for the use of the height, I like how Sid quoted me saying it didn't work and still proposed it. One primary motivator for not using it was that it broke in-box content, which is a red flag for me in most cases. I'll need some good evidence that we can use the suggested code without breaking more than a tiny fraction of cabs (and I'll still be unhappy if we break in-box content).

James- I understand your concerns about breaking "in-box" content. On further reflection, I think I got carried away proposing that users should or would start modifying the box parameters in their copies of .cvf files... I started thinking about the problems of ownership and license rules of the files, too.
I have looked at the code again, and I have modified my patch to just move the font size according to the control box size, with limits on the maximum and minimum font. I also restored the 'Viewer.CabHeightPixels' factor in the expression for 'DrawFont' in the CabViewDigitalRenderer() routine ( my goof!) after seeing where it came from.
I need to try the patch on a wider variety of cabs (with the .cvf files unmodified of course!) and will post some pictures.

Csantucci's suggestion is a potential solution, but now I wonder about modifying files that were issued with license restrictions.

Cheers,
Sid

[copperpen]

Nobody except Microsoft has the right to place licence restrictions on a trainsim cvf file, it is after all, only a text file like eng, wag, signal scripts etc., thus is easily modified by anyone.

[Sid P.]

copperpen, on 16 May 2014 - 01:23 AM, said:

Nobody except Microsoft has the right to place licence restrictions on a trainsim cvf file, it is after all, only a text file like eng, wag, signal scripts etc., thus is easily modified by anyone.

If I modify a .cvf or other file for my own use, I believe that I am free to do so, but I understand that I may not offer it to all without permission of the original creator. But there is benefit to the MSTS and ORTS community in sharing useful modifications via the file itself, so that everyone doesn't have to do the (sometimes tricky) modifications themselves.

I was thinking about some of the statements that I find in some contributed MSTS material on TrainSim.com and ElvasTower.com, such as Cabview sets, locomotive shape files, etc.. These files are really the heart of the user world of MSTS (and ORTS). In some cases, the authors simply request an acknowledgement of source. If the original files were part of payware, for example, modifying them and distributing them could be a problem.

Or am I being concerned unnecessarily?

Sid