[captain_bazza]

We need to be careful using the term 'developer' which can be construed as ' OR code developer' or 'OR model developer'.

We know what the OR code developer does, but to clarify - the OR model developer may - do the relevant research to setup the physics input data, build the 3d model, do the conversion, and do the artwork and conversion, associated with the model. (It may be done in a different order, depending how individual modelers conduct a modeling project.)

Personally, I do my research and try and find relevant data pertaining to the locomotive class and type, but where data is missing I use extrepolated data that achieves a satisfactory result, ie, running and load characteristics. Thus any engineering script should have a good layout to which known, or extrepolated, data is entered. The preference, I am sure, is a similar plain language type script such as that used for the MSTS ENG file. Text is entered using a unicode text editor, which are easily available, ie, ConTXT Editor.

There should be a single numeric system, ie, imperial, or, metric formats. Conversion utilities are readily available, including from the ET library, so there is no real problem converting from imperial to metric formats. OR code developers might find metric data input is easier to work with?

Cheers Bazza

[copperpen]

I would like to bring a bit of information with regard to OR eng file parameters in an MSTS eng file. Last night I stated that my steam test engine worked in MSTS including OR parameters in the file, but a set of diesels did not. Today I spent some time investigating the problem.

It is now quite clear to me that MSTS will in fact ignore anything it is not set up to read in an eng file so long as that OR data line follows the same convention as MSTS, Parameter ( data ). The problem with the diesels was caused by a parameter having no associated data. As soon as I commented the offending lines out, all the rest were accepted by MSTS with no error messages.

Therefore as I see it, OR can extend the MSTS eng file without upsetting MSTS as long as the rule Parameter ( data ) is observed. I would however recommend that each such new addition to an eng file is tested in MSTS before being committed.

[James Ross]

copperpen, on 15 October 2013 - 05:14 AM, said:

It is now quite clear to me that MSTS will in fact ignore anything it is not set up to read in an eng file so long as that OR data line follows the same convention as MSTS, Parameter ( data ). The problem with the diesels was caused by a parameter having no associated data. As soon as I commented the offending lines out, all the rest were accepted by MSTS with no error messages.

Fascinating! We'll probably want to understand this in as much detail as possible (e.g. does "Parameter ( data1 data2 data3 )" work?) but thanks a lot for figuring this out!

[copperpen]

James Ross, on 15 October 2013 - 05:18 AM, said:

Fascinating! We'll probably want to understand this in as much detail as possible (e.g. does "Parameter ( data1 data2 data3 )" work?) but thanks a lot for figuring this out!

MSTS already accepts lines like that. Take the following for example, a standard MSTS eng file entry

comment( min steam pressure, min water proportion, max water proportion )
InjectorLimits1 ( 50psi 0.4 1 )
InjectorLimits2 ( 60psi 0.4 1 )

[James Ross]

copperpen, on 15 October 2013 - 07:31 AM, said:

MSTS already accepts lines like that. Take the following for example, a standard MSTS eng file entry

comment( min steam pressure, min water proportion, max water proportion )
InjectorLimits1 ( 50psi 0.4 1 )
InjectorLimits2 ( 60psi 0.4 1 )

But are those unknown parameters to MSTS? It's entirely possible for MSTS to accept "UnknownParameter ( data )" but blow a gasket on "UnknownParameter ( data1 data2 data3 )". If it doesn't, great, but I'd like everything known and tested. :)

[copperpen]

James Ross, on 15 October 2013 - 07:42 AM, said:

But are those unknown parameters to MSTS? It's entirely possible for MSTS to accept "UnknownParameter ( data )" but blow a gasket on "UnknownParameter ( data1 data2 data3 )". If it doesn't, great, but I'd like everything known and tested. :)

The example shown is working MSTS code. I do not think that MSTS will toss the toys out of the pram as long as the additional parameters are set out in a way familiar to the MSTS code engine. What it does not recognize or cannot use will simply be discarded. It is merely the syntax that has to match. I agree with the testing bit anyway. That is my role with the steam code, along with research.

[Lindsayts]

From my experience from mucking around with the eng files on MSTS the parser will ignore lines it knows nothing about. It does not keep track of data it has already read and if such multiple parameters exist the value of the last one in the file will be used. Its very picky on the syntax though MSTS apparently not keeping complete track of sets of brackets and an error appears only to show when the total number of brackets is not even, the line number given in the error being usually no where near where the real error is.

The compatibilty issue may in the end not be a serious problem, my impression from looking around the net for MSTS info most people are now using OR except for the editor and tools. Even then at least three people developing routes are now doing so that they will only run on OR. Even OR's relatively recent abilty to see longer distances being catered for.

Lindsay

[Lindsayts]

Tried out a steamer using V1819, loco used was VR H220. This was used as its one of the few steam locos whose performance is published.

The calculated heating surface was high by around 25%, slightly over 5000 square ft, where as the heating surface appears to be around the 3900 sq ft marker, I say appears as different sources give differing values, 3900 would be correct for this loco.

Calculated grate area was 102 sq ft, this is way to high the actual grate area being 68sq ft.

Power output was around what the real loco generated (3600bhp at the wheel rims), very good.

Water consumption was between 13 and 15 lbs/bhp/hour which is in the correct area.

Only two complaints, the steam generation NEVER decreased, even when one stopped the machine.The second point from information published in Chapelons book the chest pressure indicated in the hud is to high by a good bit. Chapelon states that almost all locos lost around at least 25 to 33% of the boiler pressure in the steam piping at full steam flow.

Lindsay

[Coonskin]

Quote

The compatibilty issue may in the end not be a serious problem, my impression from looking around the net for MSTS info most people are now using OR except for the editor and tools.

I believe your impression is symbolic of the forum niches you frequent. I suspect you would find that a survey of the general MSTS populace will indicate this to not be the case by a long stretch.

[gpz]

As I understand steam locomotives, you can adjust the cutoff by the reverser. As the speed increases, you can slowly start closing it.