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