ENG WAG File Highlighter

[pwillard]

As some of you may know, eons ago I took a stab at creating a ENG WAG file syntax highlighter using a editor called Context. Yuri of Steam4Me took my initial attempt and ran with it.

What I'm looking to do now is finally update the highlighter and use an editor that is still being maintained... like Notepad++.

My issue now is that I'm trying to come up with a definitive list of ENG WAG file directives that includes all of the latest ORTS entities as well. After a few hours of searching for the absolute list... I have concluded that I must be missing something.

Any help would be appreciated.

[baldwin]

I still use Context and the highlighter. Works well. ORTS is still evolving so the list of directives is not yet fixed, and as of now there is not a definitive list of all extant ones in any single place.

[R. Steele]

I still use Context and the highlighter. Works well. ORTS is still evolving so the list of directives is not yet fixed, and as of now there is not a definitive list of all extant ones in any single place.

I was just posting over at Elvas that we a need document like the data spread sheet of MSTS parameters in the Richter/Realmuto document for ORTS.

If it was in spead sheet form with the exact parameter name accepted in ORTS and the range of values needed for OR to achieve some sort of prototypical performance - I think people would use it. A lot of folks are pretty confused about what OR accepts and what is needed to mod the typical MSTS style wag and eng files.

Does not matter if it is a moving target - we should start compiling what we know now, have it reviewed by the OR devs for factual accuracy regarding the ORTS code. What do you think, Mervyn?

Pete, I think your idea is brilliant, however, I also still use ConText with the MSTS highlighter option, one for ORTS would be very welcome!

[muskokaandtahoe]

Could one of you guys post a screenshot of what the "highlighter" does?

WRT spreadsheets, I've been using them for years. IMO we should not have to be doing so. Consider the DavisA, B, and C parameters. Go go over to the fcalc set of spreadsheets, chose one, pick a tab for type of bearings, enter mass() and area, transcribe the resulting three values to your .wag file. Alternatively, insert Height(), Width(), and SubType() -- e.g., empty hopper, tofc, etc. and let OR do the rest. Your .wag already should have what type of bearing and the car mass. Tell me, which way is easier?

A similar story can be told for MaxBrakeForce() and Handbrake() force.

IMO we should not be using spreadsheets for run of the mill data values. Where they should come in (IMO) are things like power curves where it makes sense to see a graphical representation of the data before you sign off on it being what you want. All the rest? Let us put in the primitives and let OR do the rest.

[pwillard]

Dave,

I wanted to UPDATE my toolset for working with ENG and WAG files. I have struggled with trying to make context do what I really want. I noticed that some improved features were available in notepad++... namely the ability to reformat code. Say for example, I find engwag examples posted on a forum and have totally lost their nice indentations... notepad++, with some cajoling, can reformat AND highlight these files to aid in 1) finding issues 2) locate parenthesis issues 3) highlighting subsections and new ORTS items.

Both of the files below were reformatted to have sensible "indents" automatically using the "indent by fold" plugin.

So... PART 1:

Lets take the engine snippet FILE from here... http://www.elvastower.com/forums/ind...-and-wag-file/ and mess with it. No real highlighting yet.



It needs an indentation fix... notepad++ can do that.

[R. Steele]

Could one of you guys post a screenshot of what the "highlighter" does?

WRT spreadsheets, I've been using them for years. IMO we should not have to be doing so. Consider the DavisA, B, and C parameters. Go go over to the fcalc set of spreadsheets, chose one, pick a tab for type of bearings, enter mass() and area, transcribe the resulting three values to your .wag file. Alternatively, insert Height(), Width(), and SubType() -- e.g., empty hopper, tofc, etc. and let OR do the rest. Your .wag already should have what type of bearing and the car mass. Tell me, which way is easier?

A similar story can be told for MaxBrakeForce() and Handbrake() force.

IMO we should not be using spreadsheets for run of the mill data values. Where they should come in (IMO) are things like power curves where it makes sense to see a graphical representation of the data before you sign off on it being what you want. All the rest? Let us put in the primitives and let OR do the rest.

Dave, you are taking my suggestion which employed the term spread sheet way too literally and technically. I meant a much looser application - a data chart, sheet, or whatever term you are comfortable with that Open Rails users can consult when starting to convert MSTS files for better use in OR. A starting point for where to add parameters and data. Many people with much less experience than yourself are absolutely put off, afraid of changing files, confused about what to change or why. They really need a place to start.

Which way is easier you ask? Well the method you describe is certainly available to yourself and others that possess the technical knowledge to choose the correct options and have foreknowledge of what they want and how to go about it. Many simply do not possess those skills (regarding fcalc set of spreadsheets I one of them - would have to search to find out where to get them)
So consulting a chart that:
1. lists all the relevant eng and wag file sections that need to be changed
2. provides an accepted range of data to enter
3. shows the correct OR parameter eg. ORTSRigidWheelBase; enginebrakereleaserate, ORTSUnbalancedSuperElevation, MaxPower - to name only a few. Many are not listed in the manual and can only be found by a rigorous search through the forums...not something everyone can or wants to do.
4. indicates what OR will accept - for instance MaxPower OR will accept either HP or kN, not reduced as in MSTS.
and any other information -- this is only the starting point.

The whole point is to make the information easily accessible to the beginner or intermediate OR user. You do want more folks to try it?

I have tuned both engine, wagon and sound files (these mostly by removing errors ) and OR really does perform much better, the simulation is a much richer experience.

One last thought - eng, wag, and act files - etc. are just data for input into the sim. Most all I've seen have been worked over and commented quite a lot for MSTS, especially eng and wag files. Some of the data is flawed - sometimes deliberately in a skilled way to trick and work around MSTS less than stellar coding. OR is designed to use good data...so people should have access to that data - in as many forms as possible to widen the appeal to all who are interested in using the simulator.

Could one of you guys post a screenshot of what the "highlighter" does?...

bandicam 2016-12-02 12-41-52-627.jpg

[pwillard]

Wondering why I'm so interested all of a sudden? I just released rolling stock with mismatched braces.

[R. Steele]

Nooooo! LOL - you're certainly not the first to do that.

[muskokaandtahoe]

It looks like the highlighting is mostly about indent levels... some (but not all numbers). That about it?

The editor I use is EmEditor Pro. I acquired a lifetime license when it was inexpensive to do so. I really like it. I'm always curious about ideas on how to make our software tools more useful and I wasn't at all sure what you meant by highlighting.

I don't create many (any??) .wags or .engs from scratch but I do mess around with them quite a bit. Of late I've been converting lots of them to use the Include() statement. The most common errors I've made are with comments, usually failing to include the closing parenthesis. Shot myself in the foot many times with that one.

@Gerry, WRT your comment about folks hesitating to edit their .wags and .engs... I can understand that. For lots of guys it's either too hard to understand what to do or you don't know what alternative values make sense. And even if you know something about one area you can still be dirt ignorant about another. I wouldn't touch power curves even if you paid me. The examples I gave you are, IMO, ones where the OR team is asking people to grapple with the more complex way of doing things, largely (IMO) because it's far easier to code than would be the case by doing the more straightforward-for-the-user way. Guys who wouldn't go near fcalc with a 10 foot pole do understand what Height() and Width() mean.

[pwillard]

What I like is the code block folding ability. Not perfect yet though (note that coupling section is minimized)