[longiron]

Genma Saotome, on 03 March 2016 - 08:55 AM, said:

OTOH there is the argument for just getting it right. The CPU cycles are there: the game loop has them available; Adding VariableMass( T|E|A ) -- Time based, One Time event based (e.g., loads, unloads), set by the activity) would minimize the occurrence of such calculations to exactly when it makes sense.

There is a side effect of having the .engs and .wags show the empty weight, at least for .wags: If you let each .wag be the empty weight and assign it's final weight elsewhere, such as in the .con file, you'll see a big reduction in the number of .wag files across the board. No longer will people need to set up two .wags: one for empties and the other for loads -- only need an empty car .wag.

My point was predominately about dynamically recalculating the weight once a train has begun moving. In an ideal world, the weight of wags would be set based on a few activity flags (empty/loaded) and what type of commodity was loaded (light, medium, maximum). The value for each flag could be stored in a standardized, include-type look up table. To do this 'right' requires a new OR WAG definition.

To switch topics, I'm getting concerned about the halfway measures and hacks (and yes I call "include" files hacks) in an attempt to maintain a semblance of MSTS compatibility while moving OR forward. Perhaps a new ENG and WAG file definition is an area the OR team should investigate as the next big improvement. That would have a huge impact on activity writing to leverage the great contributions Carlo made with dynamic loading/unloading. Combine with timetable mode. It could engage the community with some energy. Lots of good outcomes.

chris

[Genma Saotome]

longiron, on 03 March 2016 - 10:01 AM, said:

My point was predominately about dynamically recalculating the weight once a train has begun moving. In an ideal world, the weight of wags would be set based on a few activity flags (empty/loaded) and what type of commodity was loaded (light, medium, maximum). The value for each flag could be stored in a standardized, include-type look up table. To do this 'right' requires a new OR WAG definition.

To switch topics, I'm getting concerned about the halfway measures and hacks (and yes I call "include" files hacks) in an attempt to maintain a semblance of MSTS compatibility while moving OR forward. Perhaps a new ENG and WAG file definition is an area the OR team should investigate as the next big improvement. That would have a huge impact on activity writing to leverage the great contributions Carlo made with dynamic loading/unloading. Combine with timetable mode. It could engage the community with some energy. Lots of good outcomes.

chris

Having experimented extensively w/ Include files I can assure you they're not hacks but instead both realy useful and I think clearly the right way to go long term. I can reduce a 800 line .eng file to ~60-70 lines where, pretty much, the only parameter values left are the ones you might edit for customizing that particular unit -- mostly exhaust effects. All of the other 740 lines are of very little to no interest to your average end user. How many people mess with lights? Some .engs have several hundred lines for lights. They don't ever need to be in your face as they are now. Once those lines are pulled out into .inc files I've been finding value discrepancies over what should be identical values in multiple .engs -- stuff like fuel usage or max power or coupler strength... things where the differences make no sense at all (e.g., different fuel consumption values for F3A and F3B locomotives) that are either highly implausible or flat out incorrect.

For those of us interested in the post WWI US Steam Era there are only two possible sets of coupler values for freight cars -- K and AB. Why repeat that in every .wag? There are three (maybe four) brakestands in locomotives: 6-EL, 8-EL, and 24-EL all come to mind. 50 lines for locomotive monitors... move those into an .inc file and ask yourself "what are the odds these values are inappropriate to use in all my locomotives?".

The list goes on.

Using technical jargon, what include files do is normalize the data -- the eliminate redundancy are increase sharing what you know is correct. That should be encouraged.

I will say that at this stage they're not a panacea for all issues. Creating them exposes issues about whether very similar values found in the same set of parameters should remain similar instead of identical. Monitors are a perfect example: Are the values you have in hand really specific for that set of .eng files or are they reasonably correct for the vast majority of .eng files? Faced with that sort of problem the initial answer is "Beats Me". But as I continue to work the problem I hope the right answer will eventually appear (in this case I'm already leaning towards set up one monitor.inc as a fleet wide standard to select as a default and in those cases where I find an example that is substantially different, handle that instance uniquely. OTOH, weight based parameters, like Friction, almost always are unique and so it does take some experience with the data to have a good sense of which way to go.

