Deciphering the .eng file, inertia tensor, etc

LAST EDITED ON Jun-15-03 AT 00:25 AM (EDT)

This should be subtitled "Yo Bob!", since I tried to email Bob and I'm getting that "no such user" message again. I forget, does that mean six more weeks of winter, or the forum server is gonna crash again?
Anyway, anybody else can toss their two cents in.Hey, Bob.I've finally gotten disgusted with the sim randomly locking up when I use the front coupler for switching, and I'm currently trying to hack for a crashproof switcher. It looked like I had one at one time, using part of your physics 4.5, combined with fixing the size box to hit the middle of the couplers, and the ESD bounding box exactly even plus and minus, and both length values exactly half the size value. Got some bouncing couplers on curves tho, and attempting to fix those I got the lockups back again. It's a truly random thing, sometimes don't kick in until you hit escape to end the activity, and of course different cars (I'm trying to come up with an ENGINE that will eliminate the lockup independently of the incorrect car values, so I'm currently using nothing but default unmodified 5/7/2001 KUJU cars) also trigger the bug more or less often.Some conclusions,
The front coupler does not engage by hitting the car while moving forward, it actually engages when you hit it hard enough to rebound, and the engine is moving backwards at +1m/s. That's why it takes such slow creeping to back away after uncoupling, the whole couple/uncouple subroutine is geared toward the back coupler, and the front coupler works the exact opposite way. To couple on, you only need to get the front coupler within the proximity boundary of the other coupler, then back away quickly enough to meet the proximity + movement direction + speed used for the back coupler. To uncouple, since it's using backwards movement for coupling, you need to back up slowly enough to avoid recoupling. You can duplicate the conditions with the back coupler, if you creep backwards and touch the car behind at less than 1m/s (takes some patience), once in contact you can push backwards for all you're worth and it won't couple. Shift to forward, pop it into notch 8, and accelerate away from the car like a dragster, the back coupler won't engage cuz you're moving the wrong direction. One item I'm currently looking at is the velocity line, I think that is what defines the actual coupling speed, so if that was raised to a higher value the uncoupling problem would be solved, just have to hit it a little harder. Trick is finding a balance between coupling on and uncoupling.Anyway, in all this I've been searching the loco design forum, the documentation for BBoxedit, the MSTS techdocs, and Richter's engine manual, but there are a lot of things that need to be explained in plain English, and also my trial & error testing has shown that there's a hell of a lot of misinformation and things that are just plain wrong stated as absolute facts. So I was thinking, possibly it's time for someone to compile the true facts, translate into plain English, and publish/upload an engine manual for dummies. That someone might be you? Hint hint? Maybe if we all understood exactly what the hell all these things in the .eng files actually did, we could find some way around the *&^%$#! buggy front coupler problems.From the techdocs (there's 2 on this, they appear identical at first glance, this is from v2)
"Size: Width (across the tracks), height and length (along the tracks) of the wagon in meters, in that order. The length figure excludes the length of the couplings and must be greater than or equal to the bounding box length. The bounding box length is specified in the wagon shapes corresponding .sd file."Okay, the size is what it actually collides with, what does the bounding box do? If size excludes the length of the couplings, then the visual coupling would have no space between cars, and most of them have the actual size & bounding box extending beyond the car to somewhere on the coupler, in apparent contradiction to that statement."InertiaTensor A box used to calculate an inertia tensor for the wagon. An inertia tensor describes the mass distribution of an object to the physics system. The dimensions of this box are therefore important to the physical behaviour of a wagon. The format is “Box” followed by width, height and length in meters, encased in parentheses e.g.
InertiaTensor ( Box (3m 3.5m 17.7m) )
These values should be the same as the Size values."If it should be the same as the size values, why have a seperate entry? Why not use the size dimensions for the physics? Van den Hoven says making the inertia tensor box bigger than the size cuts down on bouncing for sharp curves, don't work for me. Some say it should be the same size or smaller, but what exactly is the effect of changing the inertia tensor? If that bit in the techdocs about making it the exact same size as the size box is not true gospel, is there a formula for calculating effects with different ratios?The r0 (20cm 30cm),"r0 - The first value in here describes the rest length of the spring. The second indicates the length at which the second set of values kicks in.
Coupling springs work in compression as well as extension."Hmmm, WHAT second set of values? Stiffness & damping, maybe? They don't say. Let's take a look;"Spring – a sub-section of the coupling section that defines the physical parameters of the coupling. Springs in train have 2 different extension dependent sets of characteristics. This is so that for example the initial extension of the coupling can be mimicked with relatively low numbers using the first set of values until the extension reaches what in reality would be the maximum coupling extension and hence the much larger second set of values would kick in to mimic this.
Stiffness – 2 values in Newton Meters giving the stiffness of the coupling over the first and second extension stages.
Damping – 2 values in Newton Meters per Second giving the damping factor of the coupling over the first and second extension stages.
Break – 2 values in Newtons giving the force at which the coupling will break in the first and second stage. Generally these values will both be the same and will lie somewhere in the second stage of extension."Ok, so maybe the r0 first number is the at-rest, as in how far the coupler sticks out beyond the size box when there's nothing pushing or pulling on it. So that would be the first set of values, but with nothing pushing/pulling ("rest length"), the net newtonian physics acting on it would be zero. Unless they mean that the shoving & yanking starts it uses the first set of numbers, and waits until the spring is pulled to the extension of the second r0 number (and possibly compressed to the second number, "Coupling springs work in compression as well as extension.") before the second set of spring/damping/break values kick in.From physics 4.5 for the geep;Spring (
Stiffness ( 1.2e6N/m 4.8e6N/m )
Damping ( 1.2e6N/m/s 3.4e6N/m/s )
Break ( 1.6e7N 1.6e7N )
r0 ( 20cm 30cm )
So what do the numbers actually mean? "1.2e6N/m", the "6N/m" part I assume means 6 Newtons per meter, but what is "1.2e"? And if I'm reading all this tech stuff correctly, at rest 20cm we have stiffness 1.2e6N/m, damping 1.2e6N/m/s, then when the extension (and possibly compression) hits 30cm, suddenly it changes to Stiffness 4.8e6N/m and Damping 3.4e6N/m/s. Could that sudden change in physics be the cause of the sim locking up when using the front coupler? Because the big question is how does it handle it backwards, IE Damping 3.4e6N/m/s at 30, and as it's returning toward the rest length it stays at the higher values until it hits 20cm, then suddenly changes to the lower values. I've heard there was some good info in bboxedit, but clicking on the "help" button don't bring anything up. From the BBoxEdit.txt file;"WHAT IS A Bounding Box
______________________
The Bounding_Box is a box shape that determines what portion of the
car is solid. The portions of the car inside the box will collide
with other solid objects in the world. These objects include buildings,
bridges, overhead objects, objects alongside the tracks, other cars
and the ground itself. An improperly defined bounding box will cause
a car to derail too easily and too often. A common symptom is the
'bouncing' car. This can be the result of a too large bounding_box
causing the car to collide with the ground and/or other cars."I don't think that's right, the size value is what is the actual collision box, I can reduce the ESD bounding box in the .s file to half the length of the size length in the .eng file, hit CTRL KP+ and the red lines are near the middle of the car, but the coupler hits where it's supposed to.Change the size in the .eng file, and that's what makes the spacing difference, independently of the ESD bounding box or the inertia tensor. If I make the size in the gp38.eng 10 meters, and couple two back to back, I can drive them around telescoped into each other like that and uncouple/recouple/couple to other cars with no apparent ill effects other than it looks wierd.There's also a rumor floating around that the "buffers" section don't do squat since they never got around to programming it in, true or false? And if that's true, what else is there we're missing?Anyway, it's an idea, I've been hunting for answers for a week now, and the majority of the answers I've run across are either misinformation or don't work because they're affected by other things.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RE: Deciphering the .eng file, inertia tensor, etc., kevarc, Jun-15-03, 00:55 AM, (1) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-15-03, 01:31 AM, (3) RE: Deciphering the .eng file, inertia tensor, etc., dvdhoven, Jun-15-03, 01:27 AM, (2) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-15-03, 01:46 AM, (4) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-15-03, 05:34 AM, (5) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-15-03, 11:12 AM, (7) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-15-03, 12:28 PM, (8) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-15-03, 05:05 PM, (12) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-15-03, 10:37 AM, (6) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-15-03, 12:45 PM, (9) RE: Deciphering the .eng file, inertia tensor, etc., b101uk, Jun-15-03, 02:22 PM, (10) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-15-03, 04:52 PM, (11) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-15-03, 07:04 PM, (13) RE: Deciphering the .eng file, inertia tensor, etc., plainsman, Jun-16-03, 01:25 PM, (15) RE: Deciphering the .eng file, inertia tensor, etc., smmille1, Jun-16-03, 09:57 AM, (14) RE: Deciphering the .eng file, inertia tensor, etc., plainsman, Jun-16-03, 01:29 PM, (16) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-16-03, 03:33 PM, (17) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-16-03, 04:14 PM, (18) RE: Deciphering the .eng file, inertia tensor, etc., b101uk, Jun-16-03, 07:50 PM, (26) RE: Deciphering the .eng file, inertia tensor, etc., smmille1, Jun-16-03, 04:46 PM, (19) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-16-03, 04:55 PM, (20) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-16-03, 05:08 PM, (21) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-16-03, 07:29 PM, (24) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-17-03, 04:06 PM, (29) RE: Deciphering the .eng file, inertia tensor, etc., plainsman, Jun-16-03, 06:44 PM, (22) RE: Deciphering the .eng file, inertia tensor, etc., mickoo, Jun-16-03, 06:50 PM, (23) RE: Deciphering the .eng file, inertia tensor, etc., plainsman, Jun-16-03, 07:42 PM, (25) RE: Deciphering the .eng file, inertia tensor, etc., b101uk, Jun-16-03, 09:40 PM, (27) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-17-03, 03:48 PM, (28) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-17-03, 09:46 PM, (30) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-17-03, 11:23 PM, (31) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-18-03, 03:31 PM, (32) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-19-03, 02:06 PM, (33) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-19-03, 04:27 PM, (34) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-22-03, 03:38 PM, (35) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-23-03, 01:03 AM, (36) RE: Deciphering the .eng file, inertia tensor, etc., GaryG, Jun-23-03, 03:58 AM, (37) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-23-03, 03:51 PM, (38) RE: Deciphering the .eng file, inertia tensor, etc., baldwin, Jun-23-03, 04:13 PM, (39) RE: Deciphering the .eng file, inertia tensor, etc., sniper297, Jun-26-03, 01:37 AM, (40)

