[Lindsayts]

Over the past couple of weeks a number of people (Dave Nelson is one) has asked for a way to simplify the use of WAG files by separating out common items. Below is a method that should be relatively easy to do that is a "cure all" solution.

The solution proposed is to allow OR to use general purpose "include" files within both ENG and WAG files (also most likely it would be a help in any other text file OR uses".
The operation of this to be this way.....
Parsing a loaded file occurs in two stages. The first just reads the file looking for the "include" directive if one is encounted it reads the file into the buffer adding it at the point of the "include" directive. So the buffer just becomes one long buufer as if all were included items were in the one file originally.

This way in an ENG file for instance one could have an engine, brake, lighting and coupling include files this would leave the individual engines ENG file small and easy to manage while having the abitilty to change the parameters for the entire fleet. Of course if one needs to "individualise" one of the items the parsing program uses the apropriate line from the indivdual items eng file.

Note: OR does use the "include" directive for eng files, its currently not general purpose though, being specific to individual parameters.

Lindsay

[James Ross]

Lindsayts, on 01 May 2014 - 03:53 PM, said:

Note: OR does use the "include" directive for eng files, its currently not general purpose though, being specific to individual parameters.

As far as I know, it's very general. You can use it anywhere that's syntactically valid for a block to appear and it is replaced by the contents of the other file. I believe it works on any STF-parsed file. What makes you think it is not general purpose?

[Lindsayts]

James Ross, on 02 May 2014 - 12:08 AM, said:

As far as I know, it's very general. You can use it anywhere that's syntactically valid for a block to appear and it is replaced by the contents of the other file. I believe it works on any STF-parsed file. What makes you think it is not general purpose?

I have tried to use it using the files below

It certainly was specfic, I checked the source and there was at the time particular conditions which had to be satisfied for the include statement to work. I believe it would not be to difficult to convert the routine to be general.

Note, Its been some time since I have tried it. It would REALLY be great if it worked.

Below is the eng and include files I used for a test
The model it is for being from.....

http://msts.steam4me...esel/cr_rdc.htm

 new_eng_layout-RDC.zip (7K)
Number of downloads: 217

The files are.......

AU_anRDC_CB2.eng
Brake_Westinghouse_single_pipe.inc
RDC_Adhesion_derail_friction.inc
RDC_Dimensions.inc
RDC_Effects.inc
RDC_Lighting.inc
RDC_coupling.inc
RDC_motive.inc

This is only a test version and would need fine tuning. The main file is of course "AU_anRDC_CB2.eng" and its only 2630 bytes in size. The two largest files being the Effects and Motive both around 10 k. For each individual vehicle one only needs its own 2.6 k eng file.

Lindsay

[Lindsayts]

A late comment.............

Files like "Brake_Westinghouse_single_pipe.inc" would be renamed to something like "Brake_Westinghouse_50psi_single_pipe.inc" and would be common to all vehicles one had that used a 50psi brake pipe pressure on a single pipe. Changing only a single file would change the performance of ones entire fleet.

Lindsay

[Lindsayts]

The current problem with the "include" directive is probably due to that it only works in root "blocks". I ASSUME that in this case it means an ENG file is made up of two root blocks a "Wagon" Block and an "Engine" block.
In the source file "STFREader.cs" (line 93)
"include - must be at the root level (that is to say it cannot be included within a block)."

It appears the include break up I am using is NOT at the root level. This in effect means the STF "include" is not a true general purpose include directive and therefore will not work for THIS purpose (which in fact it does not).

Now the "include" directive does work at the root level but this is not a help for the purpose of breaking up and simplifing an ENG or Wagon file.

Sssssssssiiiiiiiiiggggggggghhhhhhhh ;),

Lindsay

[Lindsayts]

I wonder if one of the developers would consider getting a general purpose include to work as described in my previous posts in this thread. I do not believe it will be anything like as complex as fixing up the power physics weakness currently in OR.

