[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

[Genma Saotome]

Some examples for your consideration -- these might not be 100% correct but they do serve to show the potential of the Include() statement.

This example shows where I'd put weight related data... something that will vary for empty, loaded, and/or specific kinds of loads -- coal vs gravel for instance -- and so while this file is called "Default_Weight.inc" you could use a different name for different car numbers or different weight situations:

	Comment ( "Default Weight" )

	Mass ( "23.7t" )
	DerailRailHeight ( 4cm )
	DerailRailForce ( 29.25t )
	DerailBufferForce ( 440.5kN )
	MaxBrakeForce( 16.4kN )
	MaxHandbrakeForce( 19.68kN )

	Friction (
		528.4N/m/s		-0.10		 1.6mph		2.220N/m/s		1.945
		5.1N/rad/s		1		-1rad/s		0		1
	)

This file has the dimensional data for the mesh in a file I've called "Car_Dimensions.inc":

	Comment ( "Standard Car Dimensions" )
	Comment ( "Built 6-30-06, T.W.Muir" )

	Type ( Freight )
	FreightAnim ( milw_cab_parts_bw1.s 1 1 )
	Size ( 3.1m 4.6m 12.66m )
	WheelRadius ( 33in/2 )
	NumWheels (	8 )
	InertiaTensor ( Box ( 3.1m 4.6m 12.66m ) )

For a caboose or passenger car there is a mesh specific interior, so here is "Interior.inc":

	
	PassengerCapacity ( 4 )

	Inside (
		PassengerCabinFile ( MILW_Cab_992075.s )
		PassengerCabinHeadPos ( -2.0 2.4 -0.50 )
		RotationLimit ( 45 360 0 )
		StartDirection ( 0 0 0 )
		Sound          (  "GenPassWagModern.sms" )
	)

And as most cars use fairly standard couplers & draft gear, a file called "Std_Type_E_Coupler_Generic_Draft_Gear.inc":

	comment ( "Type E coupler w/ generic draft gear" )
	comment ( "For cars equipped with uncushioned slack pro-couplers ie: Hopper cars, gondolas, tankcars" )
	comment ( "older flatcars and boxcars." )

	Coupling (
		Type ( Automatic )
		Spring (
			Stiffness ( 0 5e6N/m )
			Damping ( 2e6N/m/s 2e6N/m/s )
			Break ( 5.1e7N 5.1e7N )
			r0 ( 5cm 8cm )
		 )
		Velocity ( 0.2m/s )
	)
	Coupling (
		Type ( Automatic )
		Spring (
			Stiffness ( 0 5e6N/m )
			Damping ( 2e6N/m/s 2e6N/m/s )
			Break ( 5.1e7N 5.1e7N )
			r0 ( 5cm 8cm )
		 )
		Velocity ( -0.2m/s )
		)

	Buffers (
		Spring (
			Stiffness ( 5e6N/m 8e6N/m )
			Damping ( 1e6N/m/s 1e6N/m/s )
			r0 ( 0m 1e9 )
		)
		Centre ( 0.5 )
		Radius ( 1 )
		Angle ( 0.5deg )
	)

and for common brake equipment, a file called "Std_AB_Brake.inc":

 Comment ( Standard AB Brake for North American Freight Car )

	BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
	BrakeSystemType ( "Air_single_pipe" )
	TripleValveRatio( 2.5 )
	MaxReleaseRate( 1.86 )
	MaxApplicationRate( 0.9 )
	MaxAuxilaryChargingRate( 0.845 )
	EmergencyResCapacity( 2.604 )
	EmergencyResChargingRate( 1.684 )
	EmergencyBrakeResMaxPressure( 90 )
	BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )


	NumberOfHandbrakeLeverSteps( 100 )

All of which leaves a tiny bit of data in the original .wag file:

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

Wagon ( NE_MILW_992075 
	WagonShape ( NE_MILW_992075.s )

	Include ( Default_Weight.inc )
	Include ( Interior.inc )
	Include ( Car_Dimensions.inc )
	Include ( Std_Type_E_Coupler_Generic_Draft_Gear.inc )
	Include ( Std_AB_Brake.inc )

	Adheasion ( 0.2 0.4 2 0 )


  	Sound ( "GenPassWagModern.sms" )
	Name  ( "Milw. Ribside Caboose 992075" ) 
)

Anybody got a suggestion where that adheasion should go?

Looking at that highly reduced .wag it's pretty easy to get ideas for how multiple cars could reuse these include files...

IMO the new Include feature would be a lot more useful if there was a way to include a path to each include file... that would enable, at a minimum, a single instance of fleet-wide files like Std_Type_E_Coupler_Generic_Draft_Gear.inc and Std_AB_Brake.inc.