Conferences | Topics | Previous Topic | Next Topic

2.5e7N=25,000,000NKevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hee-hee, thanks, Kev, never occured to me it was one of them shorthand thingys for mega numbers. I needed 2 extra hours of trig classes after school every day just to get thru Basic Electricity & Electronics school, and as soon as I passed the tests I promptly forgot all that ten to the umpteenth power joules per coulomb stuff, never needed it in the field. I gather the lowercase "e" is a multiplier of some kind?One other question answered already, I hunted up the default 5/8/2001 gp38.eng file as well as the 1.1 patch version (they changed the fuel filler, otherwise it's the same, didn't even fix the throttle notches for 1.1):Wagon ( GP38
Type ( Engine )
WagonShape ( gp38.s )
Size ( 3.1m 4.768m 18.879m )
comment( 250000lbs US )
Mass ( 113.4t )
WheelRadius ( 20in )
InertiaTensor ( Box (3.1m 4.8m 19.1m) )So much for the accuracy of the techdocs, if the size and inertia tensor are supposed to be the same, the default gp38.eng file is wrong.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi,Jim, I cannot remember ever having mentioned the Inertia Box, but if you said it, it must be true. May be last year when I was experimenting with tight curves.You forgot another parameter:
CouplingHasRigidConnection (0)
This is very important to get cars through tight curves. Not for front couplers!
But it plays a role in the whole coupler mistery.Dick van den Hoven

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Yeah, I think it was this one;http://www.train-sim.com/dcforum/DCForumID12/68.htmlor another one like it. Looking at that thread again, I noticed Tim Muir was using a single set of stiffness & damping values, that's another potential avenue to explore. I suspect that if an engine has one set of values but the cars have two, you'd still get all the slack action in the train, just not between the engine & first car. Two years now since this game came out, most switching fanatics gave up in disgust when the 1.1 patch did nothing more than make the brakes release. There's gotta be some kind of formula that will at least alleviate the front coupler bugs.Has anyone done any extensive experiments with that double coupler statement idea, and tried a lot of front coupler switching with it? Maybe it's not working for me cuz I'm not using the right values.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Sniper,This is what l'm using for my UK diesel shunter, maybe it'll help
Size ( 2.8m 3.938m 8.6m )
Mass ( 48t )
WheelRadius ( 27in )
InertiaTensor ( Box (2.8m 3.938m 8.3m) )
Coupling (
Type ( Chain )
Spring (
Stiffness ( 1e6N/m 2e6N/m )
Damping ( 1e6N/m 1e6N/m )
Break ( 1.2e9N 1.2e9N )
r0 ( 20cm 40cm )
)
CouplingHasRigidConnection ()
Velocity ( 0.1m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
r0 ( 0cm 1e9 )
)
Centre ( 1.5 )
Radius ( 1 )
Angle ( 2.5deg )
)In the SD file the ESD box is +- 4.15m, l had read somewhere that buffers didnt play a part, maybe they dont on auto couplers but they do seem to have a big effect on chain couplers.Next l added this section to every piece of kit to make sure there all the same, for loose coupled l simple removed the coupling has rigid connection parameter and lowered the coupler length to r0 5-10cm, short l know but it stops buffer overides, l've not had any crashs or send dont send reports, at worse l cant get a piece of stock to uncouple, usually a little back and forth and then setting the handbrake on the piece of stock helps.One thing l did find was the sequence of uncoupling had an effect, basically you need to come to a stand on the train brake ( fine for fully fitted but still has some effect on loose coupled ) not the loco brake, next apply the handbrake on the car you wish to uncouple, select reverse and power to notch 1 to take the strain make sure the brakes are on enough to stop the loco creeping, hit uncouple then release the train brake and it pulls away 95% of the time.It takes a while for the brake pipe pressure to build to release and as the loco is under power it will naturally slowly move away and probably falls within your deductions on couple-uncouple speeds.l'll try some loose fly shunting on my stock to see and to doubly make sure l've not missed anything.Best regardsMichael

Attachments

http://www.train-sim.com/dcforum/User_files/3eec3d706a1f609f.jpg

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

OK, I note you have your inertia tensor smaller than the size, default GP38 it's larger. I think the techdoc's opinion "These values should be the same as the Size values" can be safely ignored, altho there's still no formula or clear indication of exactly what the inertia tensor affects.Techdoc also says "Buffers - Not used", but if your experience shows that it does affect chain couplers, I think I can take your word over the techdoc. I also note you have damping exactly the same, and stiffness doubled for second value, altho in the buffers section damping is the same and stiffness is five times for the second value. r0 ( 0cm 1e9 ), I've seen that format before instead of the r0 ( 20cm 30cm ), no idea what it means. Looking at what Kevin said, I'm guessing that "e" in all these is "times ten to the (next number) power", so 1e9 would be 1 times 10 to the 9th power, or one followed by nine zeros (language barrier again, that's one billion American, one thousand million British). But 1,000,000,000 what? Newtons, apples, watts, Gs of acceleraion, imperial tons of impact per square centimeter? And exactly how fast is "warp factor 5", Captain Kirk? Scotty just says "Aye, Captain", like HE knows what it is."removed the coupling has rigid connection parameter", in the US equipment that's usually present but commented out."One thing l did find was the sequence of uncoupling had an effect, basically you need to come to a stand on the train brake ( fine for fully fitted but still has some effect on loose coupled ) not the loco brake, next apply the handbrake on the car you wish to uncouple, select reverse and power to notch 1 to take the strain make sure the brakes are on enough to stop the loco creeping, hit uncouple then release the train brake and it pulls away 95% of the time."That's one of the goals of all this, eliminate all that unprototypical and aggravating screwing around, I've been using; back away to take out the slack, uncouple, set engine brake to 30%, throttle to notch 1, slowly release engine brake until it just starts creeping backwards, 0.3mph or less. Changing the throttle notch settings; EngineControllers (
Throttle ( 0 1 0.125 0.
NumNotches ( 9
Notch ( 0 0 Dummy )
Notch ( 0.05 0 Dummy )
Notch ( 0.14 0 Dummy )
Notch ( 0.28 0 Dummy )
Notch ( 0.4 0 Dummy )
Notch ( 0.52 0 Dummy )
Notch ( 0.7 0 Dummy )
Notch ( 0.875 0 Dummy )
Notch ( 1 0 Dummy )Makes it so I don't have to use the loco brake anymore, notch 1 at 5% power instead of 12.5% makes the initial acceleration a lot slower.I started playing with the velocity setting, according to Richter;"Velocity ( 1m/s ) - not listed
The parameter „velocity“ is not documented, but I found out it is the average of the velocity you can use for coupling. If you always get problems by coupling, always driving in the meadows and five thumbs at each hand, set this value higher, for instance to 0.15m/s
The simulator accepts values in kmh too."He's right about one thing, it's not documented, the techdocs don't mention it at all. Like him, I assumed the velocity applied to coupling speed since it's right under the coupling values, but raising it to 5m/s or 5kmh in the .eng or the .eng plus the .wag for the car you're testing with has absolutely no effect at all, 5m/s is 18kph or 11mph, yet kissing it with the back coupler at 0.5mph still couples, and exceeding 0.5mph in reverse while backing away with the front coupler still recouples. So that looks like a dead end, I did look at the default.wag, possibly that's what it's actually reading and ignoring the velocity lines in the .eng and .wag files.So here's a new thought;
Even the most vocal apologists for Microsoft agree that this sim was rushed out the door in a half finished state with numerous bugs and loose threads left in it, and all the physics experts say the default physics are just plain wrong. I'm assuming the "r0 ( 0cm 1e9 )", or "r0 ( 20cm 30cm )" is what actually triggers the change between first and second values for stiffness, damping, break, and whatever else has double physics values.Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 1e6N/m )
Damping ( 2e6N/m/s 2e6N/m/s )
Break ( 2e7N 2e7N )
r0 ( 20cm 20cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 5.0m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 1e6N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
r0 ( 0m 0m )
)Apply that format to everything, the game engine itself wasn't tuned to properly handle two sets of physics values or the transition from one to the other before it was rushed onto the shelves. No point in having two different sets of physics values if the game is gonna screw it up.

Attachments
http://www.train-sim.com/dcforum/User_files/3eec8cb17194566c.zip

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-15-03 AT 12:29 PM (EDT)

Right, I have just been for the run through Cutbank. For the purposes of testing I did not alter the coupling stiffness of the engines, but left them in the **e6 area. The result was a total disaster. No matter what speed, accelerating or braking, the lead, or second engine decoupled. Result, train braked come on at the front as air is dumped, and the rest of the train carries on, one first class pileup.I then changed the stiffness value on the engines to match the rest of the train as per my previous post, which is below this one. Result, a perfect run through at any speed, braking or accelerating. Just to be sure, I picked a save point from a bit earlier and ran Cutbank in the 70-75 mph range. Again, no derailment, just pure smooth running. Now the front coupler. I havent done much with it in this state, but so far have had no recouples so far. I have been using the N&NJ and stock to check this one.Now, assuming that r0 is referring not to the length of the spring but at which point in the extension or compression that the other values kick in, then it starts to make sense, with the stiffness set to lower values, the coupling is not so volatile in its reaction and will accept lower values for the break. I feel that the knock on effect from this is that the front coupler does not react quite as fast and in theory should make thing easier.Sniper, you are the switching king round here, care to give this one a go.mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Just been banging a few couplers together in N&NJ. I found that most cars are happy with the Inertia Tensor at the same size as the car, but some need it to be just a tad shorter. Using the front coupler only to drag and shove a line of cars between sidings I had no lockups until I reached one that I hadn't fiddled with. This one coupled to the front of the engine and then shot through it and recoupled on the rear, most odd. Was using the LV GP18 at the time. I changed that out for the modified GP38 and changed the coupler statement for a softer spring and once again it seems to be OK.I cant attach the eng file, getting javascript errors. Must be the new firewall I installed today. Anyway, this is the coupling I am using at present in all stock
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 4e5N/m 8e5N/m )
Damping ( 1.2e6N/m/s 3.4e7N/m/s )
Break ( 1.6e7N 7.6e7N )
r0 ( 5cm 20cm )
)

