[cr-stagg]

Using an Engine file from atsfsd39_1.zip I find these two Warnings in the UR Log:
Warning: Found a suffix 'ft+10in' which could not be parsed as a Distance unit in A:\WP3\trains\trainset\ATSF SD39\ATSF_SD39_4004.eng:line 7

Warning: Found a suffix 'ft+1in' which could not be parsed as a Distance unit in A:\WP3\trains\trainset\ATSF SD39\ATSF_SD39_4004.eng:line 7

Here are the first ten lines of the ENG file (I have added numbers for each line so you can see which is line 7):

1. SIMISA@@@@@@@@@@JINX0D0t______
2.
3. Wagon ( ATSF_SD39_4004
4. Comment (Locomotive Physics V4.5 by Bob Boudoin)
5. Type ( Engine )
6. WagonShape ( ATSF_SD39_4004.s )
7. Size ( 10ft 15ft+10in 65ft+1in )
8. Mass ( 176.4t )
9. WheelRadius ( 20in )
10. InertiaTensor ( Box (10ft 15ft+10in 65ft) )

The "Eng_and_wag_file_reference_guide.doc" that came on the MSTS CDs states that the dimensions for the Size line are to be expressed in meters. Also the "Manual for .eng- and .wag-files of the MS Train Simulator 1.0" version 20.e created by Rudolf Richter states that the dimensions are to be expressed in meters. But apparently the MSTS code was written to use both Metric and English measurements as MSTS has no problem with this engine.

So my first question is does OR expect the Size is to be expressed in Meters also? Or did OR just have trouble parsing the "ft+in" since there was no warning for the "10ft" value? If it is a parsing problem then I should point out that the default SD40 that came with the original MSTS CDs Size uses the same format "15ft+10in". Using the program Search and Replace I found that of the 3500+ engine files in my Trainset about 10% use English measurement for the Size parameter. Probably created by using the "default SD40 as a model"

My second question is why did OR not have problems parsing line #10, InertiaTensor, as it in in the same format?

[Csantucci]

cr-stagg, on 12 February 2015 - 07:26 AM, said:

My second question is why did OR not have problems parsing line #10, InertiaTensor, as it in in the same format?

I am able to answer this second question: because InertiaTensor is not considered at all by OR.

[copperpen]

MSTS has always had a tendency to ignore what it cannot understand and fall over if something is not there that should be there. It also accepts an eclectic mix of imperial and metric units in various places. Open Rails is not quite as forgiving and while it will accept both imperial and metric they have to be in a recognisable form, so 15.5ft should work whereas 15ft+6in will not. It is like trying to get 3.5meter to be accepted if written as 3m+50cm.

[cr-stagg]

copperpen, on 12 February 2015 - 01:44 PM, said:

MSTS has always had a tendency to ignore what it cannot understand and fall over if something is not there that should be there. It also accepts an eclectic mix of imperial and metric units in various places. Open Rails is not quite as forgiving and while it will accept both imperial and metric they have to be in a recognisable form, so 15.5ft should work whereas 15ft+6in will not. It is like trying to get 3.5meter to be accepted if written as 3m+50cm.

Well first let me ask: Did you write the code for reading and using the Size data from the ENG files? And if you did let me ask: "exactly how does OR use the Size data?" I have often wondered what MSTS actually did with that data because it seemed to me that the same information would be available in the Shape file.

As to your statement "MSTS has always had a tendency to ignore what it cannot understand", since ORTS displayed and ran this engine in the Open Rails sim it appears to me that ORTS also ignores what it cannot understand.

I agree with you that dimensions are easier for software to understand when written in the form of 15.5ft rather than in 15ft+10in, however the Open Rails team touts that ORTS can read and understand MSTS files. But, as I pointed out in the OP, one of the "original" MSTS engines uses this format. So whose Bug is it? The Engine file? Or ORTS? I will be happy with either. If the ENG file needs to be edited then we, the ConBuilder team, need to add a tool in ConBuilder to test for the use of phrases such as "ft+" and generate error reports so that the user can fix the engine files to work properly in ORTS. From what I see that will be about 10% of all US Diesel files that have been created.

[Genma Saotome]

copperpen, on 12 February 2015 - 01:44 PM, said:

Open Rails is not quite as forgiving and while it will accept both imperial and metric they have to be in a recognisable form, so 15.5ft should work whereas 15ft+6in will not.

TrackGauge() should be able to hold "56.5in" as it is pretty recognizable but last time I looked it isn't accepted as valid.

[cr-stagg]

Genma Saotome, on 12 February 2015 - 04:27 PM, said:

TrackGauge() should be able to hold "56.5in" as it is pretty recognizable but last time I looked it isn't accepted as valid.

Well ORTS does not issue a Warning on a Size line of Size ( 120in 190in 781in )

[gpz]

cr-stagg, on 12 February 2015 - 03:04 PM, said:

Well first let me ask: Did you write the code for reading and using the Size data from the ENG files? And if you did let me ask: "exactly how does OR use the Size data?" I have often wondered what MSTS actually did with that data because it seemed to me that the same information would be available in the Shape file.

By looking into the code, I see, that only height (2nd) and length (3rd) parameter is used currently of Size(). They default to 4 m and 40 m respectively, if the data cannot be understood. The shape is not measured. (Width will be necessary when we eventually try to calculate the Davis friction component ourselves.) Certainly it is an OR bug not being able to parse the ft+in format, but no developer likes to modify the STF parsing code, because a small modification may cause serious errors elsewhere. So for now the safest choice is not using ft+in format in .eng file, but using the distance expressed in either only just m, ft or in. In the future this bug might be fixed, when someone will be dare enough.

[cr-stagg]

gpz, on 12 February 2015 - 11:59 PM, said:

By looking into the code, I see, that only height (2nd) and length (3rd) parameter is used currently of Size(). They default to 4 m and 40 m respectively, if the data cannot be understood. The shape is not measured. (Width will be necessary when we eventually try to calculate the Davis friction component ourselves.) Certainly it is an OR bug not being able to parse the ft+in format, but no developer likes to modify the STF parsing code, because a small modification may cause serious errors elsewhere. So for now the safest choice is not using ft+in format in .eng file, but using the distance expressed in either only just m, ft or in. In the future this bug might be fixed, when someone will be dare enough.

OK thanks. That tell us how to proceed.