Kicking around some ideas, part 1

[muskokaandtahoe]

One aspect of every project is coming up with fresh ways to look at old, familiar issues. This thread (and another later on) is an attempt to ask the wider community for some ideas to raise for consideration by the Open Rails team -- consideration; not a commitment. Please keep that in mind.

The topic of this thread will be about freight and passenger cars -- both models and .wags... and to be clear, some ideas might be limited to Open Rails models and .wags, others only about MSTS models & their .wags. IOW think broadly.

I'll start with some thoughts I've shared with some of the Open Rails team; Please provide some feedback them and then chip in with ideas of your own.

[muskokaandtahoe]

First idea to kick around has to do with couplers: Don't model them with the rest of the car, put them in their own model, one for the A end, another for the B end. Create something equivalent to a .wag file for them. Here is why it might be a good idea:

(1) Couplers move per the push and pull action of the train. North American couplers can be pushed inwards towards the center of the car 5-8cm (2-3 inches). They can be pulled out about the same distance. Modeling them as stand-alone models would allow the Open Rails software to represent this movement.

Imagine for a moment that a car has started to move. Watching the trailing coupler, attached to the much heavier remainder of the train, we see it stationary while it's car is slowly pulling away; the limit is reached and it begins to move with its car, slowly pulling out the coupler of the next car... until that couplers limit is reached and its car begins to move. Repeat down the length of a 50-80 car long train. The Locomotive may move 10m before the last car starts to move. It's very hard to represent that in full when the coupler is modeled as a stationary element of each car.

(2) A pair of coupler models with its corresponding ".wag" file -- call it a .cplr file, could contain the coupler strength and buffer resistance forces that are repeated over and over again in each .wag file. Perhaps only a handful of .cplr files would be needed. Maintaining them would be very easy.

(3) Making note of .cplr files in within a .com file would be too much of a bother so instead stick put the note into the cars own .sd file (e.g., Coupler ( Type_E.cplr ) ).
were freely available to be referenced by all. People could then focus their own modeling efforts on the more straightforward elements of a car.

(5) Not sure anyone would bother, but standalone coupler models could be animated... use of a cut lever to uncouple (w/airhose movement & sound) and who knows, maybe even modeling the closure of the knuckle when coupling.

Any opinions on that? Other ideas you have?

[danthecpman]

Instead of calling the .cplr file in the .sd file, why not in the .wag file, it makes more sense to call it from the .wag file. Also the placement should be in the definition line as well (e.g., frontcoupler ( Type_E.cplr 4.28 ) ). The 4.28 being the distance from the center of the car, note that I used "frontcoupler" so that you could have different couplers on each end of the car (e.g., draw-bar connected well cars).

[muskokaandtahoe]

All good points.