Velocity ( 0.1m/s )
)
mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

SniperI have sidelined the double coupler for now, and have been concentrating on the complete coupler statement. My aim was to get a complete train through Piegan westbound with no shimmy, telescope, uncoupling or broken coupling. This is the one spot on the whole line where distance and 'nodes do not come into the equation. Your opening post of this thread restarted the ancient grey cells, and with a bit of gentle stirring came to a conclusion. If every line that has a major impact on coupling behaviour, why is it that there is no difference in the two parts of each line with regard to stiffness, break, and sometimes damping, when there are two distinct values in the r0 line. After much experimenting with the replacement default us2 stock and a couple of addon engines I can now get my train to run through Piegan with no breaks, shudders, or anything else, just a smooth runthrough.The values I am using are these
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e5N/m 5e5N/m )
Damping ( 1e6N/m/s 2e7N/m/s )
Break ( 2.6e7N 7.6e7N )
r0 ( 5cm 20cm )
)

Velocity ( 0.1m/s )
)
Note that I have lowered the overall stiffness, and reduced the outer r0 to 20cm. The main thing to note is that there are higher values in place for the for the end of the runout. How this will figure in the front coupler problem I am not sure yet, but the reduction in stiffness was the final key in getting through Piegan. I am now going for a run west from Shelby to see how it copes with Cutbank East.
mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Sniper,l've been playing on and off all day and have found some horrors, for the loco and coaches l've used the exact same values for buffers and couplings and front and rear coupling is really sweet, then l added in the freight stock and all hell broke loose, now l'm getting crashes, ok the buffer section is the same and the only difference is the lack of the coupler has rigid connection statement and drastically shorter coupling lengths. So.... one of those two factors in my instance is the difference between front couplers working and not working. The problem is not only between the loco and wagons but between the wagons themselves, shunting the right way round there is no issue at all, shunting fwd and theres a lot of problems.Your right about the spring values, however this seems to work best here, one problem with chain and buffers is that there always interacting with each other, by rights both should have exact same values to balance each other, l must admit as soon as l got it working l left alone so those values could well take some revisiting to "clean" up.On UK stock, having the amount of compression seen on US stock looks odd as the buffers overide, adding the coupling has rigid comment stops that but looses the loose coupled snaking effect that many find desirable.Hmm more work to do l fear.Best regardsMichael

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-15-03 AT 02:34 PM (EDT)

