ORTS Engine file for OpenRails - Annotated

[Vince]

The best thing, honestly, would for someone to figure out what we need and what we don't and create a set of template OR-only .eng and .wag files with only what's necessary in them and the MSTS-only parameters removed. No include files, no extra directories, no libraries, no paths, just models and physics. KISS is a good rule to follow, I think. There just ain't any utility in cross-compatibility anymore.

Hi Eric,
How could you make that work across multiple eng / wag files? Like the old MSTS way?

regards,

[Erick_Cantu]

I don't quite follow what you're saying. Each individual locomotive or wagon should probably have its own physics; we've been doing it this way for a while and it's not that difficult. Bear in mind that, even within a single type, the different railroads are going to have different operating weights, gearing, light configurations, fuel capacities, and all kinds of things; things will even differ within even the same railroad, depending on the order. Rebuilds in particular will almost always be somewhat unique. If we come up with templates and a guide for estimating or finding parameters, then content developers can simply modify those to suit the piece of rolling stock that they're building. I get that with the include method, you could exploit the capability of dropping OR-parameters in dual-compatible equipment to use a library of some common parameters, but, in practice, I think it's just more complicated than it needs to be. My understanding of the intent behind this whole philosophy was cross-compatibility; well, there's no point in having cross-compatible physics if we're building models that MSTS can't load and using sound triggers that MSTS can't interpret. In that case, it just makes sense to have all-ORTS physics files stripped of unnecessary MSTS parameters. The last thing we want is to have a repeat of Trainz where every addon has a laundry list of required files.

To be fair, we first need to know what MSTS parameters we can prune, which might require trial-and-error, unless anyone on the software development team should know what ORTS needs and what it doesn't. I'm no physics expert, but I'd be more than happy to format the templates if I knew what the absolute requirements were. Just as I'd be more than happy to write guides for creating content if I knew the available parameters; for example, I don't have a list of all of the supported cabview controls, so I can't, with any confidence, write a guide for building a 3D cab. I've searched the internet to no avail, and the MSTS editors most definitely do not work on my system. Get me a list; I'll write a guide. I have the 3D cab process down now, so it wouldn't take long.

What we have in this post is a good start, though. The annotations will prove helpful.

[wwhall]

What would be helpful, as has been suggested, are templates of a complete OR .eng file--that doesn't have to rely on an MSTS .eng file for anything. Templates for some common locomotives would be helpful--then, as Erik suggests, the files could be "tweaked" to fit for a specific locomotive. There are some OR .eng examples being posted over at Elvas, but I don't think that they are completely independent of the MSTS .eng file, from what I can see. Figuring out what MSTS parameters could be shed from what goes into the OR .eng file would be nice to know. I agree that annotated examples would be really helpful. Another piece of helpful information would be a list of what an OR .eng file MUST have in order to fully function, and what it CAN have as optional features.

One of my few criticisms of the otherwise excellent documentation that the OR manual provides is that it often lacks full examples of syntax--an appendix of examples as part of the manual would be really helpful.

[baldwin]

I do not think that anybody has actually made an OR only eng file so far. If they have, there is no proof, nothing posted. The steam locomotive is not completely free of using old MSTS code for some parameters, but at least there you do have a file structure to follow which makes it very easy to make a new eng file from an existing one just by entering the appropriate data in each section. The ORTS Diesel engine block goes some way towards achieving the same and can be done as an include file instead of editing every eng file that uses the same data.

[bwbrgb]

Go to " Coals to Newcastle " - - look under PHYSICS . There are sample files and templates for steam or diesel - basic and advanced .

[Erick_Cantu]

Hm, yes, it does appear that the laundry lists at Coals to Newcastle could be used to create an .eng file that has only the absolutely necessary parameters for OR functioning. I'll have to try to build something off of it when I have time. Together with the annotated list of OR parameters, we could cook up a decent diesel template here.

[R. Steele]

Go for it people.
I have started testing to produce just such a file, others should test also, see if results are replicated among a few of us.
Here's my procedure.
Use the CTN Test Route, for this test mainly because it loads fast, no scenery or frills of any sort, except those needed to test features.
I'm starting with a wagon because it's simpler and contains many elements identical to the wagon section in an eng file.
I have a OpenRails subfolder containing a working include file.
I've been systemically removing lines from the MSTS default file, loading the wagon in OR and:
1. see if it is rendered correctly in the sim
2. if there are any warnings or errors in the OR log.

