Numbers, Expressions...

[NeutronIC]

In writing my program for handling the ENG/WAG files, I've found lots of expressions in place of numbers - e.g. for a wheel radius, the diameter is specified and divided by two for the radius. There are some much more complex examples, and I was curious to find out what Train Sim is doing with them - does it really handle them? Or are these values not actually doing what is expected? The implication for me was that if it was really handling them, i'd need to handle them as well - since my application deals in real numbers not in strings, I need to be able to compare things and see if values are inside other values and so forth, so all expressions would need to be evaluated, and preferably in the same manner as MSTS itself of course.

My results are largely what I was expecting, but this doesn't necessarily bode well.

Without further ado, here are the results of some tests using the Wheel Radius field since this is very easily visible in terms of its effect, I am assuming that MSTS only has one expression evaluator (which seems logical):

170cm/2 - YES
170/2cm - NO
(170/2)cm - NO
45.2cm*2 - YES
(45.2cm)*2 - NO
45.2cm*(4/2) - bizarre! no! (no steam on no regulator, wheels locked, reverse direction)
425cm/5 - YES
340cm/2/2 - YES
200cm-115cm - YES
300cm-1m-115cm - YES
300cm-(2m-115cm) - bizarre! no! (no steam on no regulator, wheels locked, reverse direction)
300cm-2m-115cm - Evaluates to number that makes wheels go in reverse, as expected.
300cm-2m#-115cm - Evaluates to 1m, wheels about right, cease parsing at the #
85(cm) - treated as meters, inside brackets ignored
300cm- - same as 300cm-(2m-115cm) - brackets must be ignored
300cm(123)-215cm - same as 300cm
300cmX - same as '300' (i.e. treated as meters)
-42.5cm+85cm - same as 42.5cm
170cm/2m - Correct rotation
9.2cm^2 - Treated as 9.2cm

If you do not specify any units, the default is assumed, in the case of Wheel Radius this is meters.

Understood Symbols - +, -, *, /

It seems that:

Grab all up to the first invalid or terminating character
- valid: Letter, Number, *-/+
- terminating: whitespace
- brackets are not valid and terminate processing of the string, as does a hash, power etc.

Tokens marked by numbers followed by possibly units up to an operator

Read in value, parse according to units, if units are unknown then handle as default for that type.

Expressions evaluated left to right in order, no precedence.

Divide and Multiply are done irrespective of units (e.g. 1cm/1m and 1cm/1cm are the same)


Look through a few eng and wag files - the implications of this are large, there are lots of more complex expressions being used by people, particularly when it comes to steam physics, and if the above holds true for them then this means that they aren't working at all!

E.g. one boiler volume i saw recently was "8.09*(ft^3)" - which, if I'm right, is seen just as '8.09*' which is not valid and therefore the results are unpredictable.

Thoughts?

Matt.

[DarwinS]

Very interesting. Another job to do, checking through how many .eng files....

[NeutronIC]

Once my utility is done, checking through eng files will be a thing of the past (better late than never?) - it's currently fully parsing every aspect of eng, wag, sd and con files in to an object model reporting errors such as this. Next is to add in some automatic fixing, i'll also make it resolve all the expressions to numbers (no point making msts work harder than it needs to!) and then provide an easy way to bulk-fix things before saving it all out again, fixed

Matt.

[tinsley]

Fascinating...and frightening
Not surprising that so many eng are wrong then...
How would 'square' and 'cube' be entered then so that it is 'read' right..????
Your little gem is going to make life so much sweeter for all of us..
maybe it should be called Eng Riter... it will be as invaluable to me as the great Route Riter..
Thanks in advance... need a tester??? I am just doing a total MSTS re-install and intend to 'correct' ALL eng and wag as I go..
Who said I need a life ??:evil:
Regards,

[BruceB]

Looks like another "tool which revolutionises MSTS" - up there with TSTools, ShapeViewer, Route Ritter and Train Store.

Looking forward to it.

Bruce

[NeutronIC]

Still a long way to even beta, don't get too excited just yet

Spent a fair bit of the Sunderland Exhibition tucked away at the back bashing the keyboard and adding facilities for the majority of ENG files to be loaded - between steam, diesel and electric plus all the variations in power and braking, that's an awful lot of variables - and i'm not done yet, some of the more complicated structures like lighting and engine controllers have yet to be imported

Matt.

[tinsley]

We have total faith in you...
Please forgive our 'enthusiastic impatience'

[timbooth]

With boiler volume, the default unit is cubed feet - so they probably just added (ft^3) to clarify the unit. It might be worth testing if ft^3,m^3 can be used in parameters - eg. 8.09ft^3

I think its better to use raw numbers, rather than doing multiplications/divisions - just to make sure the right value is determined.

[NeutronIC]

One thing I haven't tried is to use the wrong unit type - e.g. to say "85psi" when you mean "85cm"

Matt.

[jbilton]

I think its better to use raw numbers, rather than doing multiplications/divisions - just to make sure the right value is determined.

Hi
I certainly do this whenever I find a wheel diameter expressed as such.
Seems to make wheelslip better (and certainly stops SFM getting confused...if resizing)
Although interesting to read that msts sees this as metres...as I always write this as inches (in).
Cheers
Jon

[NeutronIC]

If you put in the units, it works fine, i.e. I tried 2ft, 85cm and 0.85m and all worked (obviously the 2ft wasn't quite right ), if you put in 0.85 it treats it as meters though.

Matt.

[supergoods]

This looks a very interesting concept, I have been over involved in the offshore cleanup of the wreckage after Hurricane Katrina so have not had much time to devote to the simulator.

I agree that the sim works best when used with default units, unfortunately it does appear that some of the original work was metric and some was imperial.

An example of a paramater for a steam locomotive:

BoilerVolume ( "160*(ft^3)" )

when expressed as:

BoilerVolume ( 160 )

Gives a different, but better result.

The biggest problem is the interelationship between groups of parameters where a change in one parameter will effect other lines elsewhere which use it.

Another issue is the inclusion in generic files of features which did not exist in the prototype.

Working through the air brake physics for steam, took a long time, but eventually got a better brake, and so it goes on.

More later if I ever get more free time:

Presently 25 hour days reult in a parameter which doesn't work any more.

[CaptainBazza]

"8.09*(ft^3)"

(ft^3) = cubic foot? Anyway, the correct boiler figure (however interpreted by the physics) would be the total cubic capacity of the vessel, minus the cubic capacity of the tubes and flues, including superheating flues, minus the cubic space occupied by the firebox. This is not a figure you can get down to the last cubic inch and a fudged 'ball-park' total would be acceptable.

[NeutronIC]

The issue is more that once parsed, what's left is "8.09*" and as is shown by the wheel radius experiment, the remaining fluff on the end of the line *does* change the interpretation, often in very screwed up ways (e.g. in the case of wheel radius, it totally changed the direction of the whole loco, not just the wheels).

Matt.

[1crick14a]

CaptainBazza

I found that if the info is available to use the engine weight empty
against the engine in working order for boiler volume in fact the
hardest one to obtain is level of water in the glass.

Regards, Rick