[Genma Saotome]

Just to share what I'm fiddling with for .wags.

Here is the new .wag file -- just 25 lines:

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

Wagon ( xm_atsf_142331_mt

	Include ( XM_ATSF_142331_Mesh_Dimensions.inc )
	Include ( ..\\fleet_stds\\Std_Type_Coupler_Generic_Draft_Gear.inc )

	Adheasion ( 0.2 0.4 2 0 )
	DerailRailHeight ( 5cm )

	Mass ( 21.45t )	
	DerailRailForce (  48.6486t )	
	DerailBufferForce ( 373.7216kn )	
	MaxBrakeForce( 7.095kN )
	MaxHandbrakeForce( 8.6kN	 )
	Friction (
		820N/m/s   -0.260   5.690mph  5.10N/m/s  1.59
		5.1N/rad/s  1   -1rad/s   0   1
	 )

	Include ( ..\\fleet_stds\\Single_Pipe_AB_Brakes.inc )

	Sound ( "genfreightwag1.sms" )
	Name ("XM 40' ATSF 142331 MT")
)

Reading the file, the first Include() is about the physical features of the model:

	Comment ( XM_ATSF_142331_Mesh_Dimensions.inc )

	Type ( Freight )
	WagonShape ( SF142331.s )
	Size ( 3.1m 4.6m 13.2m )
	InertiaTensor ( Box (3.1m 4.6m 12.9m) )
	NumWheels ( 8 )
	WheelRadius ( 33in/2 )

That include file is stored with the .s file; That location makes sense to me because if I make several versions of this car (mty vs. loaded) this data would apply to each one.



The second Include() is about the couplers:

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

Because that data is constant for all of my late steam era freight cars I've placed it in a special folder I've called "Fleet_STDS". Using the relative path construct of "..\\fleet_stds\\" tells the OR software to go up one level in the directory tree and find a folder called "Fleet_STDS". This include file is there. Sticking into "Fleet_STDS" means all other .wag files can point there too, meaning I'll have just one set of coupler data for the whole fleet.



Next two lines are orphans right now... as I'm not sure where Adhesion() and DeRailHeight() could go if there were moved into an include file.

Mass() is something that could vary across different versions of this car... mty vs loaded for instance and so IMO it makes sense to keep it in the .wag.

The next 8 lines have values all determined by the value of Mass() and so they're here too. IMO none of those lines should be in any part of a .wag... I'm of the opinion that all of them should be computed by the OR software when the .wag is being read.


The final Include() is for the brake line and brake equipment:

	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( 1.86 )
	MaxApplicationRate( 0.9 )
	MaxAuxilaryChargingRate( 1.684 )
	EmergencyResCapacity( 2.604 )
	EmergencyResChargingRate( 1.684 )
	EmergencyBrakeResMaxPressure( 90 )
	BrakeCylinderPressureForMaxBrakeBrakeForce( 50 )

Like the coupler file this too is placed into my "Fleet_STDS" folder as the values are all constants for the late steam era.

If this car had lights -- a FRED, or an interior (e.g., a caboose) I'd move the data into Include files so they could be shared over several versions.


The file finishes by identifying a sound file and naming the .wag. IF the OR software ever allows us to put new descriptive data into the .wags (e.g., Car Initial, Car Number, etc. etc.) then I'd probably move all of that, plus the name line, into an Include() file so it could be shared across other versions of this car. In that case it would properly go into the car folder itself.

[markus_GE]

If such a system could be generically applied (IE, commonly agreed on using it), the world of ORTS trainsimming would become a wholly new one. Indeed, thi looks like a promising concept :sign_thanks:

The only thing I fear is that at one point people will start to distribute ENGs and WAGs with includes in them, which can

a) lead to confusion if the necessary include files are not distributed with them
:whistling: mess up a TRAINSET folder even more, if no more or less common file structure for general include files is used.
c) make your fleet harder to maintain again, with all the different includes cris-crossing throught the whole TRAINSET folder.

Don´t get me wrong, I really think this is a promising idea, but I think there are a few points (not only those I mentioned now) that should be given some attention, in order to keep one´s TRAINSET folder workable for you as its maintainer.

Cheers, Markus

[Genma Saotome]

markus_GE, on 24 June 2014 - 01:03 AM, said:

If such a system could be generically applied (IE, commonly agreed on using it), the world of ORTS trainsimming would become a wholly new one. Indeed, thi looks like a promising concept :p

The only thing I fear is that at one point people will start to distribute ENGs and WAGs with includes in them, which can

1) lead to confusion if the necessary include files are not distributed with them
2) mess up a TRAINSET folder even more, if no more or less common file structure for general include files is used.
3) make your fleet harder to maintain again, with all the different includes cris-crossing throught the whole TRAINSET folder.

It's really no different that being sure to provide a cabview folder with a locomotive.

Here are the two big problems as I see them:

• It is awkward to maintain both MSTS and OR versions of a .wag
  
• The inability of consist files to make use of an absolute path prevents use of an organized, central library