[longiron]

Genma Saotome, on 03 March 2016 - 11:45 AM, said:

Having experimented extensively w/ Include files I can assure you they're not hacks but instead both realy useful and I think clearly the right way to go long term.


Using technical jargon, what include files do is normalize the data -- the eliminate redundancy are increase sharing what you know is correct. That should be encouraged.

I will say that at this stage they're not a panacea for all issues. Creating them exposes issues about whether very similar values found in the same set of parameters should remain similar instead of identical. Monitors are a perfect example: Are the values you have in hand really specific for that set of .eng files or are they reasonably correct for the vast majority of .eng files? Faced with that sort of problem the initial answer is "Beats Me". But as I continue to work the problem I hope the right answer will eventually appear (in this case I'm already leaning towards set up one monitor.inc as a fleet wide standard to select as a default and in those cases where I find an example that is substantially different, handle that instance uniquely. OTOH, weight based parameters, like Friction, almost always are unique and so it does take some experience with the data to have a good sense of which way to go.

Dave,

I totally agree with your objective, I term it as a 'hack' because its personal to your installation. It's not standardized in a community supportable nor shareable way. IMHO, the only path is via a new ENG/WAG file format that innately supports common parameters - like common cabs folder does in MSTS today. In that way, a standardized set of data files for whatever the parameters agreed upon can be leveraged across the community. Normalized data is really important for consistent, accurate physics.

chris

[Genma Saotome]

longiron, on 03 March 2016 - 01:26 PM, said:

Dave,

I totally agree with your objective, I term it as a 'hack' because its personal to your installation. It's not standardized in a community supportable nor shareable way. IMHO, the only path is via a new ENG/WAG file format that innately supports common parameters - like common cabs folder does in MSTS today. In that way, a standardized set of data files for whatever the parameters agreed upon can be leveraged across the community. Normalized data is really important for consistent, accurate physics.

chris

I have addressed that.

Not wanting to alter the purpose of \Default or \CommonCabs I set up two roughly equivalent folders that perform the same task of providing a standard location to drop sharable include files.

I initially started with \Common_Fleet_Stds for files having very broad potential for sharing and \Common_Model_Stds for those situations where a particular model mesh has been reskinned to different road names a whole lot of times. The payware guys do this a lot.

Over time I came to realize a tiny bit more granularity would be useful so I added some subdirectories to those two to handle geographic distribution. Right now I'm using US, Canada, Germany, UK as my testbed. It could have been just as easy to try North America, Europe, Asia, etc.

The handful of files I've placed into \Common_Fleet_Stds\US are for two types of couplers (ARA Type D and AAR type E), two types of car brakes (KC and AB), couplers for steam locomotives, tenders, and pre mid-60's diesel locomotives, and three can brake stands: Generic, 24-RL and 24RL_w_Dynamics.

Now if you think about each of those you should conclude they cover the VAST majority of all US rolling stock between 1914 and 1965.


What I'm hoping to accomplish with these experiments is to demonstrate that a substantial portion of rows in all .wags can be moved to a set of standardized .inc files. An example:

Original .wag:

Spoiler

Wagon ( XM_GN_23715_LD
 Type ( Freight )
 WagonShape ( GN_USRA_box_23715.s )
      FreightAnim ( USRA_50t_parts.s 1 1 1 )
 Size ( 3.1m 4.6m 13.275m )
      comment( 18.144t empty, 56.24t full )
 Mass ( 48.24t )


 WheelRadius ( 33in/2 )
 InertiaTensor ( Box ( 3.1m 4.6m 12.975m ) )
 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 )
  )
  Comment ( CouplingHasRigidConnection ( 1 ) )
  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 )
  )
  CouplingHasRigidConnection ( 1 )
  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 )
 )


 Adheasion ( 0.2 0.4 2 0 )
 DerailRailHeight ( 5cm )
 DerailRailForce (  120.6t )
 DerailBufferForce ( 441.79kN )

 NumWheels ( 8 )
 Friction (
  1090N/m/s -0.265   5.59mph 8.42N/m/s  1.525
  5.1N/rad/s 1  -1rad/s  0   1
 )


 BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
 BrakeSystemType ( "Air_single_pipe" )

        MaxBrakeForce( 15.9192kN )      
        MaxHandbrakeForce( 19.296kN ) 
        NumberOfHandbrakeLeverSteps( 100 )


 TripleValveRatio( 2.5 )
        MaxReleaseRate( 15 )
        MaxApplicationRate( 0.8528 )
 MaxAuxilaryChargingRate( 1.684 )
 EmergencyResCapacity( 2.604 )
 EmergencyResChargingRate( 1.684 )
 EmergencyBrakeResMaxPressure( 90 )
 BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )

   Sound ( "GenFreightWag2.sms" )
 Name ( "XM 40' GN 23715 LD" )

)