Anyway... all of the above are examples reflecting my initial trials at understanding this new feature. I think it has great potential.

[Genma Saotome]

And a comment on why I think some form of pathing would be most useful... this is a problem statement only; there are a couple of ways to solve it but that discussion could be complex and so I think, for now, it's best to leave it at just describing the problem.

Taking the example .wag file I posted above:

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

Wagon ( NE_MILW_992075 

	Include ( Default_Weight.inc )
	Include ( Interior.inc )
	Include ( Car_Dimensions.inc )
	Include ( Std_Type_E_Coupler_Generic_Draft_Gear.inc )
	Include ( Std_AB_Brake.inc )

	Adheasion ( 0.2 0.4 2 0 )


  	Sound ( "GenPassWagModern.sms" )
	Name  ( "Milw. Ribside Caboose 992075" ) 
)

it becomes a trivial exercise for the original 3d modeler to include a modified copy of the mesh file, one that is matched to a second set of skins... he'd have a second, tiny .wag file that changes the mesh file name and the value of the Name() parameter:

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

Wagon ( NE_MILW_992032 

	Include ( Default_Weight.inc )
	Include ( Interior.inc )
	Include ( Car_Dimensions.inc )
	Include ( Std_Type_E_Coupler_Generic_Draft_Gear.inc )
	Include ( Std_AB_Brake.inc )

	Adheasion ( 0.2 0.4 2 0 )


  	Sound ( "GenPassWagModern.sms" )
	Name  ( "Milw. Ribside Caboose 992032" ) 
)

And "Bob's your Uncle", it's done! Pretty cool.

But it doesn't work quite as well when some other person takes the original model and reskins it. In this case the reskinned model has to use it's own directory, one that has the new textures in it. He reskinner would copy the original directory and over-write the original textures w/ his replacement and change the value in the Name() parameter. Easy to do. But what that means now is there are duplicate instances of all of those include files. Repeat the reskinning and your repeat the duplication.

If the Include feature could provide for some sort of pathing the reskinner would not need to duplicate the parametric files but instead just point to the original distribution folder. Given that the reskinner only needs to distribute his textures and his revised (tiny) .wag. I think that would make managing the parametric data a whole lot easier.

[Lindsayts]

You can use a path statement in the include file it works exactly how one finds it say a sound or a cabview file an example from Commenwealth Railways Bud deisel rail car. I have the includes that are common through out the system in...

.....\TRAINS\TRAINSET\eng_inc\

We will have to sometime work out a standard naming scheme for system wide includes for easier reuse, but this can come in time once the includes are up and running.

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