hiwell i use this, to use this cupaling do this
1st your InertiaTensor value should be the same size as the length from buckeye center to buckeye center.2nd your Size should be your "InertiaTensor value" less your 1st "r0 value (-0.3m(30cm)).Coupling (
Type ( AUTOMATIC )
Spring (
Stiffness ( 7.3425e5N/4cm 2.937e6N/2cm )
Damping ( 7.3425e5N/8cm/s 7.3425e5N/4cm/s )
Break ( 2.2e7N 2.2e7N )
r0 ( 30cm 46cm )
)
comment ( CouplingHasRigidConnection () )
Velocity ( 0.12m/s )
)
Buffers (
Spring (
Stiffness ( 4.45e6N/20cm 4.45e6N/4cm )
Damping ( 4.45e6N/20cm/s 4.45e6N/20cm/s )
Break ( 4.46e6N 4.46e6N )
r0 ( 20cm 40cm )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)witch is below in "lb/in note thes are to within 100th" of the above,
do not use the lb/in form in a wag/eng file.Coupling (
Type ( AUTOMATIC )
Spring (
Stiffness ( 165000lb/1.574in 660000lb/0.787in )
Damping ( 165000lb/3.149in/s 165000lb/1.574in/s )
Break ( 4943820lb 4943820lb )
r0 ( 11.811in 18.107in )
)
comment ( CouplingHasRigidConnection () )
Velocity ( 0.12m/s )
)
Buffers (
Spring (
Stiffness ( 1000000lb/7.87in 1000000lb/1.574in )
Damping ( 1000000lb/7.87in/s 1000000lb/7.87in/s )
Break ( 1100000lb 1100000lb )
r0 ( 7.87in 15.74in )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)what takes place: starting from 11.811in we have ziro force(free length), then for evry 1.574in we get 165000lb resistenc ageanced the direction of travel IF past the 1st r0 value(11.811in)(a + or - force), so 1.574in*4=6.296in so 165000lb*4=660000lb so in 6.296in we get a force = to 660000lb.now the 2nd r0 value starts at 18.107in and has a force starting at 660000lb that increses at a rate of 660000lb per 0.787in, so at 18.894in we have a force = to 1320000lb.now if you get 18.107in-11.811in=6.296in so we can see that the r0 values vs LB values load up into each other in a smooth maner, no ultra suden incres in force or jumps in loading in lb/in.now take the Break values (4943820lb), simply by looking we can see its not going to brake in the 1st r0 value range, so it can only brake in the 2nd values force range, remember the 2nd r0 value starts at 660000LB and not 0lb, so 4943820lb-660000LB(as 2nd r0 starts with this)=4283820lb/660000=6.49, so in 6.4906in in the 2nd r0 values range we will brake our Coupling divice, or any force = to 4943820lb will do the same.a small note on Velocity, Velocity hear is out of use becouse it is overriden by "0.2 # min coupling velocity"
"3.0 # max coupling velocity"
in the default.wag file like a fue other thingson a subnote :in real life the minimum curve for a gp15 Coupled to a 50ft box car is 245ft(74.6m) radius, for a gp35 its 303ft(92.35m) and for a sd40-2 its 359ft(109.42m), witch meens that the defualt 45deg60m (196.85ft) yard points and curve is a bit of a no no unless you are runing as a light loco(no wagons Coupled)also dont foget what i said about "couplers propogate from the frunt to the rear of the train" in http://www.train-sim.com/dcforum/DCForumID5/6748.html#19and some other bits hear http://www.train-sim.com/dcforum/DCForumID5/6760.html#4 regarding "Size,InertiaTensor,Coupling r0 values" vs bogie pivot point to the buckeye center, NOTE: any 1st r0 vaule hear over 30cm is a fix for odd shaped or long wide swinging locos, ware you dont wish to use the frunt coupling, if you wish to use the frunt coupling then use a 1st r0 value of 30cm as per:
"1st your InertiaTensor value should be the same size as the length from buckeye center to buckeye center.
2nd your Size should be your "InertiaTensor value" less your 1st "r0 value (-0.3m(30cm))."
if you wont my honest opinion, the frunt coupling prob is nothing to do with the frunt coupling on its owne, its a number of probs that combine to triger the crash, next time you frunt cuple to a groupe of wagons, look at each bogie and check the wheels are there, also check that all the bogies are there!, its difrent evry time, if the wheels are thare, are thay in the corect place!, another thing, i can switch all day on the defualt mp at whitefish yard with the frunt coupling, yet else ware i get the odd crash now and then, what makes whitefish yard difrent, as i see it long spases bitween manual switches, its also defined as a "yard zone" and lastly you can use a short "Optional path seting" in the AE, but othere places have the same setup yet thay crash? also placing loose consists in the AE so the frunt of the consist is in the same direction as the loco is or would be facing can also help, but its not a total fix.it could be the wagon .s file, eg: look how meny vol_sphere thay have, yet thay crash just as often as 3rd party ones, if we look at matrices orders in defuat wagons then we se that thay are orderd in 3 destinct groups, 1:bogies and wheels in corect order 2:bogies in corect order but attached wheels are back to frunt in order 3:bogies back to frunt but wheels in corect order, yet i have bilt meny test wagons with virus wheel and bogie orders yet crashing is still a randume event.Train Operations window only showing 6 wagons when frunt cupled is the prob, er well no its a simptem but not a cause, any of you guys intrested in a Train Operations window that will show 12 or even 24 wagons when frunt cupled as i useto have one, it would only take a fue hours to make a new one?any how thats plenty from me, my head herts nowb101uk

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Your head hurts ??, thats some pretty neat ideas, l like the tension maths, makes complete sense to me, all I have to do now is convert the current N/m so that the tension is progressive through the range.Having played most of the day the final golden bullet here was the first value of r0, l had it as low as 5cm and 10cm and it was a nightmare, tension forces made absolutley no difference, however extending r0 20cm for the first value removed all issues. sadly this increases the compression between stock which on Buckeyes doesnt look to bad but on BR stock it looks like the modeled buffers are overiding, thus l had to add the rigid coupling statement .I will confirm that coupling and tension forces only occur at one end of the stock, it seems MSTS cannot calculate the interaction between two sets of parameters. Basically put its only working on one set of parameters of the stock. Example if you shunt 1 wagon into another either forwards or backwards then the only forces calculated are on the piece of stock thats moving. The coupling parameters on the stationary piece of stock are effectively locked solid, all coupling actions and forces being taken from the moving coupler. Same applies to the loco, only the forces on the loco are used, not the front of the wagon attached to the loco being pushed.On reflection this makes perfect sense, the loco is the 1st person item and that part which the sim is controling, it knows that there is one waggon attached and it knows those forces, however.... it doesnt know what the other item is, how can it, its not connected to the 1st person, to that end the sim cannot hope to know what your connecting to nor the values of its connecting forces. This means it will take the static object as solid until its actually connected then its forces are added into the 1st person calculations, make sense ?. Sorry if some of this is old hat .Best regardsMichael

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

b101uk, if you can make a coupler window that works for 24 instead of 7, that would be great provided it don't trigger some other bug!Michael, nope, definitely new hat. Nobody can post a link to an old thread anyway, all the attempts to fix the front coupler brake release problem prior to the 1.1 patch and trying to figure out the random lockups after the 1.1 patch were all lost in the server crash.'This means it will take the static object as solid until its actually connected then its forces are added into the 1st person calculations, make sense ?."That's kind of my thinking, a loose consist sitting on the track is just an object until the player train couples on, at which time the .wag file is loaded and consulted. "I will confirm that coupling and tension forces only occur at one end of the stock", that would go a long way toward explaining why the engine's front coupler beheaves differently depending on whether it's hitting the "designated" front or back coupler of a wagon. And yeah, B101UK, I have seen the disappearing trucks, but also when using the back coupler, if a wagon is reversed the wheels rotate the wrong direction and the trucks pivot the wrong way, and on some cars with certain display options you actually see a "light side/dark side" effect on the wheels & trucks!Anyway, this everything-equal setup is working for now, it does have decent looking slack action, and the front coupler works. Saves a lot of screwing around trying to eliminate the rubber band effect when it switches back and forth from value one to value two, and I suspect it gets out of synch. That would explain why it won't damp down on some of these.I'm gonna try that default.wag hack next, at least that's only one thing that needs to be changed instead of 2e13 cars and engines!

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Your work is very interesting, but it would be much easier to follow if you would simply reduce your math terms to a simpler expression. 165000lb/1.574in is 104828lb/in or 1,257,942 lb/ft. That is a more standard expression, thus easier to follow.
Bob

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Forgive me for just skimming the whole thread before posting - I may be stating something that's impossible or has already been proposed. I noticed mention of the double coupler settings and of the velocity() parameter (and I think I noticed that there's problems with both?). If you can specify a velocity parameter for each coupler, couldn't you use a negative value for the front coupler? Since the sim is too dumb to reverse the physics, why don't we just throw a negative sign in there for it?

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Although there are a lot of improvemnts that will help under certain sisuations, they may result in other problems in different aspects of the sim. The real problem is that KUJU designed this sim thinking it would be run almost exclusively as a passenger game, getting fromn one station to the next on time. They did not anticipate the switching and freight activity it is emulating when the basic sim engine was constructed.
Bob

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hey, Bob! Boy, ain't THAT the truth. I'm surprised the back coupler worked out of the box, considering the percentage of people who actually use it. What, no flamewars? That new theory that two sets of physics values is a waste of time because the game engine don't handle it properly was designed to be provocative, get some serious arguments and grey cells going. I did try the single entry that some people have posted, but get error reading line 14 stuff out of that, so I just changed all the first & second values to be the same. I'm still getting realistic looking slack action between couplers, but no more sudden jerk-rebound when it switches from one value set to the other. "Although there are a lot of improvements that will help under certain situations, they may result in other problems in different aspects of the sim."Yup, no *&^%$#!, get it working properly with the front coupler, no lockups/crashes/send-don't send, you get rubber bands on curves and/or visual space either too much or not enough. Fix that and your send-don't send problems are back.

One real wierd one, I replaced all the US2chemicars in the PO&N6 activities with the other tanker, US2freightcar3, since the US2chemicar randomly refuses to couple to other cars when reversed, sometimes maybe it depends when the Moon is conjunct Saturn or something. Don't have that problem ever with US2freightcar3, so I just globally replaced them all and uploaded a patch. The US2freightcar3 is longer than the US2chemicar, and I hacked all the activities by doing a find, replace in wordpad. Got away with it, there was enough seperation between loose consists to accomodate the longer cars. Sometimes while hacking size boxes and stifness and r0 lengths I get "objects starting in collision", and sure enough the verify starting state in the AE shows two consists overlapping, one in Texas Tea and the other in Van den Hoven. Change values and it fixes it, small gap between the two loose consists instead of an overlap. What's really wierd is increasing the minimum coupling speed in the default wag also changes the coupler spacing in the loose consists, so if I increase too high I get objects in collision.Scott, two problems, first is I'm almost convinced that it uses only the first coupler statement it comes to and ignores a second statement if one is added. Like Mickoo said, it probably also uses the physics only on one end of the car.The other thing is the r0 (first number second number) is the trigger mechanism for two different physics values, not two different couplers. I think, still haven't had anyone either confirm or tell me I'm full of *&^%$#! yet. So the damping and stiffness first value is what it starts out at, coupler projecting 20cm from the size box (probably at one end, probably the "designated" back coupler of the wagon). When the coupler is pulled out (resisted by the stiffness and slowed by the damping of the first numbers) to 30cm, that's when the second physics number set kicks in, so there's a sudden change in stiffness and damping.The velocity, as someone pointed out and I've just been testing, is not actually used, at least not for coupling. Crank that up to 8.0 and the cars still couple on at less than 1mph. Open the \Trains\Trainsets\Default\Default.wag however, and there at the bottom are the minimum and maximum coupling speeds used by all the engines and wagons in the sim. Change the minimum number from 0.2 to 0.8 and you gotta smack the car pretty smartly with the back coupler to get it to engage. I'm currently using 0.3, seems to be a pretty good compromise between slow speed coupling on and ease of uncoupling with the front coupler. Doesn't change the other thing tho, the front coupler actually does not engage when the engine and car are moving toward each other, only when they're moving away from each other; what would be the "proper" direction if it was the back coupler instead of the front. 0.3 still works pretty good to give the illusion, smack the car with the front coupler at 1.5mph or above, and the rebound is still fast enough to activate the coupler engaged as they're seperating. Pull the slack out and uncouple, and moderate acceleration won't recouple as you back away. Even if you uncouple with the slack in it still won't recouple as long as the speed is under 0.5mph until you reverse past the limit of the coupler "engagement boundary box".So anyway, that's another thing to look at, what exactly is being read and used from the default.wag and how does it affect the physics values in the regular .eng and .wag files? Just curious, something I haven't heard mentioned in a long time, anyone here ever bought the Cybex book for trainsim, and if so does it have anything to say about any of this? Most importantly, was the book worth the money?$?$?$

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Sniper,just one point l'd like to throw in, its the r0 values, my understanding is that the first value is the maximum length for the first set of parameters, the second set of values is the for the distance between the two vaules.ie r0 ( 20cm 40cm ) would equate to the first set of parameters for the distance from 0 to 20cm, the 2nd set from 20 to 40cm, after 40cm there is no tension your basically maxed out. b101uk's maths looked ok on face value but l'm not sure its entirely correct, l dont think you need to calculate the force over the distance of the first value to arrive at the second vaule.I think that the force values are the actual pressures within those given distances, in that case you would expect a difference between the lowest and highest which is prototypical of the real thing.Just to really mess things here l've found l'm getting derails and uncouplings occasionally on less than perfect track, l looked at the ESD box, size and inertiatensor figures.My understanding is as thus.Inertiatensor : is the size of the cargo load area, typically simular to the actual size but minus a little bit for end wallsSize : physical size of the actual piece of stock but minus the coupler length, the largest figure, in my case 40cm.ESD box : the bounding collision box used by the sim to define collisions and clearance.Size has to be correct and adj to accomodate the coupler and effects the visual connections and gaps between stock. Inertiatensor is slightly smaller than the size and ESD is the physical size of the stock minus couplers ie the body size.Its the last one that threw me, nearly all my stock has this set to 0.00, as we know from loco and stock building you need to raise your model up by a small amount ( sorry forgotten the exact distance ) so that it sits on the rails, but...leave the stock ref point at 0 height. Thus by deduction our collision box is at ground height and not rail height, by raising the lower limit to say 0.05m you have moved the bounding box above the rail, in fact 0.5m would be better to give some ground clearance.Is it possible that stock is grounding out on lumps and bumps between track joins and thus uncoupling or derailing ?.Best regardsMichael

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi"ie r0 ( 20cm 40cm ) would equate to the first set of parameters for the distance from 0 to 20cm, the 2nd set from 20 to 40cm, after 40cm there is no tension your basically maxed out. b101uk's maths looked ok on face value but l'm not sure its entirely correct, l dont think you need to calculate the force over the distance of the first value to arrive at the second vaule."er 1st you dont have to "calculate the force over the distance of the first value to arrive at the second vaule" you can do it how you wish, the only resen i do it is is becouls i wont it to load up smothly into the 2nd set of values but still have some slack, run some 150 wagoon trains with my cupaling values and all power on the point and you will get apx 130ft to 145ft of slack."Its the last one that threw me, nearly all my stock has this set to 0.00, as we know from loco and stock building you need to raise your model up by a small amount ( sorry forgotten the exact distance ) so that it sits on the rails, but...leave the stock ref point at 0 height. Thus by deduction our collision box is at ground height and not rail height, by raising the lower limit to say 0.05m you have moved the bounding box above the rail, in fact 0.5m would be better to give some ground clearance"er that will make no difrence as the Bbox is alwas level with shape 0,0,0 point regardles of seting in the sd file(wag and eng types only), also track level is 32.5cm above ground level(track 0,0,0 point), loco/wagon 0,0,0 point is 30cm above graund level or 2.5cm below visual track hight, on a sub note have you trayed a ESD_Complex_Box for wagons and loco, it lead to some rather odd and some times funny hapenings . also as i run all my track shaps with out ESD_Bounding_Box ("ctrl" + "Kpad +")

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>Scott, two problems, first is I'm almost convinced that it uses only the first coupler statement it comes to and ignores a second statement if one is added. Like Mickoo said, it probably also uses the physics only on one end of the car.Well, it seems to at least pay attention to coupler types, or else that aspect wouldn't work, which we know it does to some extent. Whether or not it pays attention to the physics values in the second set is another issue entirely. Even if velocity doesn't work, might there be another value that's linearly multiplied that could be used to change the sign for the front coupler?

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

The front coupler doesnt get a lookin at Sybex, all switching referred to is done with the rear coupler.I have done a bit more with the coupler physics tonight and using the us2freight7 and the LV_GP18_#305 which has an unmodified throttle, spent 30 minutes coupling and uncoupling with the front end. During this time I did not have a single lockup,freeze,kickout or call Uncle Billy. I modified the Default wag to 0.01 min and then observed the action.What I saw confirms your statement about how the front coupler is working. The actual coupling movement takes place as the car rebounds from the engine, so your initial speed must be high enough to generate this rebound. The second item to assist in using the front coupler is the Inertia Tensor box of the car. Some work with this set to the size of the car and others need it to be a bit smaller, usually a tenth reduction will suffice.The uncoupling must take place with the coupling in tension or you will recouple on the spring rebound as you move away. The spring stiffness as set in all files is too high, IMHO, and this is the main contributing factor to front coupler problems and the 'nodes and distance' syndrome out on the track. I went a bit too soft on one test run, and had a gap of about 8 feet extend between two cars at one of the problem areas, with no coupling break. As the train rolled along, the 'spring' gradually hauled itself back into place. This needs a bit more work to prove or disprove, and probably to arrive at a definitive set of figures for the whole coupler, maybe even different figures for different types.Anyway, these are the latest set I am using along with the change in the Default.wag.
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 4e5N/m 8e5N/m )
Damping ( 1e6N/m/s 2e7N/m/s )
Break ( 2.6e7N 7.6e7N )
r0 ( 5cm 20cm )
)

