[cr-stagg]

For programs like ConBuilder to have testing tools to insure that files referenced by parameters are present where they are expected to be requires searching for parameter names. If the program has to search for both "Include" and "include" it obviously takes longer than just searching for "Include". Yes it only takes x nanoseconds, but doing it twice takes 2 x nanoseconds. As mentioned before if one looks at current ENG file ALL the parameters begin with a capital letter.

[ATW]

Since this appears like a serious issue with the newer Conbuilder I will change to capital Include. Do you need it immediately instead of changing on your end with the engines you link the files with?

[cr-stagg]

No. I just wanted to bring it to your attention so that you would follow the established convention. Like that shape file with the extra "/" that got copied umpteen jillion times. Would have been so much better if the creator had corrected his mistake in the beginning.

Also the question about 1 or 2 slashes. See this post by James Ross http://www.elvastowe...post__p__182993

[Jovet]

cr-stagg, on 29 April 2016 - 11:23 AM, said:

Also the question about 1 or 2 slashes. See this post by James Ross http://www.elvastowe...post__p__182993

• The backslash ( \ ) is the correct path separation character for Microsoft Windows. This is a holdover from MS-DOS.
• In "C" programming languages (e.g. C, C++, C#), the backslash is a special character in text string data. The backslash signals the start of an escape, which in these computer terms means a special embedded code to represent non-printable or non-textual data. The curious can read more about this here. What this means, though, is that a single backslash in a text string is invalid and makes no sense, sort of like dividing by zero. To actually have a backslash, its escape sequence must be used, which is two: \\
• Escaped or continued (across multiple physical lines—this is common in .trk files) MSTS strings should always be double-quoted.
• Adding to point #1, the forward slash ( / ) may be sometimes accepted as a substitute for a backslash in Windows paths, but this is not official nor universal, and should not be relied upon. The forward slash is the standard path separation character for Unix operating systems, which is why you see them in URLs like http://google.com. So, do not confuse the two contexts.
• Forward slashes often seem to work in MSTS configuration files, and they also do not technically need enclosed in double-quotes, but it is still the wrong way to go about it.

[disc]

cr-stagg, on 29 April 2016 - 09:45 AM, said:

I have another question. Why are these lines written this way:

ORTS (
ORTSEmergencyCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyEngagesHorn( 0 )
)
ORTS (
ORTSWheelSlipCausesThrottleDown( 1 )
)
ORTS (
ORTSEmergencyCausesPowerDown( 1 )
)

If OR reads these like that, then it's probably a bug. Anyway i don't know what's the point of that ORTS () section. The parameter name itself tells that it's for ORTS, and the most of the other ORTS specific params don't need to be in ORTS ().

[James Ross]

ATW, on 29 April 2016 - 10:01 AM, said:

The way they are included is how ORTS positively reads them where the other organized way ORTS does not read. This is a good topic to look into.

disc, on 30 April 2016 - 01:53 AM, said:

If OR reads these like that, then it's probably a bug. Anyway i don't know what's the point of that ORTS () section. The parameter name itself tells that it's for ORTS, and the most of the other ORTS specific params don't need to be in ORTS ().

I can see no evidence in the code that these items need to be in their own "ORTS" blocks; they will work identically inside a single "ORTS" block. (And yes, the block is probably unnecessary but I am not sure we can change them now as they've existed for some time.)

[cr-stagg]

I asked a question in post #17 that no one has addressed. So I will rephrase the question: Where is the ORTS equivalent of the MSTS document "Eng_and_wag_file_reference_guide"?

Lines like ORTSEmergencyCausesThrottleDown( 1 ) are understandable, values are either 1 or 0, but ORTSEngineBrakeReleaseRate ( 38 ) is not. 38 what? pounds per minute, or tons per second or liters per hour?

[ATW]

It's the BC release an application rates as if you open an close the independent brake by mouse or raildriver.

[cr-stagg]

ATW, on 30 April 2016 - 08:06 AM, said:

It's the BC release an application rates as if you open an close the independent brake by mouse or raildriver.

That is NOT my question. I can tell that by the name. What does 38 mean? 38 WHAT? pounds per minute, or tons per second or liters per hour?

BUT my real question is where is the document that defines this example and ALL the other ORTS parameters for ENG and WAG files?

[ATW]

Think I should start putting comment tips of what some parameters are in my next release.

[cr-stagg]

ATW, on 30 April 2016 - 08:22 AM, said:

Think I should start putting comment tips of what some parameters are in my next release.

Are you writing ORTS code that uses these Parameters and creating ENG files or just creating ENG files?

Comments would not be necessary if there was an ORTS Eng_and_wag_file_reference_guide document.

[copperpen]

As OR physics is an evolving thing, a reference manual is probably not practical right now. Comments where appropriate should be sufficient until things are finalised.

The code that uses these parameters has already been written, but not a lot of guidance supplied in applying parameters to use the code.

[cr-stagg]

copperpen, on 30 April 2016 - 11:00 AM, said:

As OR physics is an evolving thing, a reference manual is probably not practical right now. Comments where appropriate should be sufficient until things are finalised.

The code that uses these parameters has already been written, but not a lot of guidance supplied in applying parameters to use the code.

Understand that it is evolving, but how about an evolving reference, like a web page that is a table of Parameters, unit of measurement, max & min value. As it is now we see all these usages of ORTS parameters that ATW is posting that have NO unit of measurement shown:
ORTSEngineBrakeReleaseRate ( 38 )
ORTSEngineBrakeApplicationRate ( 34 )
ORTSAirBrakesMainresvolume ( 0.43 )
ORTSMainResChargingRate ( 3.1 )
ORTSBrakePipeChargingRate ( 199.0 )

[copperpen]

Far as I am aware those particular parameters are not used, at least I can find no reference to them in the code. A table of used parameters with units/max/min would indeed be a useful document, and if web based would probably be best located at the OR web site.

[ATW]

I am not a code writer but a user an tester of those parameters which I saw in a manual that didn't even give enough info but decided to test them an saw changes. No one was interested some posts back so I just experimented on my own.

My comments will be a reference but unit's of measure wasn't included in the Manuel. I have been in cabs an cab rides on unit's an using some of these parameters show just the things I have seen on the screen in variety of ways such as brake performance. Think of the parameters as optional with variety as not all unit's of the same prototype always perform the same like smoke an color for example.

So my thing if no one understands them an I don't give my experience reference an view then it won't be as simple for one on their end like me an my fish an experiment.

The engine release an application with 38 an 34 is same as the MSTS parameter that worked in ORTS when I used a raildriver.

My last wish to calculate an experiment these not enough info but research is have a Air Brake Flow meter in HUD at least.

With the files included an testing in a duplicated consists but different engines I would like one to tell me the difference they see in BP performance applying/release.... SD70MAC vs C44-9W.... or is that a big deal finding an messing around to experiment an find out before I give my reference again like I did in some posts before? Just delete out on your end if you don't like as one asked for all the known parameters to be put as a template.