Improved .wag:

Spoiler

Wagon ( xm_gn_23715_MT

	WagonShape ( GN_USRA_box_23715.s )

	Include ( "..\\Common_Model_stds\\US\\USRA_DS_Boxcar_Tim_Muir_Model\\XM_USRA_DS_Mesh_Defined.inc" )
	Include ( "..\\Common_Fleet_Stds\\US\\Std_Type_Coupler_Generic_Draft_Gear.inc" )

	Adheasion ( 0.2 0.4 2 0 )

	Include ( "..\\Common_Model_stds\\US\\USRA_DS_Boxcar_Tim_Muir_Model\\XM_USRA_DS_MTY_Weight.inc" )
	Include ( "..\\Common_Fleet_Stds\\US\\Single_Pipe_KC_Brakes.inc" )

	Sound ( "genfreightwag2.sms" )
	Name ( "XM 40' GN 23715 MTY" )
)

If you were using the second example yourself, would feel that you were missing anything?

The change for .engs is vastly more dramatic... many hundreds of lines move into .inc files. Here's an example of what's left:
Improved .eng

Spoiler

Wagon ( AUnit_SP_6117
 comment ( 3DTrains F3 v3.0 )

 Type ( Engine )
 WagonShape ( AUnit_SP_6117.s )

	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Weight.inc" ) 
	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Mesh_Defined.inc" ) 
	Include ( "..\\Common_Fleet_Stds\\US\\Std_Late_Steam_Era_Diesel_Locomotive_Coupler.inc" )
	Include ( "..\\Common_Fleet_Stds\\US\\Std_Early_Road_Diesel_Independant_AB_Brake.inc" )
	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Lights_V3.inc" )

	Sound ( "..\\..\\3DTrains_FPack\\Sound\\3DTrains_FUnit_Eng_SP.sms" )
 )
Engine ( AUnit_SP_6117
	Effects  (
		DieselSpecialEffects  (
			Exhaust1  (
				0.0 4.5 -0.5586
				0 1 0
				0.1
			)
			Exhaust2  (
				0.0 4.5 -2.9969
				0 1 0
				0.1
			)
		)
	)
 
	Wagon ( AUnit_SP_6117 )
	Type ( Diesel )
	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Engine_Specs.inc" )
	Include ( "..\\Common_Fleet_Stds\\US\\Westinghouse_24RL_Brakestand_w_Dynamics.inc" )
	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Air_Compressor.inc" )
	CabView ( "3DTrains_FUnit.cvf" )
	HeadOut ( 1.78 3.5 4.6 )

	DieselSmokeEffectInitialMagnitude( 0.8 )
	DieselSmokeEffectMaxMagnitude( 1.6 )
	DieselSmokeEffectInitialSmokeRate( 0.5 )
	DieselSmokeEffectMaxSmokeRate( 2.9 ) 
 
	Include ( "..\\Common_Model_Stds\\US\\F3_Stds_3dtrains_V3\\SP_F3A_Monitors.inc" ) 
	EngineVariables( 1200 )
 
	Sound ( "..\\..\\3DTrains_FPack\\Sound\\3DTrains_FUnit_Cab_SP.sms" )

	Name ("SP F3A 6117 Black")
	Include ( "..\\Common_Model_Stds\\US\\FUnit_Stds_3dtrains_v3\\3dtrains_F7_v3_Text.inc" )
)

That's done in 53 lines. The original .eng was 865 lines.

