[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.... :)

[Genma Saotome]

I'm applying my professional skills as a (now retired) career data modeler to this issue. A data modeler identifies the natural organization of data... what goes together, how different sets of data (objects if you want) relate to each other.

What that means in this case is actually pretty simple: I look for data that are all related to the same purpose (and Lindsay is correct in noting that our .wags and .engs have already grouped much of the data into clusters of sequential rows): Coupler data is set aside in its own include file. No need to mingle it with, say, friction. Brake equipment is another obvious cluster, tho when you look a bit closer a few fall by the wayside -- some depend on the value of Mass() for their value. That means the rule is the data in any include file must stand on its own, it's values cannot depend on data found in another include file.

.wags are pretty simple. The data clusters around these concepts:

• Whatever the mesh defines, such as size().
  Spoiler

  	Type ( Freight )
  	FreightAnim ( USRA_50t_parts.s 1 1 1 )
  	Size ( 3.1m 4.6m 13.275m )
  	WheelRadius ( 36in/2 )
  	NumWheels ( 8 )
  	InertiaTensor ( Box ( 3.1m 4.6m 12.975m ) )
  	ORTSTrackGauge ( 4ft 8.5in )
  	ORTSRigidWheelBase ( 5ft 6in )

  
  
• Everything that depends on the value of Mass().
  Spoiler

  	Mass ( 18.144t )
  	Adheasion ( 0.2 0.4 2 0 )
  	DerailRailForce (  45.36t )
  	DerailBufferForce ( 370.61kN )	
  	MaxBrakeForce( 7.095kN)
  	MaxHandbrakeForce( 8.6kn )
  
  	Friction (
  		662N/m/s  0   1mph  2.89N/m/s  1.8
  		5.1N/rad/s  1  -1rad/s  0  1
  	)

  
  
• Couplers.
  Spoiler

  	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 )
  	)
  

  
  