Velocity ( 0.1m/s )
)
Anyone care to try these (with no buffer statement either), apply to both engine and cars. Remember, if you dont run the slack out, you will definitely recouple. mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hmm l'm missing something here, l cant get my head round how 4e5N/m is lower than 1e5N/m as a force, surely the lower the number the less force required to extend the spring, sorry if l've missed the obvious .The buffer statement has me wondering now, if you add the coupling has rigid comment you loose the bounce between stock during shunting and traveling, thus by that statement buffers have little or no effect, in esscence buffers just seem to compound the problem as they will effectively be fighting against the coupling.Best regardsMichael

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Now MY head hurts. Who's got the aspirin?!Mickoo:"e r0 ( 20cm 40cm ) would equate to the first set of parameters for the distance from 0 to 20cm, the 2nd set from 20 to 40cm, after 40cm there is no tension your basically maxed out."Ok, if I'm getting that correctly, value 1 would be applied at max compression, and from there to at-rest and beyond to the second r0 value."the second set of values is the for the distance between", that contradicts "the 2nd set from 20 to 40cm", do you mean if r0 (20cm 40cm) then:1, first numbers from max compression (0 cm I assume) to 40cm extension, or,
2. to 40cm beyond 20cm, or 60cm total?Assorted screwing around with this seems to indicate the actual coupler length beyond the body is also defined here somehow. Setting the size at a given value then changing the first r0 seems to change the spacing, altho I'm not sure of that yet."My understanding is as thus.Inertiatensor : is the size of the cargo load area, typically simular to the actual size but minus a little bit for end wallsSize : physical size of the actual piece of stock but minus the coupler length, the largest figure, in my case 40cm.ESD box : the bounding collision box used by the sim to define collisions and clearance."My goal is always to clear up misunderstandings!When you hit CTRL and the keypad + in the sim, those red lines you see are the ESD bounding box from the .sd files.Here's the US2 logger car with the ESD bounding box in the SD file set for double the length of the car, size in the .wag file reduced to 4 meters, inertia tensor at default. Note the Alco is inside the bounding box, it doesn't collide until it hits the actual car. It won't couple on that way tho, since the inertia tensor stops it before it gets to where the physical (not the visual) coupler is, attached to the 4 meter long size box.