You'd think the first problem should be temporary but it's not. You have to have a non-include() version to run MSTS, AE, and RE. If you don't those programs will throw lots of errors. And you don't want an OR name and a MSTS name for the same car because then your consist files are no good. So you have to have both MSTS and OR \trainsets.


The second problem is about solving what happens when you have many different installations of routes with each one having rather unique requirements for rolling stock. Assume you have one setup for US Narrow Gauge routes, two for Steam Era, two for Traction, and two for Modern. Clearly your rolling stock requirements are going to be different for the Narrow Gauge and Modern routes, and your engine roster could be unique for all 7 installs... so with that logic all 7 \trainsets are unique up to this point. But moving beyond that you could have 100% commonality for freight cars for both steam era setups as well as the two traction setups. Those four \trainsets now should have an aidentical set of many .wags. As things are right now you have to copy all those .wags to all four places. Disk being cheap, that's no big deal... but administratively speaking you now have a lot of duplication and extra manual work whenever you edit or add something new.

IMO it would be far, far better to see loose consists defined in a .con file and let .con files have an absolute path pointed to one "official" library where one set of all of those .wags existed. I'm experimenting with this idea of a central library... looks like this:



All of my editing is done on files in those folders and then, because there is no pathing allowed in consist files, the folders get copied and pasted into the many different \Trainset folders. IMO that is not only a bother, it shouldn't be necessary.

[markus_GE]

I ike the idea of a central library, but I´m still concerned with the manageability of files that come with includes. Or not about the files, but how they will mess with such a central library, unless there´s some sort of convention on how to do thing there.

Cheers, Markus

[Lindsayts]

markus_GE, on 24 June 2014 - 01:03 AM, said:

If such a system could be generically applied (IE, commonly agreed on using it), the world of ORTS trainsimming would become a wholly new one. Indeed, thi looks like a promising concept :sign_rockon:

The only thing I fear is that at one point people will start to distribute ENGs and WAGs with includes in them, which can

a) lead to confusion if the necessary include files are not distributed with them
B) mess up a TRAINSET folder even more, if no more or less common file structure for general include files is used.
c) make your fleet harder to maintain again, with all the different includes cris-crossing throught the whole TRAINSET folder.

Don´t get me wrong, I really think this is a promising idea, but I think there are a few points (not only those I mentioned now) that should be given some attention, in order to keep one´s TRAINSET folder workable for you as its maintainer.

Cheers, Markus

This probably will not be a serious issue, the number of people capable of doing such detailed work as this on eng files is VERY low. MY idea is to release a "template" eng file with the includes and its almost certain such a template will be modified to suit individual machines by the machines developers. Any new includes like new brake or power systems is likely to be done by the same small group and therefore follow the same directory structure.

One the major reasons for my work on this is to make it easier for most people (including this writer) that find eng files confusing.

Lindsay

[markus_GE]

That´s a positive aspect, of course. But seeing as many people are able to understand English, which is about the only requirement to tinker with ENG files, and it is not hard to move a section of text to a new file, I´m not totally convinced still.

Anyway, :sign_rockon: for all your input and work, and especially with the latter, I´m sure we´re once going to see who had the better points about it. May the results be whatever will turn out, there´s a concept in physics-science known as entropy, which, among other things, includes the "law" that every system in the world tends to get chaotic over time, so maybe I just got something wrong there B)

Cheers, Markus

[Lindsayts]

markus_GE, on 24 June 2014 - 11:50 AM, said:

That´s a positive aspect, of course. But seeing as many people are able to understand English, which is about the only requirement to tinker with ENG files, and it is not hard to move a section of text to a new file, I´m not totally convinced still.

Cheers, Markus

Its actually not quite that simple, so one does a good bit of persistance. The reason is an eng file is NOT free form text but does have a good deal of structure and the parser does not really give meaningfull error messages when this structure is upset.

Lindsay :sign_rockon:.

[markus_GE]

True on the one hand, but with a little bit of a clue, one moves the right section with the right brackets and in another files replaces that right section with an include and it´s done. Also, there are so many tutorials on ENG file fiddling, it can´t be hard to learn.

Just in case (I know, nobody has said anything about it), I´m definitely not wanting nor trying to break loose a quarrel. I´m just trying to describe my concerns. This line is just to calm myself down, as I´m getting worried because usually I don´t have so much to say about what I think. I usually get covered with arguments proving me wrong right in the beginning :sign_rockon:

Cheers, Markus

[Genma Saotome]

markus_GE, on 24 June 2014 - 11:50 AM, said:

That´s a positive aspect, of course. But seeing as many people are able to understand English, which is about the only requirement to tinker with ENG files, and it is not hard to move a section of text to a new file, I´m not totally convinced still.

True enough if all you have is copy to another .wag in the same directory.

But what when there are six or seven such directories? Are you sure you will always get to all of them?

As I've said on other occasions, for each new .wag I download I delete almost every line and replace the values w/ my own. The dimensional data stays around... everything else gets tossed. And so being able to use two lines to say include my standard brake and standard coupler data goes a long way to both simplifying the .wag file but also ensures I don't miss something with a copy / paste.