Again I'll ask: Is there anything you think is missing from this improved .eng file, something whose value you'd want to tweek? Sure, you'd want to check out what is in each include file but having done that once is there ever a need to review them again? I'll argue that the few parameters people might want to tweek have been retained -- the exhaust and smoke stuff.


All of that said, I think there is still room for plenty of debate. Are the values I've put into the \Common_Fleet_Stds the right values to use? Maybe. Maybe not. It's certainly an issue worth looking into. For those include files that are in the \Common_Model_Stds I'm simply moving whatever was in the original .eng or .wag. The files are meant to be used only with the same mesh file under the circumstances of many occurrences of that mesh under many different road names. Tim Muir's USRA boxcars are an excellent example of this situation as are many locomotive models from many payware vendors.

For the rest of the fleet mesh-specific, 1 railroad include files can be useful when there are many .wags in the same folder.

For one of's... nope; Those can benefit from the use of Fleet standards but beyond that I don't bother.

I think that shows I'm trying to address most of the concerns you've raised. The omitted one is whether or not anyone else wants to use what I'm developing. IMO that will come only with an extended discussion of some of these issues and by providing some examples for people to try out for themselves.

[Jovet]

I was surprised to read about the "Include" functionality in the other thread. I think it's a great idea. Many aspects of .eng and other files (*cough*signals*cough* could be modularized and stuffed away and forgotten about.

My one suggestion on the matter is to give Include files for different purposes different filenames. An include file for a .wag and a .eng both shouldn't be .inc.

[Genma Saotome]

jovet, on 03 March 2016 - 03:31 PM, said:

I was surprised to read about the "Include" functionality in the other thread. I think it's a great idea. Many aspects of .eng and other files (*cough*signals*cough* could be modularized and stuffed away and forgotten about.

I may be wrong but I thought dealing with the Include() statement was a basic function of the parser. If so it should work for any file type. I dunno beans about signals so I'm not the one to play around in that area. Why don't you? You can follow my example above for what it should look like in the parent file. The only requirement in the .inc itself is that line one must be a comment. I've chosen to retain the original indentation in case I choose to roll it all back at some future date.

In the beginning there was also a need for the last line to be blank. I think that's changed but as I'm already in the habit of including it I'm not sure what the truth of the matter is now.

[Lindsayts]

For what its worth I completely support Dave here, it appears as far as I can see the main problem at the moment with include files is that so few are working consitently on them. As far as I am aware its mainly been Dave and I. I regard them as absolutely indespensable. It makes the ENG/WAG file easier to under stand and MUCH easier when dealing with multiple items of rolling stock of the same class. Naming is something of a problem, this though will likely sort it self out over time. A problem here is on somethings the number of different systems that do almost the same thing, brakes are a good example. I use 4 different set of braking include files, just for Victorain (Australia) rolling stock.

Another point here I have assumed due to the lack of any real enthusiasm around include files that few were interested, I my self simply cannot under stand this as there such major improvement.

Also I might point out that some developers think the ENG/WAg files are there copyright and strongly buck when you modify them, I have sort oppinions on the legal status of this sort of thing and I am consistently told the ENG/WAG files are already coptrighted and any modifaction is a direvative work and therefore cannot be copyrighted again. Its a REAL pain though getting into this sort of an argument.

Lindsay

[Lindsayts]

Genma Saotome, on 03 March 2016 - 05:57 PM, said:

I may be wrong but I thought dealing with the Include() statement was a basic function of the parser. If so it should work for any file type. I dunno beans about signals so I'm not the one to play around in that area. Why don't you? You can follow my example above for what it should look like in the parent file. The only requirement in the .inc itself is that line one must be a comment. I've chosen to retain the original indentation in case I choose to roll it all back at some future date.

In the beginning there was also a need for the last line to be blank. I think that's changed but as I'm already in the habit of including it I'm not sure what the truth of the matter is now.

