[lucstef]

Hello everyone.

I am having the need to adjust a lot of .wag and .eng files that have been heavily tweaked to give a somewhat real feel for the trains in MSTS, but have some issues with the advanced model in Openrails:
- a single SW1500 doesn't stop from 10MPH in less than 2-300 yards at full brake application (I've seen real heavier mainline locos stop in less than three car lenghts from the same speed)
- lots of wagons have their brake systems not recognized in OR at all, sometimes just the reservoir, therefore they have no braking capability

I'm talking about several hundreds of files to correct.
So I built some .inc files and started populating the trainsets with openrails folders; in those .inc files I have just brake parameters, with increased application and release rates and fixed braking forces (200KN for the locos, 70KN for the wagons).

All is working as intended, but then something came to me: why do we need to name a file the same as the .eng original file, and then have to set an include statement referencing that same original .eng file.....
1) original file SD40-UPS4589.ENG
2) in Openrails folder, another file named SD40-UPS4589.ENG
3) in the file within Openrails folder, an include referencing a file called SD40-UPS4589.ENG

So I thought: if the Openrails file could have something like an "include(self)" statement, that looks for a filename called the same as itself one level above...would be faster to correct a lot of rolling stocks without having to write down this string two times for every piece.

For a wagon whose filename is WVOGrain.wag, in Openrails there's a file called WVOGrain.wag with this content:

include ( "..\\WVOGrain.wag" )
Wagon (
	include ( "..\\..\\Common.inc\\Wagons\\Std_Wag_Brakes.inc" )
)

If the first command was "include(self)", that same .wag can be used everywhere with a simple name change, without the need to open and modify it as well.
Obviously that would only work if it's used in an openrails folder inside the train original folder, anywhere else it would give an error because it won't find a filename to reference.

I hope to have given a good explanation of my idea, and I know that it's not so common to find situations like mine where the number of pieces to change/correct is in the tens of hundreds ballpark, if not thousands.


P.S. - The parameter (self) is just something I popped out of my mind, can be anything, origname, samename, same...


Luca

[Weter]

Bonjorno!
Why 3?
Just copy an original file to openrails sub-folder, add there needed parameters (or include whole blocks, if You want), remove MSTS-parameters, which You sure are no more needed and run ORTS program. It will read this file only.

[lucstef]

Hi Weter.

That was the first thing I tried, but I'm dealing with a set of rolling stocks used in a serie of activities on a single route, I'm talking about 300 activities from a now defunct VR that I happened to have a backup somewhere.
Right now I'm dealing with a serie of folders with multiple wags, from 4 to 46 each; from the time I sent my OP I guess I already added around 150 new wags just copying/pasting filenames around.
I already did others, and I'm still not finished after two days.
All this because of brake parameters that don't work right with OR, and only those; hunting for them in all the wags and engs is a pain.

You can understand that your solution isn't the best.....sorry :friends:


(I have another route with lots of activities too, those require ANOTHER different set of rolling stocks...pray for me thanks :D )


Luca

[Weter]

Create a *bat-file:

Md openrails
Copy *.eng openrails\*.eng
Copy *.wag openrails\*.wag

[lucstef]

Maybe I wasn't clear after all...

Copying files is the easy part.
If I had two or three files to correct that would have worked, remove all brake commands and replace with OR specific parameters (or just add the OR parameters and forget about MSTS ones).

Doing that in hundreds and hundreds of files is starting to be a chore.

I had a look in the route trainset I'm trying to correct, and I have 2046 wag files and 791 eng files; it's including the original MSTS set, that in itself had been tweaked by the same people so it needs my "cure" as well.
In addition I have another trainset and activity set for which I don't have numbers, but it's not small at all.
All in all, my MSTS install was overwritten by those two trainsets, and it contains almost 5000 between wag and eng files, of which I don't think there are more than 500 unused by those activities.
Doing the copy&correct you are suggesting is not possible at all, at least not in a manageable stretch of time.

My solution was to make two .inc files, one for wags and one for engs, and call them with the include method in the train folder, using standardized parameters (at least they look standard to me).

For example, I have a WVOGrain.wag whose brakes aren't recognized by OR, so instead of hunting for the errors I use the include method with the entire wag and overwriting the brake parameters using a STD_Wag_Brakes.inc file as I wrote above, that rebuilds the entire brake section and adjust the values (the original file has a pipe reduction rate of 6 PSI/s for example, a bit too slow considering that OR brake effectiveness starts at a 21-30 PSI reduction while MSTS was already good at 4-5).
For the .eng files I have to work on two different sections, that's the reason for using a different .inc for engines.