Now that I'm once again looking at these files I see this one doesn't have the right coupler data... it's one or two versions back, that one doesn't have the correct MaxBrakeForce() -- once again, it ought to be computed by the software, not input by me. Is that brake equipment data correct or old? Did I update the InternalTensor() value for each .wag in this directory? I don't want to mess with that stuff anymore. One fleet-wide brake equipment include file, one fleet-wide coupler include file, and a car folder file for dimensions... and I'm ok. If the software did the weight based calculations my .wags would just be 16 lines long:

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

Wagon ( xm_gn_25096_MT

	WagonShape ( GN_USRA_box_25096.s )

	Include ( "..//fleet_stds/XM_USRA_DS_Mesh_Dimensions.inc" )
	Include ( "..//fleet_stds/Std_Type_Coupler_Generic_Draft_Gear.inc" )

	Adheasion ( 0.2 0.4 2 0 )

	Include ( "..//fleet_stds/Single Pipe AB Brakes" )

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

And in some cases I could move out both WagonShape() and Adheasion() so the total for each .wag would be 11 lines. What's not to like?

[markus_GE]

It´s not about the inc´s in general - as I´ve said, I welcome the idea myself. I really welcome it, even if it will probably make my DPU program obsolete some time.

My concern is how there use will fit in with distributed assets, made by somebody who doesn´t know how I have set up my central library. Will it make or break things?

Everything is fine as long as no distribution of said files happens. But that is unlikely to no happen.

I say it again, long live the includes, even if they will likely once make the half-year efforts I already put into DPU obsolete.

Cheers, Markus

[Genma Saotome]

markus_GE, on 24 June 2014 - 01:44 PM, said:

It´s not about the inc´s in general - as I´ve said, I welcome the idea myself. I really welcome it, even if it will probably make my DPU program obsolete some time.

My concern is how there use will fit in with distributed assets, made by somebody who doesn´t know how I have set up my central library. Will it make or break things?

Everything is fine as long as no distribution of said files happens. But that is unlikely to no happen.

I say it again, long live the includes, even if they will likely once make the half-year efforts I already put into DPU obsolete.

Cheers, Markus

Two issues then. The first is distributing the files, as of today: We're I to zip up the stuff I've made and send it you you'd get a archive w/ two directories in it... one called "Fleet_Stds" and the other something like XM_MILW_702584_MT. You'd install both into \Trainsets. No problem there. Now if all sorts of people are doing the same thing and they're distributing "Fleet Stds" and I'm doing "Fleet_Stds" and you're doing "Markus_Stds", etc. etc., we don't have any more of a mess to straighten out than we do now w/ directory names: You either accept them as they are or take a few minutes to edit the name to conform to your own preferences. Do you always accept whatever someone else has put into Name()? The folder name? The .wag name? I don't. All three get renamed (multiple reasons but one is that it tells me I have replaced the contents of the .wag file and so it is "safe" to use).

The other issue remains hypothetical: If .con files had an absolute path on each WagonData() line AND I sent you a .con file you'd have to look at those paths and see if they conformed to your own set up. Obviously if you and I followed the same definition of that standardized library the only thing that would need checking would be the disk drive. OTOH if we had rather different ideas about how that library is organized then you'd have to replace my path with yours on each line of the .con file. Certainly a bother... one reason why I think mnemonics should be used -- you'd change far fewer lines. Obviously it would be best if the structure of this hypothetical library was standardized... but that is for some other thread... and even if there was general agreement on the idea there's getting it implemented in code too. IOW, very hypothetical.

[markus_GE]

I have proposed the standardization / common agreement thing already. I still like the idea, though I know it´s unlikely to happen.

But, good point by you (and you´ll probably get me to shut up with it now :) ) I somehow had a roadblock (thoughtblock?) that kept me from seeing I´m already doing all this customization stuff myself. So, Be it named differently what you hypothetically would send me, I could just adopt it. But, it would still require me to switch out include files, should those provided not conform. And that could become a real PITA, IMHO, with everyone using different setups, how the contents of an ENG file are to be distributed over various INCs.

It has also already been discussed to standardize / make a common agreement on these. Making a standard INC library to work with any TRAINSET folder, no matter what it looks like, by simply hard-linking the library would already make things easier. Add mnemonics to it, optionally, and the hardlinking wouldn´t even be required. Inside the library, all necessary INCs (except for those that are only specific to a certain folder of cars) can be found and simply found, swapped and changed. However, there would have to be more or less common practice on what to put in which INC, in order to make swapping easy.

The advantage of an INC library detached from the TRAINSET is, that it works with almost any TRAINSET configuration, given that absolute paths are allowed in file includes. And, one can easily change the setup for any car, at least with the global files. Disadvantage? Well, nothing really. As said, some editing upon installing things will always be (and has always been) required, but one could try and keep it down.

Hope the above makes some sort of sense. Nervousness about graduation in two days is slowly growing :crazy:

Cheers, Markus