Representing it then in full MSTS notation, something like this:
Couplers (
Front (
Type ( Knuckle )
File ( a file name )
Location (4.28 )
)
Rear (
Type ( Bar )
File ( a different file name )
Location ( -4.28 )
)

With "a file name" and "a different file name" containing all the relevant performance data and being shared by many, many .wags and .engs.

[danthecpman]

Yes Dave, that is exactly what I had in mind (looks cleaner that my example). Obviously, I would make it optional so old stock would still work . The type, (bar, chain, automatic...) I think could be stored in the .cplr file instead of in the wag/eng file.

So a .cplr file might look a bit like this:

Coupler ( Type_a
shape ( "name of shape.s" )
slackdistance ( 0.125m ) ##unsure what the technical term for this is
spring ( 1.5*10e5kN )
damp ( iv'e-no-idea-what-the-units-for-this-would-be )
type ( automatic ) ##chain, knuckle, bar... are valid for use
strength ( 5.2*10e15kN )
)

[muskokaandtahoe]

Yes Dave, that is exactly what I had in mind (looks cleaner that my example). Obviously, I would make it optional so old stock would still work . The type, (bar, chain, automatic...) I think could be stored in the .cplr file instead of in the wag/eng file.

So a .cplr file might look a bit like this:

Coupler ( Type_a
shape ( "name of shape.s" )
slackdistance ( 0.125m ) ##unsure what the technical term for this is
spring ( 1.5*10e5kN )
damp ( iv'e-no-idea-what-the-units-for-this-would-be )
type ( automatic ) ##chain, knuckle, bar... are valid for use
strength ( 5.2*10e15kN )
)

Buff forces are the compression force that occurs in the train (i.e., from braking and/or ordinary down grade movement) and Draft forces are the opposite. AFAIK, what MSTS does with the coupler() data is to represent the limits the equipment can take in Draft and whats in Buffers() does the same for Buff forces.

On the diagrams of North American cars that I've seen (almost all steam to early diesel era) the Buffer equipment is a couple of feet away from each coupler, inside the center sill. Might be springs, might be some sort of resistance gear. The coupler itself is pinned at a hinge to the coupler yoke -- that allows the coupler to swing left and right -- and the yoke itself is the equipment where all movement is constrained: buff forces will move the yoke against the resistance springs and draft forces are limited by a large slot-pin that passes thru the yoke (it looks to be about 2x6 and crosses the centersill side to side). The slot itself is about 12" long, meaning the yoke can move 3" in forwards with draft or 3" backwards with buff. I would imagine that cushioned underframes allow for greater movement and perhaps greater buffer capability but I don't know much about them.

[kraus]

An alternate implementation would use named sub-objects in the shape file similar to how wheels and bogies are animated based on name. This maintains compatability with MSTS since shapes that include these named sub-objects will also work with MSTS and no changes would be needed in the wagon or engine files.

[Erick_Cantu]

I think a better way of animating couplers would be akin to suspension in MSFS (since they're about the same thing).

You set tolerances in the physics.

You animate the coupler extended at frame 0 and compressed at frame 100. You would ensure your animation matches what the physics says as close as possible.

The coupler would be linked to a second animation done like the steering on an aeroplane in FS (once again, same concept). Frame 0 and 100 would end up looking the same, but in between a 360° rotation would take place. Whether it's clockwise or anticlockwise is arbitrary (in FS I think it's clockwise viewed from top, but I am not sure). The sim would know that this animation is a full circle, and would rotate the coupler as required to keep it aligned with a point exactly centered between the rails (best place, then all couplers match). We know the sim knows where this point is, that's how it keeps the trucks and body in the right place on curves.

Having a separate model and configuration file, like the RailWorks system, is cumbersome and an additional layer of complexity that really shouldn't be necessary.

Perhaps the better way of putting it is this: for any given feature, find out how it's done in RailWorks, and then do the exact opposite, you'll probably set a model of efficiency.

[muskokaandtahoe]

Jeffery: Yeah, that would work too.

OTOH, a completely different, more radical approach would be to split up cars models into several component elements: couplers, trucks w/ wheels, car body, and everything else. You spec the "assembly" within the .sd (or .wag). For the most part, car body is always unique because the texture is unique, so within the software that has to be loaded into VRAM uniquely. But a lot of the rest of the stuff can often, if not almost always, be shared across many cars and that can mean loading it only once. It could result in much better performance.

I don't know if one could pull off the same thing using just names. And full disclosure, nor do I know if something as radical as this would result in a big enough performance change to warrant the suggestion.

[mestevet]

I've been digging around to find the source of this, but I thought that I've seen "Coupler" on the list of originally "reserved names" for MSTS parts (like Bogies, Wheels, Wipers, etc), but that were just never implemented.

I agree with the basic concept that Dave is discussing though, some method for allowing the animation of coupler draft gear action would be desirable.

Some additional thoughts...

Allow for cushion underframes, where the motion of the coupler could be significant, with damping for lower shock forces on the car

Allow for both body mounted and truck mounted couplers (in model railroading, they'd refer to these as "talgo" types, don't know if that's a real railroading term or not). In the case of truck mounted couplers, they'd have to pivot about the center of the truck's pivot. I don't know if that would throw a monkey wrench into making them separate parts or not.

I see the advantage to having the couplers be separate parts, so that there could be a common library of coupler models to use though.

Steve

[GaryG]

Don't forget about the cushion underframe cars where the couplers are more or less rigidly connected to a moveable centre sill that is connected to the carbody by a damping mechanism. These cars can have almost one foot of coupler/sill movement before the body and wheels of the car might start rolling if the car is heavily loaded and accelerated rapidly as in a slack run in or out.

GaryG

[muskokaandtahoe]

Having a separate model and configuration file, like the RailWorks system, is cumbersome and an additional layer of complexity that really shouldn't be necessary.

I dunno that it is worse than having duplicated coupler() values in each and every .wag. Changing those over the years as more an more was understood was a real PITA. And I think a simple reference to the file, as we've seen in previous posts, is pretty trivial step, no more a burden than adding a freight animation line.

The other value in making them a separate model is having a small library of acceptable quality models (especially if they have any animation in them) is that they may be enough incentive for people who otherwise would not try to get started on creating a few cars as now they don't have to model one of the more difficult features.

[longiron]

What about using something that already exists - aliasing? That way there needs to be only one coupler model, texture and definition for each coupler in the entire installation. The WAG would just point to the coupler to be used.

[muskokaandtahoe]

Chris, are you saying model one coupler and then when used, it goes on which ever end is correct (i.e., lets say the "standard" is to build the model for the leading end)... then the program "makes a copy", flips around the data, and uses the flipped data at the other end?

If so, that would take care of the vast majority of cases but OR would also have to accommodate those situations described in post #3, above.

It could look like this:
Coupler ( Both
Filename ( xyz.s ) <---that could alternatively be xyz.cplr if that makes more sense
Location ( 4.28 )
)

and then the variant:
Coupler ( Lead
Filename ( abc.s ) <---that could alternatively be abc.cplr if that makes more sense
Location ( 4.28 )
)
Coupler ( Trailing
Filename ( def.s ) <---that could alternatively be def.cplr if that makes more sense
Location ( -4.28 )
)

[Erick_Cantu]

Yes, but picture this readme:

"xyz.cplr" and "abc.truk" required to run this equipment.

Then both files go missing from where they're supposed to be hosted. It's bad enough when it happens to sounds and cabs. This is just another layer of things you have to replace when they inevitably turn up unavailable (and they will).

Open Rails would have a reputation as a sim where you have to track down component parts to run anything.

Another (unrelated) idea would be the use of XML coding in the model. No scripts taking up space and overcomplicating things, you have an XML file - that the export modules read - where you store part names and their associated XML code, when you name an animated part, if its name is in this file, the appropriate XML is coded into the model as the model exports. No mess, no fuss, it just works. Configure the animation once and use it whenever you need to.