That way, I just copy an openrails folder with the prepped file as above in the train folder and change file names and include parameters in it, much easier than scrolling the copied wag or eng while deleting/pasting/typing lines of text.
If there was a way to avoid to change the reference in the include statement as I suggested, that would have been even faster as the only action required would have been a change in the filename, a simple double click/ctrl+C/ctrl+V/done task.

[Weter]

Very clever trick (never thought that way before)...
Well, it requires to think.
Appreciate Your patience.
Pardon for misunderstanding.

[Genma Saotome]

Take a look at the free version of this editor -- it has search and replace on sets of files. You might be able to insert your Include() calls at the very end of the .wag or .eng files; anything therein that matches parameter names above that point will be understood by OR as replacements. I've been using Emeditor Pro for at least 15 years* and really count on it.

A place to try would be this line: Sound ( "GenFreightWag1.sms" )

A lot of the time (not always) it is one of the last lines in .wag files. There may be GenFreightWag2, or GenFreightWag3 but there is not going to be GenFreightWag1 thru GenFreightWag97 so the number of find and replace actions should be few.

And of course ALWAYS pull some .wags into a safe place and test your changes there.

Two suggestions: Some parts of braking does vary by the value of Mass() so be sure to leave those parameters outside of your .inc file. Second, having done many files I strongly recommend you start slow and work on what is the same for most cars -- couplers, single pipe brake equipment, locomotive/engineer's brakestand and the like. That way if you goof inside of the .inc files there are only a handful you need to correct. IOW exercise safety until you really know the job.

FWIW, you can get .wags to this level of concise:

Quote

SIMISA@@@@@@@@@@JINX0D0t______

Wagon ( XM_MILW_703403_Lumber
WagonShape ( MILW_USRA_703403.s )
FreightAnim ( MILW_703403_parts.s 1 1 1 )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\USRA_SS_Boxcar\\XM_USRA_SS_Empty_Car.inc" )
Include ( "..\\Common.Inc\\Models\\Tim_Muir\\USRA_SS_Boxcar\\XM_USRA_SS_Lumber_Ld.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Type_D_Coupler_Generic_Draft_Gear.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Single_Pipe_AB_Brakes.inc" )
Include ( "..\\Common.inc\\Fleet\\DHNelson\\Std_Cast_Iron_Brakeshoe_Friction.inc" )
Sound ( "genfreightwag2.sms" )
Name ( "XM 40' MILW USRA_SS 703403 Lumber" )
)

* An example: I decided I wanted to change the paths within my \common.inc directory -- all part of Include() statements. I could see the existing folder names in Windows explorer... it was a trivial effort to change all of those names with the file based search and replace... hundreds of changes in seconds.

[lucstef]

Weter, on 31 October 2022 - 12:36 PM, said:

Pardon for misunderstanding.

Not a problem :)
I know I'm not the smartest boy in town when trying to explain myself...sigh.

Genma Saotome, on 31 October 2022 - 12:37 PM, said:

Take a look at the free version of this editor -- it has search and replace on sets of files.

Thanks Genma, I'll have a look.

[Weter]

Wait a minute:
If I understand right, include () statement may be bi-directional?
That means, it either can be in original file, at place, where a code from include-file is needed to be added, or in include file too - calling original file by link at very first string, isn't it?
Like this:

lucstef, on 31 October 2022 - 09:41 AM, said:

For a wagon whose filename is WVOGrain.wag, in Openrails there's a file called WVOGrain.wag with this content:

include ( "..\\WVOGrain.wag" )
Wagon (
	include ( "..\\..\\Common.inc\\Wagons\\Std_Wag_Brakes.inc" )
)

[lucstef]

I'm not sure if I understood your question right, butI think you're asking if code from the MSTS original file would be replaced or else from subsequent includes.
In my experience, yes: if you type a parameter twice even in the original file then the second entry will overwrite the first, and that's why the include method works better if it's the last statement in the .wag or .eng before the last bracket.

In the WVOGrain example, just copying the entire .wag file in the openrails folder and adding the include ( "..\\..\\Common.inc\\Wagons\\Std_Wag_Brakes.inc" ) before the last bracket would have the same effect, at the cost of some more seconds spent scrolling down to place.
With my copy/paste method I can adjust a single file in like 4-5 seconds; having to scroll down to last bracket would add other 2-3 seconds, not much right? JUST that addition alone means 2 and a half hours MORE time on 3000 files.....

Sorry, the accountant in me... :D


Luca