Elvas Tower: A Include() example w/ .wags - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

A Include() example w/ .wags

#1 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 23 June 2014 - 05:56 PM

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.

#2 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,502
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:MSTS / ORTS
  • Country:

Posted 24 June 2014 - 01:03 AM

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

#3 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 24 June 2014 - 09:58 AM

View Postmarkus_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:

Attached Image: Rolling Stock Library.jpg

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.

#4 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,502
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:MSTS / ORTS
  • Country:

Posted 24 June 2014 - 11:38 AM

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

#5 User is offline   Lindsayts 

  • Superintendant
  • Group: Elite Member
  • Posts: 1,827
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 24 June 2014 - 11:40 AM

View Postmarkus_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

#6 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,502
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:MSTS / ORTS
  • Country:

Posted 24 June 2014 - 11:50 AM

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

#7 User is offline   Lindsayts 

  • Superintendant
  • Group: Elite Member
  • Posts: 1,827
  • Joined: 25-November 11
  • Gender:Male
  • Country:

Posted 24 June 2014 - 12:17 PM

View Postmarkus_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:.

#8 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,502
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:MSTS / ORTS
  • Country:

Posted 24 June 2014 - 12:51 PM

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

#9 User is offline   Genma Saotome 

  • Owner and Admin
  • PipPipPipPipPipPipPipPipPipPipPip
  • Group: Owner
  • Posts: 12,709
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 24 June 2014 - 01:19 PM

View Postmarkus_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?

#10 User is offline   markus_GE 

  • Executive Vice President
  • PipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 4,502
  • Joined: 07-February 13
  • Gender:Male
  • Location:Leoben, Styria, Austria, Europe
  • Simulator:MSTS / ORTS
  • Country:

Posted 24 June 2014 - 01:44 PM

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

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users