[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: 170

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