Here both the inertia tensor and bounding box are 4 meters long, the size is back to default, the engine can couple on.See the top set of pics for both inertia tensor and size in the .eng or .wag file set smaller than the actual car size and bounding box.The actual collision takes place with the size value in the .eng or .wag, NOT the ESD bounding box. Been a lot of confusion on that one issue, I'm not clear about what the bounding box actually does, but contrary to popular opinion it does not define collision boundaries. How the inertia tensor fits in I don't know either, except that if it sticks out far enough beyond the size box it will prevent coupling and cause a rebound, possibly it's an elastic boundary. That would fit in with Dick van den Hoven's experiments with a slightly larger than size box inertia tensor reducing bouncing on tight curves, since the collision with the size box takes place within the inertia tensor boundaries, which would dampen the collision. If that's what the inertia tensor actually does, that is."Is it possible that stock is grounding out on lumps and bumps between track joins and thus uncoupling or derailing ?."Could be.http://www.train-sim.com/dcforum/User_files/3c805fad2e115d0a.zip
http://www.train-sim.com/dcforum/User_files/3c805fd52e7842a0.zip
http://www.train-sim.com/dcforum/User_files/3c805ff22ed29412.zipThere's PO&N version 1 in its entirety.
Download all 3 zips, extract all 3 zips to \Train Simulator\Routes, and double click on PO&N.bat in the Port_Ogden folder to install.There's a 5% grade coming out of the coal mine in that version, with an abrupt transition to level track. Took me a while to learn some of those transition lessons, but I had no problems with ordinary length cars, altho the really long cars would tend to hang and uncouple and derail on those sharp humps. Why the hell anyone would be hauling anything but hopper cars in and out of a coal mine is another issue, but sacrifices for the sake of scientific research are sometimes necessary, so drag a set of those 80 foot tank cars up & down that grade.Igor;"Even if velocity doesn't work, might there be another value that's linearly multiplied that could be used to change the sign for the front couple",Hmmm, maybe, we've been hunting for that for a long time. Guy named Craig "TopDog" Shortino ("I GOT IT! I GOT IT!" Hee-hee, that kid definitely needed Ritalin, but I liked him, his bouncing off the walls really livened things up here!) was fooling around with that before the 1.1 patch came out, but back then the goal was just to get the holding brakes to release when the front coupler engaged. Turned out that was in train.exe, not the .wag or .eng files. Maybe the default.wag has possibilities;"1.0N/kg/m/s # Friction when cars dig themselves into banks"
"0.3 # min coupling velocity"
"3.0 # max coupling velocity"
"29.4 # durability max acceleration"
"0.034013605442176 # 1 / durability max acceleration"Adding a
"-0.3 # min coupling velocity"
"-3.0 # max coupling velocity"to that mess and somehow getting the sim to take notice of it might work. I assume that value is in mph rather than meters per second, they didn't say, but max coupling speed is around 3-4mph, and minimum around 0.2, again with the back coupler on the front of the wagon, any other combination changes everything.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