Being able to split up the eng and wag files this way would make playing around with these files WWWWWWWWWWAAAAAAAAAAYYYYYYYYYYYY WWWWWWWWWWAAAAAAAAAAAYYYYYYYY easier. This would be I consider a REAL MAJOR improvement in OR. Playing around with the eng files is currently a real pain, particularly in a route like the SOB, with literally hundreds of separate items of rolling stock.

I am currently considering a mass correction of eng and wag files in the SOB, being able to split the files up would very greatly simplify this task. I would of course reditribute such corrected files for others to use. Although even being able to split up the files it will still be a serious task.

Lindsay

[James Ross]

It's on my list of things to investigate.

[Lindsayts]

James Ross, on 18 May 2014 - 03:18 AM, said:

It's on my list of things to investigate.

Many thanks James.

I had a bit of a look at STFReader.cs to see if I could do anything but I find C# to be a mystery wrapped in an enigma. I have done plenty of program in assembly language (on motorla M68K series of CPU's) and in standard C in the linux kernel, mostly on the Frame Buffer driver (one of programmings tougher challenges) and I find the namimg scheme for functions and Data in C# to make no sense at all.

I managed to mostly figure out MSTSSteamLocomotive.cs by recognising the formula's used and a good knowledge of how a steamer works.

The STF code is a differnt story, in Linux (unix) the parsing of a file is trivial as the main C library has a good number of functions specfic for parsing files, this makes the whole process quite simple. Apparently no such routines exists in Windows and one must build them from scratch.

My idea was to include a simple function that when an "include" directive is encounted the routine simply reads in the new file at that point without doing anything else, then passing it on to the main parsing routine. This would replace the current include code as it would do the same thing at a lower level. The code in STFreader.cs appears to always work at the block level though. There must be somewhere though that just reads the file into a buffer.

Keep up the excellent work OR is comming on VERY nicely, although one does get the odd strange behaviour specially in the SOB route.

Lindsay

[James Ross]

Lindsayts, on 18 May 2014 - 07:06 PM, said:

I had a bit of a look at STFReader.cs to see if I could do anything but I find C# to be a mystery wrapped in an enigma. I have done plenty of program in assembly language (on motorla M68K series of CPU's) and in standard C in the linux kernel, mostly on the Frame Buffer driver (one of programmings tougher challenges) and I find the namimg scheme for functions and Data in C# to make no sense at all.

The STF code is a differnt story, in Linux (unix) the parsing of a file is trivial as the main C library has a good number of functions specfic for parsing files, this makes the whole process quite simple. Apparently no such routines exists in Windows and one must build them from scratch.

The STFReader code is written in (IMHO) a very odd way and is probably the single most obscure code in OR at present. It also goes to great lengths to avoid standard ways of parsing text. This was for some noble reasons but I don't think it worked out well; I'd love to rewrite it or at least try and tidy it up but it's so crucial to everything working and we don't yet have much test coverage. I wouldn't level any of the issues at C# though, but instead at that code in particular. :oldstry:

Lindsayts, on 18 May 2014 - 07:06 PM, said:

My idea was to include a simple function that when an "include" directive is encounted the routine simply reads in the new file at that point without doing anything else, then passing it on to the main parsing routine. This would replace the current include code as it would do the same thing at a lower level. The code in STFreader.cs appears to always work at the block level though. There must be somewhere though that just reads the file into a buffer.

The existing Include() function worked by creating a "secret" parser for the included file and forwarding reads to it, until it ran out of include. Given the ways files are parsed and used this is a good design - it means any parse errors will be attributed to the correct file and line. However, there were no comments on why it was restricted to top-level includes only, so I have simply removed that restriction in X2261.

To get your engine example to work, I had to make one tiny tweak to the included files: because the included files are parsed as separate STF files the first line of the .inc files is ignored. I simply added this to each:

# Dummy line where the SIMIS header would normally go.

But you're free to use whatever you like on this line - it is completely skipped.

With that change, the engine loads in X2261. Let me know if you discover any more issues.

[Lindsayts]

Many Many thanks for this.
I am not really criticising C# or in fact any languages using objects. Like most people my prefences on most things are based on what I first used. In the case of programming languages this was Motorola M68k Assembly language, The straight C language being what one may call standardised assembly language.