The problem I have with this method is that if the wagon is rendered correctly and OR does not show a warning or error, is this conclusive evidence that the specific line/parameter removed is not needed by OR?

So far if the size line is removed in the parent MSTS wag file, there will be large gaps in OR between couplers...so size line is required.
If the InertiaTensor line is removed, the wagon is rendered properly and no warnings or errors are seen in OR. Caveat --- this does not necessarily mean that nothing is happening, OR native physics may use the line and the problem might not be readily noticable, or generate a line in the log.

I'm assuming that anything needed by OR to render the model, if that item is not present in the MSTS default file, then there would be a warning or error in the OR log. Safe assumption, do you think?
Whoever posted that someone needs to be looking through the code, yep that would be very helpful.

[Erick_Cantu]

I'll try to write a GP7 ENG based on the laundry list at Coals to Newcastle in the near future. We'll see if our results are close (they should be). I'll make a note that InertiaTensor is required.

[R. Steele]

Erick, my meaning was unclear...
Size line is required
InertiaTensor line is NOT required.
Sorry for the confusion. This will be interesting, I have a working GP7 ORTS Engine Block if you would like to look at it.

[baldwin]

It might be of some use to look at an OR steam loco eng file as well to see how the file is structured. The wagon and brakes parts of the eng file are common to all so the steam eng file layout should work for diesel and electric as well.

[muskokaandtahoe]

I do not think that anybody has actually made an OR only eng file so far. If they have, there is no proof, nothing posted.

I've done lots of diesel locomotives, more freight cars, electric boxcabs, and a few steamers and passenger cars. What do you want to see?

p.s. I've converted at least 290 .wags and 250 .engs to full use of include files. All of the folders containing those files are sitting in a master library from which I use symbolic links to "distribute" virtual copies of almost all of those to multiple mini-route directories. A symbolic link is sort of a shortcut that programs will use so using them from a master library to various other places mean none will ever be out of sync from the others.

[baldwin]

What is needed is an eng file set up to use OR parameters without using include files. This sample eng file should be available somewhere for anyone to download and use as a template. There could also be an example made that uses the include files with said files as part of the download. The use of include files and the location of them is in my opinion up to the end user, not the provider of ready to run models.

[markyisri]

What is needed is an eng file set up to use OR parameters without using include files. This sample eng file should be available somewhere for anyone to download and use as a template. There could also be an example made that uses the include files with said files as part of the download. The use of include files and the location of them is in my opinion up to the end user, not the provider of ready to run models.

Agreed. That would be helpful.

[crstagg]

What is needed is an eng file set up to use OR parameters without using include files. This sample eng file should be available somewhere for anyone to download and use as a template. There could also be an example made that uses the include files with said files as part of the download. The use of include files and the location of them is in my opinion up to the end user, not the provider of ready to run models.

What is really needed is for the someone with knowledge of both the MSTS and ORTS ENG file parameters to update either the "MSTS Eng_and_wag_file_reference_guidev2.doc" or the "Manuel for .eng- and .wag-files of the MS Train Simulator.doc" by Rudolf Richter and Joe Realmuto and place this new document under the ORTS teams configuration management. This reference could then be used by those that want stand alone ENG files and those that want to use ENG files that reference Include files. If this is done, I would suggest that any MSTS parameter that is not used (required) by ORTS be retained and the font changed to "Strikethrough" and annotated "Not required for ORTS".

[conductorchris]

Well ultimately it's all up to the end user.

That being said, I think it would be immensely helpful to work out a common standard way of doing things.

I think if we leave it us to the end user, then mostly we (speaking as an end user) will just continue to use MSTS or however things come. If we work out together a series of best practices, then it will be easier for us to get the benefit from each others experience and we'll all be running better .eng and .wag files.

I really like the include file method. It makes things vastly simpler and I think besides simplifying new files, it will also simplify the process of upgrading from MSTS and then changing settings as our collective knowledge improves. This is because having a master list of open rails files means one change can then be reflected in the whole fleet that refers back to that file.

You know using common.cab and common.sound is also up to the end user and there are alternative schemes. But I value having stepped into a world that's been organized that way.

Christopher