If you look at the values I originally put up, and then the last set you will see that I have shifted the whole thing up the scale. My original set, whilst giving a smooth ride through the rough patches, had a side effect, coupling stretch, but only on a couple of cars. It was really strange to watch. I was convinced I had a broken coupler, but no message displayed, then I noticed that the second part of the train was travelling faster than the first part as the coupler spring pulled back into position.The buffer statement is something else that needs work done to actually find out what, if anything, it does. If the complete statement is removed from the wag/eng file, there is still bounce between stock from the coupler spring. On American style stock the train forces are all concentrated through the coupler, but on old chain coupled stock the coupler absorbs the pulling forces while the buffers absorb the braking and switching/shunting forces as the train bunches up. The difficulty lies in determining where the inertia tensor and bounding boxes fit in with stock that has no visible coupler, and do the buffers sit inside or outside of these.mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

This is what I mean by a tradeoff. I would really loose the visual appreciation of the sim if even 3-4 foot gaps open and close between cars. I want to be able to run break at 360,000 and 500,000 pounds for grade C and E couplers, but we just can't seem to work those numbers in the sim as it is now. I think
Stiffness ( 1.0e6N/m 1.8e6N/m )
Damping ( 1.1e6N/m/s 1.6e6N/m/s )
Break ( 1.4e7N 1.4e7N )
r0 ( 20cm 30cm )
is about the least you can go and avoid the unreasonable stretch. I guess some who want a lot of front coupler switching, and don't run long trains would be able to go to your settings, but i wouldn't like the effect on my activities.
Bob

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-16-03 AT 06:51 PM (EDT)

Aha yes l see it now, mine are too soft, yeah here in the UK we would be lucky to get to 3000 tonne train maximum, generally there in the 1000-1700 tonne range and passenger trains in the 500-1000 tonne range, thats probably why my figures are just fine. l also add the coupling has rigid parameter and that soaks up all the stretch but keeps some for coupling, hmmm what a mess .Best regardsMichaelPS l'll try increasing mine to see if it has any detrimental effects on coupling front or rear, l do note that sniper has lowered his too so maybe like you say its a trade off.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I understand. Where I live, the typical train that goes by is 12-15,000 tons. We get up over 17,000 tons on coal trains in North America. Most of my trains in the sim are from 4,000 to 14,000 tons.
I do hope KUJU has spent some time with getting coupler action modeled more accurately. It was obviuously an after thought in the first version, since some parts seem to have no affect. They didn't think it was important as they saw the sim in use, little freight and mostly passenger activities.
Thanks,
Bob

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hisomthing i have been after, but like you say ther are some sticking points(no pun).from what i have gatherd over the years is that that anything that has a constent rate loading force eg: 360,000 and 500,000 pounds, C and E couplers, meens you can hang that amount of force of them all day with out them faling, yet shock forces that take place for msec of time can run in to big numbers fare exseding the rating, i have read tetnical reports on couplers both train/truck and cars witch show that 360,000 and 500,000 pounds couplers reguly get forese up to and boyond 5,000,000lb witch only take place for 2 to 7 msec & or over ranges of up 1/16in,also with the "Break" how it works would in some ways be to low, if i recall all wagons in the USA must exsept a force of 660,000lb agenced them with out damage or derail, for loco this is 1,000,000lb, as your wagons have no buffors then this froce can only be absorbed by the 2 cupalings bitween the wagons under compreshon, as the Break statment works in boath directions(as dose spring & damping) then a 500,000 pounds coupler under compreshon would brake at 500,000 pounds and not the >660,000lb it should withstand.b101uk

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

BobWith the stiffness level as I now have it I dont get the gaps opening and closing quite so much, what I am getting is a nice smooth ride. As always, there is a bit more work to do on this, but I am convinced that the coupling stiffness levels are set too high, and therefore are a major factor when considering why the things break in the first place. What break values would you be looking for to be realistic in operation, working within your span of train weights?mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hee-hee, well, this is why I started all this, got tired of wasting time exploring blind alleys to dead ends. "This is what I mean by a tradeoff. I would really loose the visual appreciation of the sim if even 3-4 foot gaps open and close between cars. I want to be able to run break at 360,000 and 500,000 pounds for grade C and E couplers, but we just can't seem to work those numbers in the sim as it is now. I think
Stiffness ( 1.0e6N/m 1.8e6N/m )
Damping ( 1.1e6N/m/s 1.6e6N/m/s )
Break ( 1.4e7N 1.4e7N )
r0 ( 20cm 30cm )
is about the least you can go and avoid the unreasonable stretch."Question is, what actually limits the stretch? I have found that the first r0 number does indeed affect how far from the size box the back coupler projects, but the second number isn't any kind of limit. I've been assuming all this time that the higher the stiffness & damping values, the more the slack action would be tight and controlled, but from what I'm seeing with the latest experiments it looks like the opposite. Higher numbers = more stretch, bunch, and Ricochet Rabbit Rebounds, low numbers = less slack action. Yes? No? Maybe-sometimes-it depends?

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

http://www.train-sim.com/dcforum/DCForumID15/1513.htmlNope, that's not the answer. At least I got a decent belly laugh out of it tho!

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