From memory (its sometime since I went through OR's parsing code) it IS a basic function of the parser and therefore should work on most of OR's parsed text files, this in theory should make a good number of things simpler.

When I did my initial work on include files, the include part of the parsing code did not work properly, I mentioned this and some kind developer fixed this issue, which was no mean feat as it was quite difficukt to understand the code.

Lindsay

[conductorchris]

Well, it seems to me that for include files in rolling stock to become common practice it is modelers and reskinners who need to embrace this. I am listening. However the problem is, if I release something with include files, it won't work in MSTS and there are still a lot of MSTS users (although I am mystified as to why). What would make it easier is if there could be a batch of include files to work with. If sounds like you've already done a lot of that work, Dave.
Christopher

[Genma Saotome]

conductorchris, on 03 March 2016 - 06:37 PM, said:

Well, it seems to me that for include files in rolling stock to become common practice it is modelers and reskinners who need to embrace this. I am listening. However the problem is, if I release something with include files, it won't work in MSTS and there are still a lot of MSTS users (although I am mystified as to why). What would make it easier is if there could be a batch of include files to work with. If sounds like you've already done a lot of that work, Dave.
Christopher

No batch files. I've divided my routes into two environments: One for MSTS (really, just for RE and some utilities) and the other is pure OR. I use junctions to "load up" the \routes directories of both environments from a common library I have on an older SSD drive. In reality there's nothing in those folders... everything on disk is on the SSD. It's cool. Because \Trainsets is outside of \routes I can have original MSTS-ready .engs and .wags in one environment and pure OR in the other. They share the same names -- folder and file so I do not need to mess with any consist or activity files. Any RE or AE edits I do in the MSTS environment appear automatically in the OR environment and so I need only two procedural rules:

• Any consist files I mess around with in the MSTS side must be manually copied over to the OR side.
  
• Any .wag or .eng I edit on the OR side must stay there.

I find it very straightforward: MSTS is fading into the mist.


I do one things that I understand will not be accepted by most people: I have a master library of .wags and .engs. I've done this because many folders were found in many mini-routes. I find it easier to rely upon the procedure of editing in one master library and doing a copy/paste anywhere where it's to be used. In numerous instances I've used symbolic links (like junctions) to do this automatically for me. I seriously doubt my specific solution would be accepted by anyone else... it's filled w/ too many personal preferences.

As for gaining acceptance... there is not a lot of activity going on for new rolling stock and so I discount the probability that that channel will show the way. I think it more likely it'll be individuals like myself who are experimenting with what can be done will show the right path forward. My own work should be but one example -- it makes sense for me but for others? I dunno. It needs to be kicked around and examine -- quite bit of that actually because right now it's just one persons opinion on what might be right to do.

[longiron]

Again, I'm hoping that we can agree on a supported OR standard - what's in and what's out; what's allowed and what's not. There's work being done on steam SFX that goes beyond MSTS, which could have application in this area. There's lots of potential, we should have the OR team discuss, review and publish a standard, rather than having it develop haphazardly.

chris

[Genma Saotome]

Lindsayts, on 03 March 2016 - 06:05 PM, said:

For what its worth I completely support Dave here, it appears as far as I can see the main problem at the moment with include files is that so few are working consitently on them. As far as I am aware its mainly been Dave and I. I regard them as absolutely indespensable. It makes the ENG/WAG file easier to under stand and MUCH easier when dealing with multiple items of rolling stock of the same class. Naming is something of a problem, this though will likely sort it self out over time. A problem here is on somethings the number of different systems that do almost the same thing, brakes are a good example. I use 4 different set of braking include files, just for Victorain (Australia) rolling stock.

The issue of many variants occurred to me too... that's why I added a country folder to my \Common _Fleet_Stds. US brakes go under \US and Australian brakes under \Australia. Etc., etc.

Lindsayts, on 03 March 2016 - 06:05 PM, said:

Also I might point out that some developers think the ENG/WAg files are there copyright and strongly buck when you modify them, I have sort oppinions on the legal status of this sort of thing and I am consistently told the ENG/WAG files are already coptrighted and any modifaction is a direvative work and therefore cannot be copyrighted again. Its a REAL pain though getting into this sort of an argument.

Lindsay

<gag><spit>
Some people need to get a life.

I cannot speak for other countries but here in the U.S. copyright is predicated on demonstrating creativity. I cannot help but notice that the vast majority of what's in .engs and .wags is parameter names that came from KUJU. I see no creativity there. What's left is almost entirely numbers. I see no creativity there either but I'm willing to listen to a counter argument on that. Of particular note are two very important Supreme Court cases: First one -- An ordinary compiled list, such as the phone book, lacks creativity and cannot be copyrighted. IT IS JUST A LIST OF DATA. Those .eng and .wag files certainly look like a list to me. Second: A system of play cannot be copyrighted. What this means is how a game is played cannot be copyrighted. The words that describe the rules can be copyrighted but anyone can write their own text that results in the same game play for their own product and that's ok. I'll argue those numbers represent a significant portion of how the game is played.

You take that all together and IMO its pretty hard to argue copyright applies. That said, I've always spoken of this matter where moral considerations trump all: If some guy has said he doesn't want his complied list of Kuju names and numbers he copied from somewhere else messed with, we should respect that and not distribute revisions of his stuff. Even when its stupid.

[Lindsayts]

conductorchris, on 03 March 2016 - 06:37 PM, said:

Well, it seems to me that for include files in rolling stock to become common practice it is modelers and reskinners who need to embrace this. I am listening. However the problem is, if I release something with include files, it won't work in MSTS and there are still a lot of MSTS users (although I am mystified as to why). What would make it easier is if there could be a batch of include files to work with. If sounds like you've already done a lot of that work, Dave.
Christopher

The way I look at it is is an OR ENG file using includes is just an MSTS eng that is split. In the end what the parsers sees is the same thing. Remember when one is using includes one ONLY has to do any individual system once.

Here is my list of includes, I have as yet not done a standard naming scheme, but these files will cover at least 90% of my rollings stock.
I am putting these up for discusion, they should NOT be regarded as any kind of final work or any kind of standard.

Brake_Westinghouse_AirBrake.inc
Brake_Westinghouse_EngineBrakeContrl.inc
Brake_Westinghouse_EngineBrakeContrl_Setup.inc
Brake_Westinghouse_TRainBrakeContrl_setup.inc
Brake_Westinghouse_engine_TwinPipe.inc
Brake_Westinghouse_engine_single_pipe.inc
Brake_Westinghouse_single_pipe_wagon.inc
Brake_Westinghouse_twin_pipe_wagon.inc
Brake_controler_Westinghouse_Graduated.inc
Brake_train_single_pipe_Control.inc
Control_Blower.inc
Control_Dampers.inc
Control_Fire_door.inc
Control_Heating_tap.inc
Dynamic_brake_control.inc
EMD_noncpu_8_notch_throttle.inc
Not required
Steam_Regulator_no-step.inc
Steam_cuttoff_05-steps.inc

There are also includes for an individual class of loco, for example the Victorian railways H220 class steamer
At the moment I have these in with the loco's ENG file.

H220_Effects.inc
H220_EngineControllers_misc.inc
H220_Lights.inc
H220_Misc.inc
H220_Motive.inc
H220_Wagon.inc

Finally an example ENG file with using includes...........
Again it is for H220, To make another version of the same class only two line shave to be altered and one can GARUNTEE each item of rolling stock of the sane class will stay the same.
Also every differnt item of rolling stock using the same system (brakes , engine control etc) will behave exactly the same.

Note: MaxBrakeForce may appear to be out of place but its individual to the class of loco.

Comment ( required by new parser )

Wagon   ( TA_AU_VR_H220_FA_P

Comment ( The wagonshape parameter MUST be in the main eng file )

        WagonShape ( TA_AU_VR_H220.s )

        include ( H220_Wagon.inc )

        include ( ..\\eng_inc\\Brake_Westinghouse_single_pipe_wagon.inc )

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

        MaxBrakeForce( 142.254kN )

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

        include ( H220_Lights.inc )

        FreightAnim ( Harry_FA.s 0.01 0.01 )

        Sound ( "H220eng.sms" )

        )


Engine ( TA_AU_VR_H220_FA_P

        include ( H220_Effects.inc )

        Wagon ( TA_AU_VR_H220_FA_P )

        Name ( " TA VR H-220 4-8-4 Auto Fireman" )


        include ( Brake_Westinghouse_Compressor_Main_resv.inc )
        include ( ..\\eng_inc\\Brake_Westinghouse_AirBrake.inc )
        include ( ..\\eng_inc\\Brake_Westinghouse_EngineBrakeContrl_Setup.inc )
        include ( ..\\eng_inc\\Brake_Westinghouse_TRainBrakeContrl_setup.inc )


        CabView ( "AU_H220.cvf" )

        HeadOut (  -1.6 3.2 -7.2 )

           EngineControllers (
            comment( Engine controls )

                include ( ..\\eng_inc\\Steam_cuttoff_05-steps.inc )
                include ( ..\\eng_inc\\Steam_Regulator_no-step.inc )
                include ( ..\\eng_inc\\Brake_train_single_pipe_control.inc )
                include ( ..\\eng_inc\\Brake_Westinghouse_EngineBrakeContrl.inc )
                include ( ..\\eng_inc\\Control_Fire_door.inc )
                include ( ..\\eng_inc\\Control_Blower.inc )
                include ( ..\\eng_inc\\Control_Dampers.inc )
                include ( ..\\eng_inc\\Control_Heating_tap.inc )

                include ( H220_EngineControllers_misc.inc )

                )

        include ( H220_motive.inc )


 comment(fire temp, fire mass, water mass, boiler pressure,
  water level, tender_water_mass, tender_coal_mass,
  smoke_quantity, fire_condition, coal quality )

Comment ( EngineVariables( 990 1167 6468 224 1 14000 1 1 1 0.85 ) )

Sound ( "H220cab.sms" )

Name ( " TA VR H-220 4-8-4 Auto Fireman" )

  Description (

 "VR H class H220 4-8-4 Steam loco\n"+
  "Configured for MSTS Automatic fireman\n"+
 "____________________________\n\n"+
 "3d Model:\n"+
      "   Russell Beer\n"+
 "____________________________\n\n"+
      "Textures:\n"+
      "   Russell Beer\n"+
 "____________________________\n\n"+
      "Physics:  Ian Bowles & Ian Roberts\n"+
 "____________________________\n\n"+
 "Copyright © 2007 Team-ALCO\n"+
 "All Rights Reserved.\n"+
 "____________________________\n\n"+

"VR H class H220 4-8-4 three cylinder locomotive\n"+
"Brakes: Air, operates at 70 psi\n\n"+
"Power Source: 220psi Mechanically Fired, coal burning boiler\n\n"+
"Wheel Configuration: 8 - 5' 7" (1.70m) diameter driving wheels in a\n"+
"4-8-4 configuration\n\n"+
"Max Service Speed for Passenger service 70 mph ( 113 km/h )\n\n"+
"Height: 14.11 ft (4.30 m)\n\n"+
"Width: 9.46 ft (2.88 m)\n\n"+
"Length (locomotive): 51.18 ft (15.60 m)\n\n"+
"Tractive Effort at 85% Boiler Pressure: 54187 lbf (241.03kN)\n\n"+
"Coal Capacity: 9 Long Tons (9.14 metric tons)\n\n"+
"Water capacity: 14000Imp Gallons (64635liters)\n\n"+
"Couplings: Automatic\n\n"+
 "Brakes: Westinghouse A6-ET AirBrakes. \n\n"
 )
        )

[Lindsayts]

One of the problems in an include naming scheme is for the names to be meaning full and descriptive without becoming a handfull, An example of this is Westinghouse brakes there being multiple different specs all using the same main name.

I would be interested is Chris's (and Dave's) thoughts on this. I believe it would be a major step forward to get this sorted.

Lindsay

[Hamza97]

Quote

Again, I'm hoping that we can agree on a supported OR standard - what's in and what's out; what's allowed and what's not. There's work being done on steam SFX that goes beyond MSTS, which could have application in this area. There's lots of potential, we should have the OR team discuss, review and publish a standard, rather than having it develop haphazardly.

I will second that.. . There is DIRE need of standard for many OR parmaters. Take .inc for e.g. AFAIK, only Dave and Linda are using this. Some other members may using different techniques.

Ditto for any new OR parameters, some parameters are required to be there in separate OpenRails Subfolder, some parameters are required to be there in original .eng file only. ORTSDieselEngine would be a good example of former, ORTSTractionCurves for latter.

Once a standard is established, many will be encouraged to follow that way.... :)