[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

[Weter]

Hello, Luca.
I confirm that (it was seen in Rudolph Richrer's ENG manual): "second" blocks are taken in account, as like they either "overwrite" previous ones, or as like program "reads" file from its end, so takes the first block, it encounters, but ignores all subsequent ones with the same "Name ()"

But my original question was caused by my being surprised, seeing new for me method: the first string (or second, if the first is blanc) of include file in example contained "call" of superseding "original" rolling-stock file; then contained include block itself.
As I thought before, only "calling" of include-files from original ones are used, all this become very interesting for me to learn.
Exactly this technique I've called "reversible" include command usage in my question.

[lucstef]

Weter, on 03 November 2022 - 10:27 PM, said:

Hello, Luca.
I confirm that (it was seen in Rudolph Richrer's ENG manual): "second" blocks are taken in account, as like they either "overwrite" previous ones,

That ^^^

Quote

But my original question was caused by my being surprised, seeing new for me method: the first string (or second, if the first is blanc) of include file in example contained "call" of superseding "original" rolling-stock file; then contained include block itself.
As I thought before, only "calling" of include-files from original ones are used, all this become very interesting for me to learn.
Exactly this technique I've called "reversible" include command usage in my question.

Oh I see what you were saying; more than "reversible", I'd call it "recursive" and I'm still not sure it's the right term :)

For what I understand, the include(file2) statement in file1 takes the file2's text and places it inside file1 at the exact position of the statement.

That means, include ( "..//WVOGrain.wag" ) grabs all the text inside WVOGrain.wag and builds the first part of the new .wag file (that is now a full .wag config file, including the SIMISA first line of the original), then include ( "..\\..\\Common.inc\\Wagons\\Std_Wag_Brakes.inc" ) adds instructions from STD_Wag_Brake.inc inside the wagon section, and being after the the first include() these will be at the end of this section.

(The first empty line is required, or the include() statement wouldn't work.)

It's like programming with subroutines, that are then called by a base program one after another or based on specific tests; only, here we're working with text files and the result is a new text file.

Later from home I'll post the original .wag, the .inc and will show you the resulting file; I'll even post an example from an .eng file where there are additions to two sections (wagon and engine), it's not hard to understand and (to me) very simple and straightforward.



Luca

[lucstef]

(This is not for Weter or other experts, it's just to show how I understand how the include() statement works)

Let's start with the original WVOGrain.wag:

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

Wagon ( WVOGrain
	comment( WVO Covered hopper, hi-hip version)
	comment( Physics by Chris Lee)
	Type ( Freight )
	WagonShape ( WVOGrain.s )
	Size ( 3.243m 4.728m 17.503m)
	comment( 23.776t empty, 106.747t full )
	Mass ( 73.78t )
	WheelRadius ( 36in/2 )
	InertiaTensor ( Box (3m 3.6m 13.5m) )
	Coupling (
		Type ( Automatic )
		Spring (
			Stiffness ( 1e6N/m 5e6N/m )
			Damping ( 1e6N/m 1e6N/m )
			Break ( 5.1e8N 5.1e8N )
			r0 ( 20cm 30cm )
		)
		comment( CouplingHasRigidConnection () )
		Velocity ( 0.1m/s )
	)
	Buffers (
		Spring (
			Stiffness ( 1e6N/m 5e6N/m )
			Damping ( 1e6N/m/s 1e6N/m/s )
			r0 ( 0m 1e9 )
		)
		Centre ( 0.5 )
		Radius ( 1 )
		Angle ( 0.5deg )
	)
			
	Adheasion ( 0.2 0.4 2 0 )
	DerailRailHeight ( 4cm )
	DerailRailForce ( 2.5N/kg*23t )
	DerailBufferForce ( 400kN )
	NumWheels (	8 )
	Friction (
		871N/m/s		0		1mph		3.26N/m/s		1.8
		5.1N/rad/s		1		-1rad/s		0		1
	)
	Lights	(	2
				
		Light	(
			comment( Rear red light flashing dim )
			Type		( 0 )
			Conditions	(
				Headlight ( 2 )
				Unit ( 3 )
			)
			FadeIn	( 0.5 )
			FadeOut	( 0.5 )
			Cycle		( 0 )
			States	(	2
				State	(
					Duration ( 0.35 )
					LightColour ( 80ff0000 )
					Position ( 0.0 1.2 -8.955 )
					Azimuth ( -180 -180 -180 )
					Transition ( 0 )
					Radius ( 1.0 )
				)
				State	(
					Duration ( 0.35 )
					LightColour ( 00000000 )
					Position ( 0.0 1.2 -8.955 )
					Azimuth ( -180 -180 -180 )
					Transition ( 0 )
					Radius ( 1.0 )
				)
			)
		)
		Light	(
			comment( Rear red light flashing bright )
			Type		( 0 )
			Conditions	(
				Headlight ( 3 )
				Unit ( 3 )
			)
			FadeIn	( 0.5 )
			FadeOut	( 0.5 )
			Cycle		( 0 )
			States	(	2
				State	(
					Duration ( 0.35 )
					LightColour ( 80ff0000 )
					Position ( 0.0 1.2 -8.955 )
					Azimuth ( -180 -180 -180 )
					Transition ( 0 )
					Radius ( 1.0 )
				)
				State	(
					Duration ( 0.35 )
					LightColour ( 00000000 )
					Position ( 0.0 1.2 -8.955 )
					Azimuth ( -180 -180 -180 )
					Transition ( 0 )
					Radius ( 1.0 )
				)
			)
		)
	)

	BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )    <----- THIS SECTION HAS SOME SORT OF ISSUE THAT I'M NOT GOING TO CHECK,
	BrakeSystemType( "Air_single_pipe" )                                                              <----- IN OPENRAILS THE BRAKES AREN'T RECOGNIZED
	MaxBrakeForce( 22.13kN )                                                                            !
                                     
	MaxHandbrakeForce( 22.13kN )                                                                        !
	NumberOfHandbrakeLeverSteps( 100 )
                                                                                                            !
	EmergencyBrakeResMaxPressure( 110 )
	TripleValveRatio( 2.5 )                                                                             !
	MaxReleaseRate( 2.27 )
	MaxApplicationRate( 1.717 )                                                                         !
	MaxAuxilaryChargingRate( 1 )
	EmergencyResCapacity( 2.604 )
	EmergencyResChargingRate( 1 )                                                                       !
	BrakeCylinderPressureForMaxBrakeBrakeForce( 64 )                                                 <-----------------------------------------------------------------------

  	Sound (	"GenFreightWag1.sms" )
)

I then made a new brake system section and typed it in a STD_Wag_Brake.inc:

	BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
	BrakeSystemType( "Air_single_pipe" )
	MaxBrakeForce( 78kN )
	MaxHandbrakeForce ( 57.2kN )
	NumberOfHandbrakeLeverSteps( 100 )
	EmergencyBrakeResMaxPressure( 110 )
	TripleValveRatio( 2.5 )
	EmergencyResVolumeMultiplier ( 1.461 )
	MaxReleaseRate( 22.2 )
	MaxApplicationRate( 13.9 )
	MaxAuxilaryChargingRate( 20 )
	EmergencyResCapacity( 2.025ft^3 )
	EmergencyResChargingRate( 20 )
	BrakePipeVolume ( 0.307ft^3 )
	BrakeCylinderPressureForMaxBrakeBrakeForce( 90 )

(Yes, I know, same everything apart from the tweaked values but still.....)

At this point, I made an Openrails folder inside the WVOGrain folder, where I placed a text file with the following text called WVOGrain.wag (the well known include method, with my comments):

                                                                           <----- REQUIRED EMPTY LINE
include ( "..\\WVOGrain.wag" )                                             <----- CALLS THE ORIGINAL WAG FILE
Wagon (                                                                    <----- THIS MEANS: INSERT THE NEXT LINES IN THE WAGON SECTION
	include ( "..\\..\\Common.inc\\Wagons\\Std_Wag_Brakes.inc" )       <----- CALLS THE .INC FILE WITH THE NEW PARAMETERS
)                                                                          <----- CLOSE THE WAGON SECTION

To note: this trick is in the manual, where it explains how to add instructions to remove the trees on rails in a route without touching the original .trk definition file.

The final result, if it would be visible, would be that:

SIMISA@@@@@@@@@@JINX0D0t______                                                              <---- START OF THE ORIGINAL WVOGRAIN.WAG

Wagon ( WVOGrain
        comment( WVO Covered hopper, hi-hip version)
        comment( Physics by Chris Lee)
        Type ( Freight )
        WagonShape ( WVOGrain.s )
        Size ( 3.243m 4.728m 17.503m)
        comment( 23.776t empty, 106.747t full )
        Mass ( 73.78t )
        WheelRadius ( 36in/2 )
        InertiaTensor ( Box (3m 3.6m 13.5m) )
        Coupling (
                Type ( Automatic )
                Spring (
                        Stiffness ( 1e6N/m 5e6N/m )
                        Damping ( 1e6N/m 1e6N/m )
                        Break ( 5.1e8N 5.1e8N )
                        r0 ( 20cm 30cm )
                )
                comment( CouplingHasRigidConnection () )
                Velocity ( 0.1m/s )
        )
        Buffers (
                Spring (
                        Stiffness ( 1e6N/m 5e6N/m )
                        Damping ( 1e6N/m/s 1e6N/m/s )
                        r0 ( 0m 1e9 )
                )
                Centre ( 0.5 )
                Radius ( 1 )
                Angle ( 0.5deg )
        )
                        
        Adheasion ( 0.2 0.4 2 0 )
        DerailRailHeight ( 4cm )
        DerailRailForce ( 2.5N/kg*23t )
        DerailBufferForce ( 400kN )
        NumWheels (     8 )
        Friction (
                871N/m/s                0               1mph            3.26N/m/s               1.8
                5.1N/rad/s              1               -1rad/s         0               1
        )
        Lights  (       2
                                
                Light   (
                        comment( Rear red light flashing dim )
                        Type            ( 0 )
                        Conditions      (
                                Headlight ( 2 )
                                Unit ( 3 )
                        )
                        FadeIn  ( 0.5 )
                        FadeOut ( 0.5 )
                        Cycle           ( 0 )
                        States  (       2
                                State   (
                                        Duration ( 0.35 )
                                        LightColour ( 80ff0000 )
                                        Position ( 0.0 1.2 -8.955 )
                                        Azimuth ( -180 -180 -180 )
                                        Transition ( 0 )
                                        Radius ( 1.0 )
                                )
                                State   (
                                        Duration ( 0.35 )
                                        LightColour ( 00000000 )
                                        Position ( 0.0 1.2 -8.955 )
                                        Azimuth ( -180 -180 -180 )
                                        Transition ( 0 )
                                        Radius ( 1.0 )
                                )
                        )
                )
                Light   (
                        comment( Rear red light flashing bright )
                        Type            ( 0 )
                        Conditions      (
                                Headlight ( 3 )
                                Unit ( 3 )
                        )
                        FadeIn  ( 0.5 )
                        FadeOut ( 0.5 )
                        Cycle           ( 0 )
                        States  (       2
                                State   (
                                        Duration ( 0.35 )
                                        LightColour ( 80ff0000 )
                                        Position ( 0.0 1.2 -8.955 )
                                        Azimuth ( -180 -180 -180 )
                                        Transition ( 0 )
                                        Radius ( 1.0 )
                                )
                                State   (
                                        Duration ( 0.35 )
                                        LightColour ( 00000000 )
                                        Position ( 0.0 1.2 -8.955 )
                                        Azimuth ( -180 -180 -180 )
                                        Transition ( 0 )
                                        Radius ( 1.0 )
                                )
                        )
                )
        )

        BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
        BrakeSystemType( "Air_single_pipe" )                                                          
        MaxBrakeForce( 22.13kN )                                                                            
                                     
        MaxHandbrakeForce( 22.13kN )                                                                        
        NumberOfHandbrakeLeverSteps( 100 )
                                                                                                            
        EmergencyBrakeResMaxPressure( 110 )
        TripleValveRatio( 2.5 )                                                                             
        MaxReleaseRate( 2.27 )
        MaxApplicationRate( 1.717 )                                                                         
        MaxAuxilaryChargingRate( 1 )
        EmergencyResCapacity( 2.604 )
        EmergencyResChargingRate( 1 )                                                                       
        BrakeCylinderPressureForMaxBrakeBrakeForce( 64 )                                          

        Sound ( "GenFreightWag1.sms" )

        BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )   <---- THIS IS THE ADDED SNIPPET FROM THE .INC
        BrakeSystemType( "Air_single_pipe" )
        MaxBrakeForce( 78kN )
        MaxHandbrakeForce ( 57.2kN )
        NumberOfHandbrakeLeverSteps( 100 )
        EmergencyBrakeResMaxPressure( 110 )
        TripleValveRatio( 2.5 )
        EmergencyResVolumeMultiplier ( 1.461 )
        MaxReleaseRate( 22.2 )
        MaxApplicationRate( 13.9 )
        MaxAuxilaryChargingRate( 20 )
        EmergencyResCapacity( 2.025ft^3 )
        EmergencyResChargingRate( 20 )
        BrakePipeVolume ( 0.307ft^3 )
        BrakeCylinderPressureForMaxBrakeBrakeForce( 90 )                                                 <---- ...TO HERE
)                                                                                              <----- END OF ORIGINAL FILE

That's it!!!

Oh, you can add parameters in different sections too, look at this commented example where I added new values in an .eng file:

include ( "..\\WVOSD402.eng" )                                                             <---- CALL THE ORIGINAL DEFINITIONS
Wagon (                                                                                    <---- ADD LINES TO THE WAGON SECTION
	include ( "..\\..\\Common.inc\\Locomotives\\Brakes\\Std_Loco_Brakes.inc" )
	MaxBrakeForce( 200kN )
)                                                                                          <---- END THE WAGON SECTION
Engine (                                                                                   <---- ADD LINES TO THE ENGINE SECTION
	include ( "..\\..\\Common.inc\\Locomotives\\Std_Loco_Eng.inc" )
)                                                                                          <---- END THE ENGINE SECTION

If you're working on a copy of the original file not using the first include, then you won't need the wagon() and/or engine() statements, because the new code will be placed right at the spot where the new parameter's include() is.


I hope this explanation is clear enough to understand the include() statement, and it's useful to ay least one of you :)
(I'm almost sure it's somewhere in the manual too, but I couldn't find it).


Luca

[Genma Saotome]

Luca, if you continue with this approach you should get to a point where the second file can become the actual .wag file. Go back to my post (number 7 in this thread) and look at the .wag file I posted and think about it.

[lucstef]

Genma, I must admit I can't understand this last post.
Aren't the resulting files in Openrails folders just MSTS structured .wag and .eng files with added ORTS parameters?

One thing I didn't mention: I wanted to keep the original files (all 4000+ of them!) untouched to be used by MSTS if needed, although I'm on the way to abandon it entirely if not for the activity editor.
AS a plus, I can tweak the parameters if I find them too hard or easy, and that would reflect on all the rolling stock at once.


Luca