I have never found assembly language difficult, the knowledge arena for it is MUCH smaller than for ANY high or midlevel language. In assembler if somethings wrong with the program its definitely the programmers fault. I would not do a train sim in it but for machine control and robotics its a dream.

The most important part in progamming (in my opinion anyway) is not the selection of the language but it is understanding the language you are using and the problem one is trying to solve VERY well.

Lindsay

[Lindsayts]

First tests shows it works OK, Including files from another directory works OK, Many thanks again.

THe idea behind this is to be able to vastly simplify working with eng and wag files. My proposal breaks these files down into 3 sections. The first is a small file individual to each SEPARATE item of rolling stock, the second set are files will be common to one CLASS of rolling stock (engine system, lighting and effects, controls etc. The third set of items that are common through the whole fleet (braking system).
This means you will be able to change a particular parameter say brake pressure for the whole fleet or say engine power for a whole class by changing only a single file.

Another goal was to make it so if one say wished to modify the lighting you had little fear one would break the engine/braking or what ever.

The above would make it dead simple to have as many individual items of one class.
.
I will do more testing and put up some more info and may be get some ideas on how the files are best to be broken up.

Any comments or questions welcome!

Lindsay

[Buttercup]

You might want to further separate out visual parameters (lights, smoke, etc.) that depend on the shape file used.

[Lindsayts]

Buttercup, on 27 May 2014 - 05:08 AM, said:

You might want to further separate out visual parameters (lights, smoke, etc.) that depend on the shape file used.

I have done so, the files concerned being "Whatever_Effects.inc" and Whatever_Lights.inc", you actually HAVE to split these two as they reside in different parts of the eng file. The Lights being in the wagon section, Effects in the engine section. The idea from the beginning was to make the eng files far easier for all to work on by separating out all the different items into there own box. James mods are working VERY well its a bit disconcerting when first draft programming mods work OK, we all have wins though occasionaly.

Something I am also constructing is a separate include directory containing common through out the fleet items, such as the brake system and brake controls and throttle controls.

Lindsay

[Lindsayts]

Can the developers or other interested parties come up with a loco I can convert to my system so others can try it. I have successfully done a couple of my favorites, one of these having 15 members in the class. Once the first is done the rest are a "piece of cake".

Loco MUST be freely down loadable.

I will do a couple more of mine and try and get a full set, A DMU, A DE and a steamer, then write some docs.
I am very pleased so far on my progress, system works well so far.

Lindsay

[Lindsayts]

The story so far..............

After much thought I have broken the eng file up into the following....

xxxx.eng
Main eng file, its only just over 1000 bytes in size, it contains, the base eng file format, rolling stock ID and the include statements.

xxxx_Wagon.inc
locos Dimensions, Adhesion, friction, buffers and coupling.

xxxx_Effects.inc
effects statements from the engine section.

xxxx_Lighting.inc
All the lighting for the machine.

xxxx_Motive.inc
engine power, fuel and water capacity, aircompressor power etc.

xxxx_EngineControlers_misc.inc
misc control items such as wipers, sanding, Dircontrol, AWS etc

The above are all describing the class of the item of rolling stock and the files would reside with the shape files and cabview etc.


Brake_Westinghouse_twin_pipe.inc
The brakeparameters from the Wagon section of the eng file.

Brake_Westinghouse_engine.inc
All the pressures from the engine section of the eng file.

Brake_controler_Westinghouse_Graduated.inc
THe loco's brake controler.

EMD_noncpu_8_notch_throttle.inc
The standard Deisel electric 8 notch throttle.

This list is not complete single pipe brakes will be needed as will EP brakes and different throtlles (at least).

THe above reside in an include directory under TRAINS\TRAINSET\ and can be accessed by any other rolling stock that uses these systems/controls.
Each of these include files has its formating complete unto itself, ie the nested braces all match.
This breakup should allow some decent documentation on the individual files to be easier to produce and seriously simplify the creation of an eng file set for new rolling stock.

Lindsay