• Brake gear.
  Spoiler

  	Comment ( "Single_Pipe_AB_Brakes.inc" )
  
  	BrakeEquipmentType ( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
  	BrakeSystemType ( "Air_single_pipe" )
  
  	NumberOfHandbrakeLeverSteps( 100 )
  
  	TripleValveRatio( 2.5 )
  	MaxReleaseRate( 20 )
  	MaxApplicationRate( 0.9 )
  	MaxAuxilaryChargingRate( 1.684 )
  	EmergencyResCapacity( 2.604 )
  	EmergencyResChargingRate( 1.684 )
  	EmergencyBrakeResMaxPressure( 90 )
  	BrakeCylinderPressureForMaxBrakeBrakeForce( 70 )

Using those logically categorized clusters one can reduce an average steam era / early diesel era US freight .wag from 55-60 lines to 11, a couple of which are blank.

Because there are variants of each (e.g., Type D and Type E couplers) there will be a number of include files for each type of cluster. ALL freight cars will use the same types of clustering for their specific include files.

I know nothing of freight cars outside of North America but per my professional background plus the analysis I've done on N.A. cars I am of the opinion that the clusters I've described above are very likely correct for most situations in most eras.
-----------

.engs are much more complex. In addition to the 4 listed above the very obvious clusters include:

• The instructions usually found at the bottom of the .eng file.
  Spoiler

  Comment ( 3dtrains_F7_V3_Text.inc ))
  
      Description (
   "3DTrains.com\n"+
   "Pro Series F-Unit v3.0d\n"+
   "____________________________\n\n"+
   "Physics: Bob Boudoin\n"+
   "____________________________\n\n"+
   "Copyright© 3DTrains.\n"+
   "All Rights Reserved."
       )
       EngineOperatingProcedures (
       "To move forward\n"+
   "1. Press the W key to move the Reverser to Forward.\n"+
   "2. Press the ; (SEMICOLON) key to release the train brakes.\n"+
   "3. Press the [ (LEFT BRACKET) key to release the locomotive brake.\n"+
  etc., etc.

  
  
• The various lights a locomotive caries.
  Spoiler

  Comment ( "3DTrains_FUnit_A_Lights_V3.inc" )
  
  	Lights ( 15
  		Light (
  			comment( Cone of Dim Light )
  			Type  ( 1 )
  			Conditions (
  				Headlight ( 2 )
  				Unit ( 2 )
  				Penalty ( 1 )
  			)
  			Cycle ( 0 )
  			FadeIn ( 0.5 )
  			FadeOut ( 0.5 )
  			States ( 1
  				State (
  					Duration ( 0.0 )
  					LightColour ( eff9ec95 )
  					Position ( 0.0 3.3 7.22 )
  					Transition ( 0 )
  					Radius ( 400.0 )
  					Angle ( 5.0 )
  				)
  			 )
  		)
  etc., etc.

  
  
• Data about the power it produces and engines that produce it.
  Spoiler

  Comment ( "F3A_Engine_Specs.inc" )
  
  	MaxPower ( 1119kW )
  	MaxForce ( 206.5kN ) 
  	MaxContinuousForce ( 177.9kN )
  	MaxVelocity ( 65mph )
  	MaxCurrent ( 1100A ) 
  	WheelRadius ( 20in )
  	Sanding ( 25mph )
  	NumWheels ( 4 )
  	MaxTemperature ( 120 )
  	MaxOilPressure ( 90 )
  
  	MaxDieselLevel ( 1200gal )
  	DieselUsedPerHourAtMaxPower ( 93.1gal )
  	DieselUsedPerHourAtIdle ( 3.2gal )
  
  	DieselEngineIdleRPM( 270 )
  	DieselEngineMaxRPM( 800 )
  	DieselEngineSpeedOfMaxTractiveEffort( 11mph )
  	DieselEngineMaxRPMChangeRate( 45 )

Only slightly more difficult to cluster are the data related to specific tasks or equipment found on the locomotive:

• Everything about Monitors.
  Spoiler

  	Comment ( SP_F3_Monitors.inc )
  
  	EmergencyStopMonitor(
  		MonitoringDeviceMonitorTimeLimit( 0 )
  		MonitoringDeviceAlarmTimeLimit( 0 )
  		MonitoringDevicePenaltyTimeLimit( 0 )
  		MonitoringDeviceCriticalLevel( 0 )
  		MonitoringDeviceResetLevel( 0 )
  		MonitoringDeviceAppliesFullBrake( 0 )
  		MonitoringDeviceAppliesEmergencyBrake( 1 )
  		MonitoringDeviceAppliesCutsPower( 0 )
  		MonitoringDeviceAppliesShutsDownEngine( 0 )
  	)
  
  	AWSMonitor(
  		MonitoringDeviceMonitorTimeLimit( -1 )
  		MonitoringDeviceAlarmTimeLimit( 5 )
  		MonitoringDevicePenaltyTimeLimit( 0 )
  		MonitoringDeviceCriticalLevel( 0 )
  		MonitoringDeviceResetLevel( 0 )
  		MonitoringDeviceAppliesFullBrake( 0 )
  		MonitoringDeviceAppliesEmergencyBrake( 1 )
  		MonitoringDeviceAppliesCutsPower( 0 )
  		MonitoringDeviceAppliesShutsDownEngine( 0 )
  	)
   

  
  
• The physical levers and various controls used by the Engineer that are found in the cab.
  Spoiler

   	Comment ( "SP_F3_Locomotive_Controllers.inc" )
  	EngineControllers (
  		Throttle ( 0 1 0.125 0
  			    NumNotches ( 9
  				Notch ( 0       0 Dummy )
  				Notch ( 0.125   0 Dummy )
  				Notch ( 0.25    0 Dummy )
  				Notch ( 0.375   0 Dummy )
  				Notch ( 0.5     0 Dummy )
  				Notch ( 0.625   0 Dummy )
  				Notch ( 0.75    0 Dummy )
  				Notch ( 0.875   0 Dummy )
  				Notch ( 1       0 Dummy )
  			)
  		)
  		Brake_Engine ( 0 1 0.0250 0 
  			NumNotches ( 1
  				Notch( 0  1 Dummy )
  			 )
  		)
  		Brake_Train ( 0 1 0.0125 0.65 
  			NumNotches ( 5
  				Notch( 0    0 TrainBrakesControllerReleaseStart )
  				Notch( 0.3  1 TrainBrakesControllerGraduatedSelfLapLimitedHoldingStart )
  				Notch( 0.85 0 TrainBrakesControllerSuppressionStart )
  				Notch( 0.9  0 TrainBrakesControllerContinuousServiceStart )
  				Notch( 0.95 0 TrainBrakesControllerEmergencyStart )
  			)
  		)
  		Brake_Dynamic ( 0 1 0.11 0 
  			NumNotches ( 10 
  				Notch ( 0       0 Dummy )
  				Notch ( 0.11    0 Dummy )
  				Notch ( 0.22    0 Dummy )
  				Notch ( 0.33    0 Dummy )
  				Notch ( 0.44    0 Dummy )
  				 Notch ( 0.55    0 Dummy )
  				Notch ( 0.66    0 Dummy )
  				Notch ( 0.77    0 Dummy )
  				Notch ( 0.88    0 Dummy )
  				Notch ( 1       0 Dummy )
  			 )
  		)
  		DirControl ( -1 0 1 1 )
  		BellToggle( 0 1 0 )
  		AWS ( 0 1 0 )
  		Sanding ( 0 1 0 )
  		Horn ( 0 1 0 )
  		Wipers ( 0 1 0 )
  		EmergencyStopResetToggle( 0 1 0 )
  		EmergencyStopToggle( 0 1 0 )
  		Vigilance ( 0 1 0 )
  		Headlights ( 0 0.25 1 0 )
  		BailOffButton( 0 1 0 )
  	)
  	DoesHornTriggerBell( 0 )
  

  
  
• Anything that enables the correct pressure in the train line.
  Spoiler

  	Comment ( "F3A-Air_Compressor.inc" )
  
   	AirBrakesAirCompressorPowerRating( 3.93 )
   	AirBrakesAirCompressorWattage( 15000 )
   	AirBrakesAirUsedPerPoundsOfBrakePipePressure( 1.4 )
   	AirBrakesCompressorRestartPressure( 132 )
   	AirBrakesIsCompressorElectricOrMechanical( 1 )
   	AirBrakesMainMaxAirPressure( 140 )
   	AirBrakesMainMinResAirPressure( 14.7 )
   	AirBrakesMainResVolume( 8.5 )

  
  
• What the brake controls really do.
  Spoiler

  Comment ( "Westinghouse_24RL_Brakestand_W_Dynamics.inc" ) 
  
   EngineBrakesControllerEmergencyApplicationRate( 8 )
   EngineBrakesControllerEmergencyBrakeTimePenalty( 60 )
   EngineBrakesControllerFullServicePressureDrop( 26 )
   EngineBrakesControllerHasProportionalBrake( 1 )
   EngineBrakesControllerMaxApplicationRate( 6 )
   EngineBrakesControllerMaxReleaseRate( 14 )
   EngineBrakesControllerMaxSystemPressure( 90 )
   EngineBrakesControllerMinPressureReduction( 6 )
   EngineBrakesControllerMinSystemPressure( 15 )
   EngineBrakesProportionalBrakeLag( 0.9 )
  
   TrainBrakesControllerEmergencyApplicationRate( 7 )
   TrainBrakesControllerEmergencyBrakeTimePenalty( 60 )
   TrainBrakesControllerFullServicePressureDrop( 26 )
   TrainBrakesControllerMaxApplicationRate( 5 )
   TrainBrakesControllerMaxReleaseRate( 3.4 )
   TrainBrakesControllerMaxSystemPressure( 90 )
   TrainBrakesControllerMinPressureReduction( 6 )
   TrainBrakesControllerMinSystemPressure( 15 )
  
   DynamicBrakeHasAutoBailOff ( 0 )
   DynamicBrakesCutInSpeed( 5 )
   DynamicBrakesDelayTimeBeforeEngaging ( 10 )
   DynamicBrakesEffectAtMaximumFadeOut( 0 )
   DynamicBrakesFadingSpeed( 17 )
   DynamicBrakesHigherSpeedCurveExponent( 9.2 )
   DynamicBrakesLowerSpeedCurveExponent( 1.55 )
   DynamicBrakesMaxAirBrakePressure ( 50 )
   DynamicBrakesMaximumEffectiveSpeed( 23 )
   DynamicBrakesMaximumForce( 115.5kN )
   DynamicBrakesMaximumSpeedForFadeOut ( 325 )
   DynamicBrakesMinUsableSpeed( 3.0 )
   DynamicBrakesNumberOfControllerNotches( 1 )
   DynamicBrakesResistorCurrentLimit ( 600 )
  
   BrakesEngineBrakeType ( "Air_single_pipe"  )
   BrakesTrainBrakeType ( "Air_single_pipe" )
   BrakesEngineControllers( "Independent, Train, Dynamic" )
          
   EngineBrakesControllerDirectControlExponent( 1 )
  

Using those logically categorized clusters one can reduce an average steam era / early diesel era US locomotive .eng from 800+ lines to around 60, a couple of which are blank.

Again, expressing my professional opinion, the data naturally groups into these clusters. Of course there is room for refinement; Perhaps the data about notched brake handle movement really belongs with the performance data of the brake system in stead of where I have it now, with the notched throttle data. But i think overall further changes are a the margins of the task. What does remain as entirely subjective are the names I've given the include files... and to a lesser degree where I've stored them. I can cover both of those maters later if anyone wants to review and discuss what I'm fiddling around with.

I think if you were to take any .wag or .eng from any country or era you'd find it's lines of data would move quite comfortably into the clusters I've identified. The actual parameter names and values could be quite different but I believe the natural group of that data should conform as I've described above.

Last point: Why these clusters and not fewer? Or More? The answer is everything in each cluster is obviously related to all of the other data and none is dependent upon data from another cluster. The analogy is atoms and not compounds or particles.

[Genma Saotome]

Just a f.y.i., if you want to use the show/hide feature I used in the post above all you need to do is manually type the word spoiler inside of these two characters [], then the "peekaboo" text, followed by /spoiler again inside of these two characters [].

It helps with long code lists.

For what I did above, I did spoiler, color=black, code followed by the lines taken from a .eng or .wag and finished with \code, \color, and \spoiler -- each command inside its own []pair.

My use of the color command might be optional... it seems to matter for me but I'm not sure it matters for everyone. Perhaps it has something to do w/ my text editor.

[Goku]

For me, intense use of 'include' is not good idea. It dramatically slows loading speed due to more files and much more complex parser.
Millions of files and complicated loading is not a way to good game engine.
I know that 'includes' helps in creating content, but content is created once and used many times. So better focus on the second thing.

[Jovet]

Goku, on 04 March 2016 - 03:08 PM, said:

For me, intense use of 'include' is not good idea. It dramatically slows loading speed due to more files and much more complex parser.
Millions of files and complicated loading is not a way to good game engine.
I know that 'includes' helps in creating content, but content is created once and used many times. So better focus on the second thing.

I must disagree. I think it's a great idea. I wish I had heard of it sooner!

The main reason being that managing hundreds or thousands of separate files is a daunting task. If one wants to tweak or change, say, braking parameters on on set or even all wagons/cars, that is a lot of work. But if the parameters are modular, then only one file needs changed and all of the wagons/cars are instantly changed. It's also significantly simpler to manage similarly-related but diverging parameters, such as Dave outlined.

A good game engine doesn't need to load millions of files. It only needs to load the ones that are appropriate. The delay in loading a few extra files is negligible on today's systems, and certainly is a non-issue compared to the loading of, say, a world file and its components. Additionaly, I would think very few people are going to have millions of Include files in their installations. It would kind-of defeat the purpose.

[Genma Saotome]

jovet, on 04 March 2016 - 04:23 PM, said:

A good game engine doesn't need to load millions of files. It only needs to load the ones that are appropriate.

I expect if the number of include files is perceived as a problem the Loader software could keep track of the files it has read in that cycle and avoid reading something more than once. Given the vast amount of duplication present its arguable that performance could be improved from the use of inckude files, not degraded.

But there is a valid point in Guku's criticism: The include file idea can be applied to excess. Any model which is a one-of (which, due to uncertain heritage of so many models is likely a lot of models) should not have their .eng or .wag changed to use any include files that are not almost uniformly applied are good -- stuff like couplers and brake equipment -- but the others... weight or mesh related data there would be no benefit in having those. They're work to set up and the marginal gain for one .wag file is slim to none. So in that situation more is not better.

One more thought on that if I may; I've long believed all .wags and .engs should be the empty version with the value of the lading held elsewhere, .con file or one of the activity files. Doing so would produce the circumstances whereby all loaded .wag files could be deleted. Want to use a model? Read one .wag file always.