Wagon ( AU_anRDC_CB2
        comment( Original car & cab graphics by Gaétan Bélanger. March 2002 )
        comment( Original power sound by Andy Hockin. June 2001 )
        comment( Operating & sound modifications by Richard Foley. March 2002 )
      comment( Braking, physics, lighting sound modifications pass view
                by Yuri Sos 1 Sep 2003 )

        Type ( Engine )
        WagonShape ( AU_anRDC_CB2.s )

        include ( RDC_Dimensions.inc )

        include ( RDC_Adhesion_derail_friction.inc )

        AntiSlip ()


        include ( ..\\eng_inc\\Brake_Westinghouse_single_pipe.inc )

      Comment ( ============= Brake Force======= )

        MaxBrakeForce( 67kN # disk brakes )


      Comment ( =========== Lighting =========== )

        include ( RDC_Lighting.inc )


        Sound ( "RDCeng.sms" )

      Comment ( =========== Start Passenger View ============= )

      Inside (
             PassengerCabinFile ( AU_anRDC_CB2.s )
             PassengerCabinHeadPos ( -1.0 2.5 0.0 )
             RotationLimit ( 0 180 0 )
             StartDirection ( 0 0 0 )
                 )


      Comment  (  =============== End Passenger View ========== )


)

Engine ( AU_anRDC_CB2

        include ( RDC_Effects.inc )

        Wagon ( AU_anRDC_CB2 )

        Name ( "AU AN RDC CB-2" )

        include ( RDC_motive.inc )

)

Lindsay

[Lindsayts]

I put Adhesion with the dimensions. My overall break up us slightly different to yours, but I am doing primemovers so they are more complex. The brake includes though are the same.

Lindsay

[Genma Saotome]

There are probably as many ways to set out the contents in the Include files as there are combinations of lines in the .wags.... The obvious ones, I think, are going to be brake and coupler include files. I suspect that both are applicable fleet-wide (perhaps for .wags from each country rather than all .wags) and so that's where the pathing issue comes into play.

Lights and interiors are pretty obvious candidates too, so long as they describe the same mesh. I suspect there may be some variation when multiple meshes are distributed for the same kind of rolling stock -- different years for a locomotive for instance where the differences are the number and placement of lights. But I think a lot of instances the number, color, and placement is a constant and so, for now, I'm trying one light section for all of the same models (e.g., the H10-44 locomotive) I'm fiddling with. If it turns out there are variations from one mesh to another I'll have to rename the Include()... ad set up others... Early Vs. Late for instance.

There is one Include that I believe should not be necessary: the one that has all of the weight derived parameters. You need Mass() but all of the rest can be computed by the OR software and should not be part of any .wag. Those "...Force...()" and Friction parameters all vary only because of the value of Mass(). So why put them in .wags when the computation could be done by OR?

You are ahead of me WRT trying out include() with locomotives... I'm confused about all of the brake parameters... it's hard to tell what the purpose is for the .wag portion is and how it differs from what is in the Engine() section. Do you know?

The name you chose for "Brake_Westinghouse_single_pipe.inc" looks very right; what data did you put into it?

[cjakeman]

Genma Saotome, on 29 May 2014 - 04:04 PM, said:

Anybody got a suggestion where that adheasion should go?

Just a small point, but OR has accepted "adhesion" as well as "adheasion" for some time. For files like this which are not intended for MSTS, we can use the correct spelling at last.

[James Ross]

I don't think I've seen it tried, but something else that should just work is includes-inside-includes. I.e. you can include one file which can itself include more. Each include should be resolved relative to the file it is in (not the base file). Do let me know if there are any issues with this, though. :bigboss:

[gpz]

Dave,
Just one small note for your arrangement: The NumWheels parameter in eng doesn't have any real meaning, it is used only for the adhesion calculations. At many cases it is just set to 1. So it might have to be removed from the car dimensions, and be put together with "Adheasion".

[Lindsayts]

Genma Saotome, on 29 May 2014 - 09:35 PM, said:

There are probably as many ways to set out the contents in the Include files as there are combinations of lines in the .wags.... The obvious ones, I think, are going to be brake and coupler include files. I suspect that both are applicable fleet-wide (perhaps for .wags from each country rather than all .wags) and so that's where the pathing issue comes into play.

Lights and interiors are pretty obvious candidates too, so long as they describe the same mesh. I suspect there may be some variation when multiple meshes are distributed for the same kind of rolling stock -- different years for a locomotive for instance where the differences are the number and placement of lights. But I think a lot of instances the number, color, and placement is a constant and so, for now, I'm trying one light section for all of the same models (e.g., the H10-44 locomotive) I'm fiddling with. If it turns out there are variations from one mesh to another I'll have to rename the Include()... ad set up others... Early Vs. Late for instance.

There is one Include that I believe should not be necessary: the one that has all of the weight derived parameters. You need Mass() but all of the rest can be computed by the OR software and should not be part of any .wag. Those "...Force...()" and Friction parameters all vary only because of the value of Mass(). So why put them in .wags when the computation could be done by OR?

You are ahead of me WRT trying out include() with locomotives... I'm confused about all of the brake parameters... it's hard to tell what the purpose is for the .wag portion is and how it differs from what is in the Engine() section. Do you know?

The name you chose for "Brake_Westinghouse_single_pipe.inc" looks very right; what data did you put into it?

First a point all include files must have a comment on the first line your "Interior.inc" does not have this.
As for various parameters in the eng file at this stage I am not to concerned on individual items, the important point at this stage is to test the include system as much as possible.

For the brake parameters for this particular single pipe include these will have come with eng file for the model as this model are one of the few eng files I have not altered (much anyway). My second test vehicle the Bluebird though has been much altered. For this I did a long series of brake tests on a level track and the parameters were altered until the railcar stopping distance matched real life performances (for the brake cylinder pressure). I have not got the response times as good as I would like this may though require some of OR's specfic data.

The actual brake parameter names in the eng file are mostly quite descriptive as long as one has a firm idea on why the Westinghouse Graduated release system works.

A comment that gpz's post has brought up, it would be nice if at least a list of all the eng and wag file parameters OR used was availible. When each particular part of the source was writen it would have saved a great deal of effort if a short description of each one created/used in OR was produced.

Lindsay

[cjakeman]

Hi Lindsay,

Lindsayts, on 30 May 2014 - 01:54 AM, said:

A comment that gpz's post has brought up, it would be nice if at least a list of all the eng and wag file parameters OR used was availible.

You must have missed the list of 39 parameters in the appendix at the back of the manual.

Would be nice to have a description too though.