That was the Stiffness at work, or rather the lack of it.mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Here's another new idea, the unexplained values in the coupling statement affect the stretch, the ones in the buffers statement kick in when the coupler is pushed in? Switches back again when the coupler comes back to 20cm (or whatever the first "at rest" value is in the r0) extension?That would explain the more noticeable effect of the buffers statement on chain couplings, if you stop and think about the nature of chain couplings their normal "at rest" position is max stretch, held in tension by the buffers.I was looking thru some of the defaults, noticed the 380 and the scot don't have double coupler entries for either the loco or the tender, don't know what that means if anything. My attempts to simplify the physics of the geep by making a single set of values didn't work (error reading line whatever), so this one in the 1100 (whatever an 1100 is, have to check that out) caught my eye;Coupling (
Type ( automatic )
Spring (
Stiffness ( 2e7N/m 0 )
Damping ( 0.2e7N/m/s 0 )
Break ( 1e7N 0 )
r0 ( 0.1 1e9 )
)
CouplingHasRigidConnection ()
)
Buffers (
Spring (
Stiffness ( 1e7N/m 0 )
Damping ( 1e6N/m/s 0 )
r0 ( 0m 1e9 )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)So I copied and pasted that into invisocar, since I'm looking for a rigid coupling for that anyway. The slack action between the first car and the engine is still there, since each end of the invisocar rigid coupler is coupled to one that don't have a rigid coupler. Seems to be working so far, dragged a train with six different invisocars all over the tight curves and sudden grade transitions of PO&N1 with no problems.So I'm guessing what I was doing wrong was not adding the 0 for the second value in each line, maybe that would work without the rigid coupling. But "r0 ( 0.1 1e9 )"? I've seen that 1e9 for the second value instead of cm on other engines and wagons, what is it? 1,000,000,000 centimeters it couldn't be length!And then there's the last part, Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )What is it, what does it do, what else does it affect?

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I'm not so sure about that new idea, but have one to bounce back. If the coupling type behaviours were hard coded, it would go some way to explaining the difference in action of the different types. After all, when you look at a coupling statement, apart from the descriptive type word, the rest is basically the same.Buffers and chain couplings, the 'at rest' position would depend on the type of chain coupler in use. The standard 3 link coupler as used on UK goods wagons had a spring behind it which was there to soak up drag forces in the same way that the springing on automatics works. The buffers were there because the coupling being 'loose' couldnt use it's spring to absorb buffing forces. That was the main reason for all the banging and clanking noises from a freight train as it slowed down and the slack ran in.Looking at thisStiffness ( 2e7N/m 0 )
Damping ( 0.2e7N/m/s 0 )
Break ( 1e7N 0 )
r0 ( 0.1 1e9 )
)
CouplingHasRigidConnection ()
)it gives me the impression it is actually meant for a bar type coupling where there is no extension or compression and therefore only one set of values is needed. Maybe 1e9 = infinity.As to the last part, I dont know. The techdocs are rather confusing in this area. Under couplings we have the statement that this section covers couplings, and buffers on those wagons that have them. The next entry is for Buffers, comment, Not used.
mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I have been playing around with the coupling and buffer statements for the past couple of days. My first plan was to find out if buffers work with automatic couplers, they don't.The next stage was to find out what is the major governing force in controlling forced gap enlargements such as when traversing the places such as Cutbank east. Spring and damping do have an effect, but the major player here is the r0 line. The bigger the difference there is between the two figures, the bigger the gap will be, and it will take longer to reclose the gap. r0 also has no effect on the overall size line or the InertiaTensor line that I can find or see. r0 first value set to more than zero also seems to assist the front coupler operation working in conjuction with the stiffness value, too high and you get a recouple, and the second r0 value, if this is too close to the first then the recouple problem resurfaces.The InertiaTensor box seems to describe the coupling boundaries, too long and you bounce off, right size and you have a 75% chance of coupling with the front of the engine. Make it just a tenth shorter and there should be no more difficulty, but this does vary from car to car.The Bounding Box??? If this is supposed to be the crash detection system, why and more importantly, how do cars and engines manage to end up inside each other, and even pass right through.As to values for stiffness and damping, it seem that the sim will accept any value up to 29.9 before the e, and I have been as high as 40 for the value after the e in the damping line. After those points the coupling becomes unworkable. The stiffness line is also the brittleness value, go too high here and you get an automatic coupler break, whereas if you go too low you get elastic for your coupler. Go too low with the damping line values and you will get double elastic, and your train will bounce itself apart. It is my feeling that somewhere in the stiffness, damping, and r0 lines there is a sweet spot that will allow trains to run with true coupler break values, without falling apart on the track, and allow true front coupler operations. However, life is too short to find it, so true break values have to take a back seat.Sniper, just to make sure my little dxthingy isnt masking anything I have wacked the slider all the way to the right so it should now be supersensitive. I have not had one single freeze/lockout so far. mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Interesting. Hope you were knocking on wood when you said that! I've been going at it from another angle, hacked the default.wag to:"0.4 # min coupling velocity"
"3.0 # max coupling velocity"That's twice the default value for min coupling velocity, and fo course no clue what the value actually is. I don't think it's meters per second, cuz 3.0 for max coupling would mean the couplers would work at 3m/s = 10.8kph = 6.5mph, and if you raise the derail buffer force to 800kN, the back coupler just bounces off and don't couple above 5mph. It will couple on at 4mph tho, and minimum back coupler speed is still 0.1mph, not 0.4. It does help with the front coupler most of the time tho, it's harder to couple on, but moving up to touch with the front coupler, then pushing hard against it and backing the throttle off does work. Most cars with the GP38 will couple on at 2.5mph+, and you can uncouple and back away without any screwing around. Higher numbers make uncoupling as easy as the back coupler, but then you got the problem of trying to get it to couple on in the first place. "The Bounding Box??? If this is supposed to be the crash detection system, why and more importantly, how do cars and engines manage to end up inside each other, and even pass right through."Again, it's the size box in the .eng or .wag file that's the actual collision, altho it does tie into that r0 value. Even if the size is right having the r0 value way off somewhere causes cars to pass thru each other. I forget which one I was fooling with at the time I found that, but I think it was the buffers r0, which would contradict your finding that the buffers statement has no effect on automatic couplers. I know KUJU said in the techdocs that the buffers aren't used, but KUJU said a lot of things that have turned out to be BS.How the bounding box fits in I don't know, except that it's supposed to be exactly equal and the two lengths are supposed to add up to the size box (size 21.4 meters, BBox length -10.7 10.7). That don't work for the SD40, too much space at the back coupler and not enough at the front.Yeah, I agree, life's too short to find a sweet spot that will work for all cars and situations, hopefully MSTS 6 will fix this damn thing. Meantime all we really need is something that will work most of the time. I suspect in order to make the perfect bugproof switching activity I'm gonna be stuck uploading some engines and a complete set of cars with all the values tweaked for front coupler ops anyway, no magic bullets here.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi Sniper and gangVery interesting thread got me experimenting also. I didn't see a mention about the parameter I fiddled with in this thread.I tried changing the coupler parameters and at least seem to now get through a location I was having serious problems with. The cars though are at times really bouncing so did a bit more thinking.In the default.wag file I'd been using 7.5ms as the value for "On-track solver timestep" instead of the default 10ms. For the hell of it I changed it to 1ms just to see what happened. The FPS took a serious hit but the car bouncing had stopped!I then tried 2ms and the FPS wasn't too badly hit but there was a bit of bouncing. I next tried 1.75ms and the FPS wasn't too badly hit and there was just a very small bounce visible. I've now got it at 1.85ms and will try an activity or two just to see how badly this new setting might slow the FPS with multiple trains on the KHP2 route.My hardware is an AMD 2100+ with a Radeon 9000 Pro. The CPU is actually coasting along at as a 1500+ right now (summer mode). The parameter I'm fiddling with does seriously impact how much CPU power is needed for MSTS, your mileage may vary.Just thought someone else might want to try this direction of experimentation.GaryG

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi GaryI have been running mine on a timestep of 2.5 for quite a while now, and unable to get rid of that bounce. I just dropped mine to 1.5 and blew through Cutbank East at 75mph without a stretched, uncoupled or broken coupling. Just a hint of movement, which would be normal due to coupling compression/extension whilst moving. I am running the same CPU with 512mb of pc2100ddr and a Geforce4 4400Ti. I am now going to try the softer settings again and see how far down I can get.mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Jun-23-03 AT 04:43 PM (EDT)

"Interesting. Hope you were knocking on wood when you said that! " Still got the headache.This 'ere bounding box thingy. I know that every item of rolling stock is officially supposed to have one, but I have just commented that line of the .sd for one engine and one car in my test train and sure enough the BB doesn't appear with the magic key press, but equally, the train runs with no complaints from the game engine, and the train runs happily through the problem areas, probably because of the timestep change ( see reply to gary ). I'll give the front coupler a whirl without the BB.
EDIT!!! Now I know what the BB is. It is the placeholder for friction values. Engines dont pull without it and coupling does not work without it.I'll go back to the buffers for another look.Just had a look at my min/max coupling speeds and have them set at 0.1 and 5.0. I seem to remember changing them a long time ago, may be why I am getting different results.mervyn@madasafish.com

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

AAACK!!Hee-hee, let this thing die for a while. I'd start another thread, but it looks like nobody knows enough concrete facts to actually write an .eng file manual.0.1 and 5.0 on the default wag?! AAACK!!! The originals were 0.2 and 3.0. 0.2 is bad enough, but 0.1? Almost seems like once you coupled on with the front coupler it would seem like someone had coated it with crazy glue, you'd never get loose.I was playing with two things, bumped the minimum coupling speed from 0.2 to 0.4, and also changed the minimum coupling distance from 30cm to 20cm. Worked real nice on all cars, altho coupling on was a bit more difficult on some cars. You had to either smack them a little harder or push against them, apply the brakes, reverse then throttle then release brakes so you'd accelerate up to minimum coupling speed before you got outside the capture distance. Obviously uncoupling was easy, I went too far the other way and made it too difficult to couple on in the first place. So I changed values again, here's the ones I'm starting new experiments with;"25cm # Minimum couple distance"
"0.8 # Coefficient of restitution for car/car collisions" "1.0N/kg/m/s # Friction when cars dig themselves into banks"
"0.35 # min coupling velocity"
"3.0 # max coupling velocity"Letchya know how it turns out, back to the salt mines.

Alert | IP

[ Home | MSTS Forum | MSTS FAQ | File Library ] Copyright © 2002 by Nels Anderson. All Rights Reserved.