Testing, Testing, will somebody fix the front coupler?

http://www.train-sim.com/dcforum/DCForumID7/1598.htmlI know the Klueless KUJU Klowns are under the impression they fixed it, but all they did was get the brakes to release.Every engine or car (wagon) has a "designated" front and back coupler. Regardless of whether it's in a consist or placed as a loose consist in an activity, part of a cut (string) of cars or all by itself, it's still facing in a given direction, and has a designated front and back coupler. Yeah, I know, aside from some specialty side dumping cars with rotating couplers real life freight cars aren't like that, somebody go tell KUJU.I believe this is one of the missing factors in the front coupler bug, why do people sometimes have problems with the sim locking up or crashing when they use the front coupler? My suspicion is it has to do with the coupler box values combined with all them other wierd numbers in the .wag, .s and ,sd files that define shape, size, and collision properties.

I don't do 3D modelmaking, but I've been skinning some cars for eventual upload, and since even some of the default cars have coupler box problems I test by making up a consist with two of each car type, and reverse every other one.
In the sim it's not apparent which cars are reversed (which is as it should be) until the train starts moving, then if you look closely at the wheels on the reversed cars, they're rotating in the wrong direction, and on curves the trucks pivot the wrong way.I found with the US2chemicar (one of the default cars with incorrect bounding box values) it sometimes refuses to couple onto other cars that are facing the opposite direction, even when using the back coupler of the engine. When using the front coupler, this particular car will frequently trigger the lockup even if it's not the first or last car in the consist.So what I'm doing here is what KUJU should have done in the first place, testing, testing, testing. After starting, I back the train into a siding (BR "loop"), uncouple and run around to the back, then one at a time using the front coupler pull each car off the back and shove it onto the next track until the entire train is reassembled in reverse order. For the most part I'm deliberately smacking them at 4mph, altho some cars I wimped out on hitting them that hard.Only then can I be certain that these particular cars won't trigger the front coupler lockup/crash/send-don't send, since it's such a random, intermittent bug.Don't get me wrong, testing a new loco is important, but it should be done with cars that you know for sure aren't faulty, otherwise you may trigger the bug, blame it on the engine, and change the values from good to bad. Then you test again and don't duplicate the exact same conditions with the exact same cars, and are left thinking the engine is good now. Same thing goes for new cars, test with an engine that you know is good.Hopefully this will shed some light on why the front coupler bug seems to be so random, maybe it isn't random if you combine the front coupler of a good engine with the "designated" front coupler of a bad car.Comments, curses, crying, crowing, careening, carousing?

Alert | IP

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

RE: Testing, Testing, will somebody fix the front coupl, Mark_Blum, Jun-01-03, 10:08 PM, (1) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-01-03, 11:15 PM, (2) RE: Testing, Testing, will somebody fix the front coupl, sniper297, Jun-01-03, 11:48 PM, (3) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-02-03, 08:27 AM, (5) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 08:59 AM, (6) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 09:51 AM, (7) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-02-03, 01:10 PM, (15) RE: Testing, Testing, will somebody fix the front coupl, edwardk, Jun-01-03, 11:54 PM, (4) RE: Testing, Testing, will somebody fix the front coupl, sniper297, Jun-02-03, 09:56 AM, (8) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 10:08 AM, (9) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 10:33 AM, (10) RE: Testing, Testing, will somebody fix the front coupl, sniper297, Jun-02-03, 10:41 AM, (11) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 11:17 AM, (12) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-02-03, 12:30 PM, (13) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 12:48 PM, (14) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-02-03, 01:19 PM, (16) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 02:00 PM, (17) RE: Testing, Testing, will somebody fix the front coupl, edwardk, Jun-02-03, 02:41 PM, (18) RE: Testing, Testing, will somebody fix the front coupl, Brad 110, Jun-02-03, 04:23 PM, (30) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 05:19 PM, (32) RE: Testing, Testing, will somebody fix the front coupl, jleslie, Jun-02-03, 10:32 PM, (37) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 03:05 PM, (19) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 03:26 PM, (23) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 03:37 PM, (24) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 03:50 PM, (27) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 04:10 PM, (28) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 05:13 PM, (31) RE: Testing, Testing, will somebody fix the front coupl, muumiw, Jun-02-03, 03:06 PM, (20) RE: Testing, Testing, will somebody fix the front coupl, kevarc, Jun-02-03, 03:08 PM, (21) RE: Testing, Testing, will somebody fix the front coupl, baldwin, Jun-02-03, 03:39 PM, (25) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 03:42 PM, (26) RE: Testing, Testing, will somebody fix the front coupl, muumiw, Jun-02-03, 04:12 PM, (29) RE: Testing, Testing, will somebody fix the front coupl, plainsman, Jun-02-03, 05:49 PM, (34) SI units (was RE: Testing, Testing, will somebody fix t, quaia, Jun-02-03, 06:11 PM, (35) RE: SI units (was RE: Testing, Testing, will somebody f, plainsman, Jun-02-03, 06:23 PM, (36) RE: Testing, Testing, will somebody fix the front coupl, lfriddle, Jun-02-03, 03:19 PM, (22) RE: Testing, Testing, will somebody fix the front coupl, sniper297, Jun-02-03, 05:21 PM, (33) RE: Testing, Testing, will somebody fix the front coupl, xlspecial261, Jun-02-03, 11:06 PM, (38) RE: Testing, Testing, will somebody fix the front coupl, cyberjim2, Jun-02-03, 11:53 PM, (39)

Conferences | Topics | Previous Topic | Next Topic

"Comments, curses, crying, crowing, careening, carousing? "No.......... only applause Mark
A Southern Railway Fan

Alert | IP

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

Interesting that you should post something about this, I was just getting ready to post on something about the front couplers I just noticed.I'm not a BN or BNSF fan, so I don't normally download locomotives in those flavors, but just for the halibut I downloaded the latest BN (in BN green) SD40-2 #7830 (BNSF7830.zip) by Jean-Louis Chauvin.What caught my eye was the author's mentioning of "new locomotive physics". Whenever I see that, the first thing I do is test the front coupler to see if the author has stumbled on to the "cure".Much to my amazement, this locomotive is the closest thing I've seen to the "cure" for front coupler disease. JLC doesn't mention in his readme if he's the one that came up with the "new" physics, and I haven't tried to find out yet if they are indeed his physics. The lack of a credit to somebody else leads me to believe that they are his own physics.I use my favorite locomotive, my own reskin of Mark Toland's SW1500 into Akron Barberton Belt livery, as my "control" model for front coupler tests. This is because it rarely couples to anything with the front coupler without derailing or giving the S/DS screen.So, I fire up the BN 7830 SD40-2 and aim it at a string of 10 of Bill Bzak's 100 ton hoppers (loaded of course) to see what happens. My SW1500 derails at 2 MPH or higher, and bounces off at 1MPH nearly every time. Once in a blue moon it does manage to hook up at 2MPH, but only at 2MPH. Well, the SD40 hooks up the first try at 2MPH. I try it again successfully at 3MPH, and again at 4MPH. 5MPH derails, as does another 4MPH hit. It'll bang into the hoppers at 2MPH and 3MPH all day long and couple every time.I don't know enough about the .ENG file to pick it apart and figure out the secret, but it's definitely different than my SW1500 file. One noticable difference right off the bat is the lack of a Buffers string in the SD40 .ENG file.Maybe somebody can figure this stuff out before MSTS2 comes out.Just an observation for you to ponder.Jeff L

Alert | IP

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

LAST EDITED ON Jun-01-03 AT 11:49 PM (EDT)

"lack of a Buffers string in the SD40 .ENG file.", I'll have to download that and check it out. Biggest problem with the front coupler on a loco derailing is you gotta hit it harder than with the back coupler to engage, and sometimes hard enough to engage is 0.2mph over derailment speed since the derailment impact speed is lower for the front coupler than the back. That also applies to "designated" front couplers on wagons. One cure is to just barely kiss the car's coupler with the loco's front coupler, then back away fast enough to engage (again, since them Klutzy KUJU Klowns Koded it that way, the front coupler engages at or above a given speed in the "normal" direction, that's why you gotta back away so slowly to keep the front coupler from re-engaging after uncoupling, it's still following the "correct" direction programming.).Personally I avoid all that by changing the derailbufferforce in my engines from 200kN to 800kN, it still derails when I smack into a car with the back coupler at 8mph, lower speeds with the front coupler, and that's "realistic" enough for me (200 ton loco jumps clean off the tracks after hitting empty car's coupler at 4mph, "as real as it gets"?). Possibly the absence of a derailbufferforce cures the problem because you can couple on at 100mph, who knows."Maybe somebody can figure this stuff out before MSTS2 comes out."Somebody mentioned he was at the E3 show where they were demoing MSTS 2-alpha, and he asked the KUJU guy about the front coupler for MSTS 2. KUJU (if this imbecile is any sample) is under the impression that the 1.1 patch completely fixed ALL of the front coupler problems. Honest to god, if there was any way I could get in touch with those idiots, I would volunteer to be a beta tester for the usual ridiculous "no pay, but a free copy of the finished game" conditions (if you actually do SERIOUS beta testing it's dull and tedious, and a free game means about 10 cents per hour if you test it thoroughly!), if I was sure they would actually LISTEN and fix the problems. Worst trouble with all game developers these days, they use "free" beta testers, and they're worth exactly what they're paid since they're more into the "play" part of "playtesting".Sorry, didn't mean to go off on a rant there, JUST MY OPINION, I COULD BE WRONG!I'm really kind of optimistic, MSTS 2 has gotta be better, cuz they couldn't make it worse if they deliberately tried.

Alert | IP

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

Jim,Here's the pertinent files posted so you don't have to go through all the download and examine-it-yourself process. This is from the file beginning down to the "Friction" line, which I believe starting at that point shouldn't have anything to do with the front coupler. The SD40 file:Wagon ( BN7830
Type ( Engine )
WagonShape ( BN7830.s )
Size ( 3.1m 4.768m 20.7m )
Mass ( 177.0t )
WheelRadius ( 20in )
InertiaTensor ( Box (3.318m 4.768m 20.648m) )
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1.2e6N/m 4.8e6N/m )
Damping ( 1.2e6N/m/s 3.4e6N/m/s )
Break ( 1.6e7N 1.6e7N )
r0 ( 5cm 25cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 0.11m/s )
)
Adheasion ( 0.25 0.47 1.8 0 )
DerailRailHeight ( 5cm )
DerailRailForce ( 2.5*177.0t )
DerailBufferForce ( 385kN )
NumWheels ( 12 )The SW1500 file:Wagon ( ABB1501
Type ( Engine )
comment( First Release V1.0 )
WagonShape ( ABB1501.s )
comment( Produced with 3D Canvas V5, by Mark Toland WA, Jan 1 2002)
Size ( 3.301 4.1 13.64m )
Mass ( 124t )
WheelRadius ( 20in )
CentreOfGravity ( 0m 2.2m 0m )
InertiaTensor ( Box ( 3.301 4.1 13.64m ) )

Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m/s 3.4e6N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 20cm 30cm )
) comment( CouplingHasRigidConnection (1) )
Velocity ( 0.1m/s ) ) Buffers (
Spring (
Stiffness ( 1e7N/m 0 )
Damping ( 1e6N/m/s 0 )
r0 ( 0m 1e9 )
)
Centre ( 0.5m )
Radius ( 1m )
Angle ( 0.5deg )
) Adheasion ( 0.2 0.4 2 0 )
DerailRailHeight ( 4cm )
DerailRailForce ( 2.5*124t )
DerailBufferForce ( 200kN )
NumWheels ( 8 )

I've done some extensive testing over the months because the route I'm building is a switching route, and you need a good front coupler for a switching route. I use those full 100 ton hoppers by Bill Bzak because their couplers seem to be made of glass. I don't know if weight might have something to do with it; it appears to me that some of these cars and locos with "realistic physics" are the ones causing the big problems. That's not saying that its the car's fault, but more likely the physics model in MSTS is coded so far out of whack, that if you try to apply "realistic" physics, it causes the whole thing to go south and you get a derailment.Some wagons are more forgiving than others. For instance the default US2EMPLOGGER car for some reason is very forgiving with the front coupler on my SW1500, but the US2Chemicar is not.Another thing I've noticed, is that when I run BBoxEdit V. 1.2 on the SD40 file, some of the box values are out of range. Same thing with the 100 ton hoppers. But, my trusty SW1500 has all in-range values. Kinda blows the theory of bounding boxes causing the derailments. The ones with out-of-range values are coupling fine, the ones with in-range values have glass couplers.It seems that whenever we try to apply logic to all these errors in MSTS (TDB rebuilds, front couplers, etc...) to try to find a fix, we just keep digging a deeper hole and the errors themselves defy the applied logic.The more I think about MSTS 2 and the fact that KUJU is running the show again, makes me think that MSTS 2 will be nothing more than MSTS 1 with different routes.Jeff L

Alert | IP

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

Hi Jeff,
Point 1. Just FYI, compare the values you posted to the V4.5 physics files for a SD40-2? The V4.5 files have not removed the buffer lines, but the settings are the same. Now I am not upset about anything as i specifically note that these files are public domain, and do not ask anyone to give me credit for the physics. I just wanted to set the stage for
Point 2 I strongly disagree that "if you try to apply "realistic" physics, it causes the whole thing to go south". Your inditement is way too broad and does not consider that other things may be causing some of the problems. I don't think trying to get better physics is the problem. Often however, a small problematic error gets embedded in the files and is perpetuated by the use of a default with that error as a template (the extra parenthesis dropping out the brakes on cars is a good example, or the incorrect damping units, or the extra zero in the throttle..need I go on). It was a shame KUJU did not get better beta quality evaluation before it released the sim, and they obviously did not have the needed technical knowledge to understand many of the issues involved in better "realistic physics", but lets not abandon a good process of improving the sims performance on a broad characterization that the physics improvemants are bad. If removing the buffer block (or parts of it?) helps the coupler issue, I will quickly modify my files to accomodate the new information. That is the way the files should be improved, by adding what works and fixing or deleting what does not.
Bob Boudoin

Alert | IP

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

Hi again Jeff,
BTW, try this and report your results please??
Mass ( 111.9t )
WheelRadius ( 20in )
InertiaTensor ( Box ( 3.301 4.1 13.64m ) )Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1.2e6N/m 4.8e6N/m )
Damping ( 1.2e6N/m/s 3.4e6N/m/s )
Break ( 1.6e7N 1.6e7N )
r0 ( 5cm 25cm )
)Velocity ( 0.11m/s ))Adheasion ( 0.24 0.46 1.8 0 )
DerailRailHeight ( 5cm )
DerailRailForce ( 2.5*112.5t )
DerailBufferForce ( 245kN )
NumWheels ( 8 )I also note Jean-Louis Chauvin changed the line :
r0 ( 5cm 25cm )
maybe this is a significant change?
Try this on your SW1500 and maybe we will learn something??
Thanks,
Bob

Alert | IP

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

LAST EDITED ON Jun-02-03 AT 01:12 PM (EDT)

Test results with SW1500:on US2Chemicar, <=2MPH gets a good coupling, >=3MPH gets a derailsame results on Bill Bzak's "100ton Hopper B&O Offset Lime"on USFcarRE2 and US2BNSFcar, <= 4MPH gets a good couple, didn't try it at anything faster than that. Both those default cars DO NOT have the latest physics patch from the file library, but US2Chemicar DOES have the new physics patch applied.Default cars are much more forgiving.EDIT: I did apply the parameters you requested from your post to the SW1500.Jeff L

Alert | IP

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

Jim,I only have one consist that I have been playing around with when testing the front coupling. The problem I have is when I attempt to exit to the menu portion. I will either lock up or get Microsoft's error message. Either way, hitting the escape key puts me back out to the desktop. This problem would happen after doing a simple uncoupling/coupling process. The funny part is that the next day I would perform the same action with the same consist and nothing happened. I never locked up. So far I have only been playing around in explore mode because I find it a hassle to uncouple a train with over seven cars when using the front coupler.Edward K.

Alert | IP

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

Oh, THAT buffer line. Odd, but I don't know what kind of effect it has, the coupler stiffness and damping defines the behavior of that, I don't even know what the "buffer" line does. Here's one of the Jason Diworth SD40s skinned for PO&N from the file library:Coupling (
Type ( Automatic )
Spring (
Stiffness ( 0N/m 5e6N/m )
Damping ( 0N/m/s 1e6N/m/s )
Break ( 2e7N 2e7N )
r0 ( 20cm 30cm )
)
Velocity ( 0.1m/s )
)
Buffers (
Spring (
Stiffness ( 1e7N/m 0 )
Damping ( 1e6N/m/s 0 )
r0 ( 0m 1e9 )
)
Centre ( 0.5m )
Radius ( 1m )
Angle ( 0.5deg )
)Those values are in both PO&N SD40 #12 and #18, and if you couple both engines together, run up to 5mph and apply engine brake, the back engine pushes in the slack, bounces off the front one, rolls out to the limit and rebounds from that, rolls back in again, and if you walk away and come back a half hour later it's still bouncing back and forth.Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m 1e6N/m )
Break ( 2e7N 2e7N )
r0 ( 20cm 30cm )
)
Velocity ( 0.1m/s )
)
Buffers (
Spring (
Stiffness ( 1e7N/m 0 )
Damping ( 1e6N/m/s 0 )
r0 ( 0m 1e9 )
)
Centre ( 0.5m )
Radius ( 1m )
Angle ( 0.5deg )
)That's the corrected lines, note the buffers haven't changed at all, but the values for stifness and damping under the coupling type (Automatic) are increased, and damping changed from (whatever)/m/s to (whatever)/m. That gives a more reasonable and realistic rebound, with the damping actually damping so it don't turn into a perpetual motion machine.Anyway, down near the bottom on yours is the problem: DerailBufferForce ( 385kN ) for the SD40, all default wagons are 400kN, so altho it's silly for an engine it's pretty close. On your SW-1500: DerailBufferForce ( 200kN )is completely prepostrous, altho that's the default value for the KUJU GP38, Dash 9, and undriveable SD40. I suspect the idea was to make coupling more of a challenge, with the back coupler 200kN derails the engine at an impact of 4 to 5 mph so you gotta couple at 3 or slower to guarantee no derailment, and since the front coupler is DIFFERENT (somebody please tell KUJU that it IS different and it's not SUPPOSED to be different!), it derails at much lower speeds. Again, that's why all mine are at; DerailBufferForce ( 800kN ), I did extensive testing with those values using the back coupler;1-4mph, couples
5mph, sometimes couples, sometimes "bumps" and rolls the car without coupling.
6-8mph, bumps car without coupling.
8mph+, derails.Some people just jack it up to
DerailBufferForce ( 1500kN ), but I don't know what that would do, other than take all the realism out of coupling."Some wagons are more forgiving than others. For instance the default US2EMPLOGGER car for some reason is very forgiving with the front coupler on my SW1500, but the US2Chemicar is not."Yup, in addition to refusing to couple to other US2chemicars when reversed, it also triggers the lockup with the front coupler more often than all the other default cars."Another thing I've noticed, is that when I run BBoxEdit V. 1.2 on the SD40 file, some of the box values are out of range. Same thing with the 100 ton hoppers. But, my trusty SW1500 has all in-range values. Kinda blows the theory of bounding boxes causing the derailments. The ones with out-of-range values are coupling fine, the ones with in-range values have glass couplers."Hee-hee, that was the first thing I did, using BBoxedit to fix the US2chemicar, but it had no effect, even with correct values it misbehaves exactly the same. I downloaded that default wagon fix from the file library, and applied all the replacement .sd and .wag files, haven't tried the US2chemicar yet. One thing I did have a strange problem with was the US2graincar, after cloning it for a reskin using the .sd and .wag from the replacement, I got this wierd error from the activity editor consist editor "failed to load PONgraincar.s". Only thing I did to the .s file was uncompressed, changed the .ace file name, saved as a different name, and recompressed it. It worked OK in the sim, and conbuilder didn't have a spaz attack over it, the activity editor consist builder was the only thing that had a problem, and wouldn't display it. So I finally replaced the fixed .sd and .wag files with the KUJU originals, and the AE consist builder stopped having a hissy fit about it. I still don't know what the difference is, the default US2graincar has the fixed .sd and .wag files from that patch and the AE consist builder don't have any problems with that, maybe it don't like my paintjob.Odd thing, some of Teemu's (enocell) replacement wagons have wrong BBox values, and the replacement for the US2chemicar behaves exactly the same as the original.Anyway, while I'm typing this I noticed Bob has tossed in his two cents worth, "I strongly disagree that "if you try to apply "realistic" physics, it causes the whole thing to go south",Bob and I agreed to disagree on this issue a long time ago. One major problem I have is a 2% grade just looks and feels flat with the conversion from a three dimensional world to a two dimensional illusion of a 3D world, so my grades are deliberately exaggerated so that they actually look like grades on that two dimensional monitor. Having 6 Dash 9s hauling 3 boxcars up a 4% grade looks just plain silly, so I use higher power settings than Bob does, and since the geeks made this sim optimized to click and drag pictures of controls with a mouse , they apparently added the keyboard input as an unwanted stepchild. Before Raildriver I was using a Saitek X-36 and throttle, with the keyboard emulation software, and the keyboard input lag even with the Raildriver means I'm usually using 10 to 30% brakes instead of the full range, and the 22 second delay moving thru all the released-running-holding-lapping steps on some of the steamers means I'm in the weeds before I get 10% braking power anyway, unless I want to go into the cabview (which you can't SEE out of on steamers, useless for switching) and slap the regulator shut and dump the air with the mouse .
So I use unrealistic physics that feel real to me given the way I operate the controls. And yeah, Bob (my friend, again I have the greatest respect for you but still disagree on this issue), your physics would be great if it wasn't for the Krappy KUJU Koding and the limitations of the control interface. Hopefully MSTS 2 will have a directX joystick interface so things like Raildriver will work without the delayed response time."but lets not abandon a good process of improving the sims performance on a broad characterization that the physics improvemants are bad", amen to that, keep hacking away we do appreciate it, even if I only use bits and pieces of what you do and sometimes choose a happy medium between your numbers and the originals that works for me.On to Edward, "Either way, hitting the escape key puts me back out to the desktop. This problem would happen after doing a simple uncoupling/coupling process. The funny part is that the next day I would perform the same action with the same consist and nothing happened. I never locked up."That's been the hard part about troubleshooting this, sometimes you get the immediate lockup, sometimes everything's cool until you go to exit.One rule I have, when switching or running backwards, uncouple so that there's nothing coupled on the front of the engine before hitting the escape key to save the activity. Never save with the front coupler engaged. Dunno if it makes a difference, but that's what my Personal Psychic from the Psychic Friends Hotline told me, and it may be a factor."So far I have only been playing around in explore mode because I find it a hassle to uncouple a train with over seven cars when using the front coupler."Try this;http://www.train-sim.com/dcforum/DCForumID3/18308.htmlMight help.

Alert | IP

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

Hi jim,
I am not trying to argue here, but i just wanted to point out that most of the data Jeff cited as working better came from the V4.5 files. I don't fuss if you want steeper grades and more potent locomotives than reality. I just don't think we need to say realistic physics is the cause of a problem it did not create.
BTW, your sample file has a significant error in the damping line.
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m 1e6N/m )
is not correct
Stiffness ( 1.2e6N/m 4.8e6N/m )
Damping ( 1.2e6N/m/s 3.4e6N/m/s )
will solve a lot of problems. Just give it a try before you say it is bad.
Bob

Alert | IP

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

I did a lot of experimenting with the N/m/s. The documentation clearly states that the units should be N/m/s. But, I question most of the documentation and did quite a bit of research on damping. All references, including the PE test reference manual, state that this should be N/m/s. So I changed everything and played with it in the sim. I was able to lower the coupling to a more reasonable 3.5e9 than the 5.9 referenced in most posts as preventing the derail on MP route. I was able to clear the proplem areas with no problems. I plan on reducing the values to 2.5e9 and try it on the problem areas to see what effect that has.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

"I am not trying to argue here", hell, argue all you want, an argument is not a fight. Reasoned arguments cause me to change my mind all the time, provided the preponderance of evidence is on the other side. I'm not married to any particular theory, just the one that works best at the moment."BTW, your sample file has a significant error in the damping line.", yeah, that first one is the bouncy one, I think leesome did that, the second was a fix suggested by one of you physics wizards, I forget who. It worked tho, stopped the "slinky" effect."Just give it a try before you say it is bad", damn right, I'm adventurous, I'll try anything once, even YOUR mods! I just now D/Led your physics 4.5 (again I'll give anything a shot if I'm in the mood!), and indeed the values for the SD40 from physics 4.5 match the one Jeff is talking about, except the buffer line was cut out for whatever reason. Just curious, with the derailbufferforce values you're using (TOO LOW!!! ), how well does the front coupler work for you?

Alert | IP

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

Sniper, I am looking at the derail buffer force and am preparing a very long post on this. From my first run of calculations, I haven't double checked them yet, show a huge number, more than an order of magnitute greater than what the sim uses. This is leading me to believe that there is some type of calculation in the sim that takes into consideration the derail forces, weight, and velocity of both the engines & cars in motion AND the derail forces and weight of the cars & engines that are about to be coupled to.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

Bob,Don't get me wrong here, I wouldn't have a clue about what is V4.5 and what is not. I don't drive trains around as much as I would like since most of my time goes into route building, so I have no idea what the the difference between a V4.5 loco and a non V4.5 loco is. All I did was download a locomotive that claimed "new physics" and tested it. I'm not looking to credit or discredit an author of anything or point fingers at anybody for "something bad", I just want my front couplers to work.Anyway, back to the war..."BTW, your sample file has a significant error in the damping line.
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m 1e6N/m )
is not correct
Stiffness ( 1.2e6N/m 4.8e6N/m )
Damping ( 1.2e6N/m/s 3.4e6N/m/s )
will solve a lot of problems."I know what a Newton is. "A unit of force equal to the force needed to accelerate 1kg 1m/s/s." Well, 1m/s/s is an expression of acceleration, or changing velocity. The expression "1.2e6N/m/s" is an expression of constant velocity. If a Newton itself is a representation of changing velocity (acceleration), then is it correct for it to be used in a formula for constant velocity? (1.2e6N/m/s) Or am I as confused as I think I am?So, I can see where changing Damping ( 1e6N/m 1e6N/m ) to Damping ( 1.2e6N/m/s 3.4e6N/m/s ) would be a significant change, because "1e6N/m" is not an expression of constant velocity but "1e6N/m/s" is. At least I think it is.If I read this right, that little "/s" put in there drastically changes the formula. I am curious how many other lines should have that expression, and is that stuff even right to begin with?Jeff L

Alert | IP

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

I am research how all the lines interact and as far as I can tell, the damping lines are the only ones that should have the /s since they are the only ones involving springs. The real problems I am having relate to the determination of N. This unit is caculated with acceleration and I do not find how the sim determines it and how these values were caculated. Is a constant used for acceleration? I need to load all of these numbers from each eng and wag file into a spreadsheet to see if I can spot a trend. Anyone want to do that?Another thing that really bothers me is the use of US tons as mass. Why here when all the others are SI units.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

LAST EDITED ON Jun-02-03 AT 01:25 PM (EDT)

A Newton is not always going to have the same value. It all depends on the coefficient of friction between the surface the 1kg of mass is sitting on. So, the higher the coefficient of friction between the 1kg of mass and the surface it's resting on, the more force will be necessary to accelerate it to 1m/s/s (one meter per second per second)Even though a railroad car is sitting on wheels with bearings on the axles, there is still going to be a coefficient of friction. The only way to get a 0 for coefficient of friction would be suspended in a vaccum, not resting on anything.Is this getting deep or what? EDIT: To represent the force of a compressing spring acting on velocity, the value would actually be a negative acceleration value. Speeding up is positive acceleration, slowing down is negative acceleration. Maybe that's where the problem lies - the values for springs need to be negative values to represent the "slowing" effect a spring will have on velocity? That might explain why cars are derailing, instead of slowing the collision, it is actually multiplying it, thus exceeding the derailbufferforce or something which causes the derailment....Jeff L

Alert | IP

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

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

Hi Jeff,
You missed my point about the Version 4.5 physics files (I thought I was pretty good at communication skills, but I guess I was wrong). I was not expecting you to know what was in the V4.5 files. What I was trying to point out was that the data which seemed to make the coupler work better, largely derived from a set of files which claim to make the physics more realistic. Only a breath later you suggest it is realistic physics which is causing the problem, and I just wanted to point out that contradiction.
As a scientist and engineer, I was hoping you could try the suggested modifications to your problem file, and report if it helped or made things worse. I have spent a lot of time trying to improve the .eng files, and if there are further improvments we can make in this version of MSTS, I would surely like to make them. The discussion on your theories of the problem may be interesting, but I think we can learn more by trying some of the suggested approaches before we propose a new theory, after all, you suggested these parameters seem to improve the action in the locomotive you tested. Let's see if it is repeatable in your problwm SW1500? I certainly would not want to pontificate about route building techniques, until i had tried some of the methods of the experienced route builders.
Bob

Alert | IP

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

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

Here is something to think about if nobody thought about already. Using Svante's articulates as an example, if a car is suppose to have two different couplers, than two entries are needed. The only question here is what entry goes with what coupler? If a car is only suppose to have one type of coupler than one entry is needed, but what if you used two entries with different settings for each? Would the settings be read as two different entries or would they still be read as one. If read as different entries, than you can tweak the front coupler w/o messing with the rear since it's the front that is causing issues.Edit: In Svante's articulate #1, the bar coupling entry is first than the automatic entry. In car #5, the automatic entry is first than the bar coupling entry. Is this correct?Edward K.

Alert | IP

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

>What I was trying to point out was that
>the data which seemed to make the coupler work better,
>largely derived from a set of files which claim to make the
>physics more realistic. Only a breath later you suggest it
>is realistic physics which is causing the problem, and I
>just wanted to point out that contradiction. I am not sure I see a contradiction here. In the first place, the physics files don't supply physics at all -- they supply a set of _values_ to the KUJU physics. What is being supplied is more realistic values, the physics remain the same. With that point firmly in hand, consider the recent release of "real" paint chips. Almost the first thing we find out is that the "real" RGB values often do not display correctly, due to how the graphics program/monitor used is set up to render those RGB values into colors on the screen. Effect: sometimes the "real" values look less correct then a "tweaked" set of values. Same same for Kuju physics. We do know how physics in the Kuju world works (although it seems safe to say that it is NOT an exact analog of the real world). There seems no reason to assume that more realistic values applied to known unrealistic physics will automatically and always give a more realistic result. I'm all for getting the most correct values possible as a point of departure, but I am alive to the possiblity that these values may well have to be tweaked in unrealistic directions to accomodate the vageries of the Kuju physics.
Brad Meyer

Alert | IP

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

The obvious contradiction is that in one sentence the ame "new physics" that seemed to make things better, were being broadly defiled as the source of the problem, without realizing the "new physics" that worked were from the "realistic physics" that caused the problem. All I am saying, is don't knock it till you try it.
Bob

Alert | IP

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

Bob, we're on the same team here. I'm not suggesting for one second that there's anything wrong with any of the physics you have researched. I don't know enough about it to be qualified enough to make a statement like that. All I'm saying is that if the KUJU system is broke to begin with, if you try to apply something that is realistic and correct as far as scientific principle goes (your physics values), then it's quite possible it will have negative effects in the output (derailment in the sim) because the broke KUJU system doesn't like the realistic numbers. I think Brad understands what I'm trying to say. If it sounded like I was trying to say that your realistic physics were bad, then I apologize for making it sound that way, that was not my intent at all.Also, see my post #15 above for the results of my test. It was just a quick test, only done on a few cars. Kevin - Is deceleration not represented by a negative number? I'm not a scientist, engineer or physicist, but I seem to remember from somewhere that deceleration is negative and acceleration is positive. That's what I was getting at by suggesting that the "braking" effect caused by 2 cars colliding with a set of couplers between them might be better represented by a negative value.Jeff L

Alert | IP

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

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

A newton is a Newton, you cannot change what it is, only the value. Fricton is important, but not in this case as the object to be couple to is at rest, momentum is more important in this equation. That is the problem, we have different things; energy, momentum, and friction; and we do not fully understand how the sim takes these different factors into the physics calculations.Am example:
I am using one car and engine for this example as the more you add the more complex this gets.
A engine (111.9t or 233800lbs) is going 3mph(4.4ft\sec)at the moment of impact with the car at rest. Now according to Physics - F=ma. where F is lbf, mass is in pounds and a is acceleration. But at the moment of impact a=0 so F=0. So where did the designers get their numbers from? Unless we know how this is handled within the caculations of the sim it is almost impossible to caculate the correct values for most of the Newton values in the eng file. But we know that if you hit the car to hard with the engine, it derails. We also know that if we are going to slow, it will not couple.
I am looking to see how, inertia, linear momentum and linear impluse may figure into this. I really think this is very important in these calculations.No, it would not be a negative number. The positive number represents the dissapation of energy. A negative number would be adding energy to the system.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

I disagree a little this time Kev. At impact (I won't call it a moment because I want to take it through the process), the coupler starts to compress the spring. Depending on the stiffness, the spring will flex or not (given force will move it so far,hence N/m). The damping does not control the extent of the flex, but affects the rate at which it happens. In a simple example, take a screen door with a spring. You push a little on the door and it opens. If the spring is the same strength as a ball point pen spring, you will probably break it and the door will fly open way too far. If you have the spring as strong as one from a 1958 DeSoto (or Studebaker if you prefer), it will not open very far, as you are not strong enough to move it very far. Now put the correct spring back on the door. If you open it in air, the spring behaves as you normally expect. Now put the system under water and the door will still open just as far, but you can't swing it open as fast. Now put the system in a vat of Karo syrup. You will still be able to open the door, but it may take a while to get it open. This is damping.
For your example, the locomotive and coupler press against coupler and car with a force which moves the spring a certain distance. That movement dissipates the kenetic energy, and the system reaches equilibrium and the car is coupled. If the spring does not damp this process enough, the energy will be transferred too rapidly into the car. Thus a and F are not 0 until after the system has come to a stop.
Bob

Alert | IP

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

I have to disagree with you. At the moment the couplers touch, a=0 and when they come to rest a=0 again. But between those two points there is decelleration dissapating the energy.Putting the system in Karo is not damping. All that is doing is increasing the force required to move the karo out of the way. Extra force is required to overcome the density and viscosity of the Karo It is not dissapating the energy of the spring. A shock absorber is an example of damping.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

Sorry Kev, but at the moment they touch a does not equal zero. A is zero inside the coupler just before they touch, but as soon as they make contact, the spring starts to move backwards, with a finite a.
Yes Karo (ignoring the stickiness, but just using it as a viscous fluid), is a good example of damping. The actual force needed to move the door will not be greater, it will just take a lot more time for the viscous fluid to move out of the way. That is how a shock absorber works, a plunger or piston moves up and down inside a tube filled with a viscous liquid.
Bob

Alert | IP

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

No Bob, it is not. While they appear to be the same they are not. Opening a car door in a vat of karo does not reduce the rate of ocillating motion of the spring while the shock increases the rate of the reduction of the ocillating motion.
http://www.plus2physics.com/vibrations/study_material.asp?chapter=2Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

Thought we were talking about a screen door with a spring, not a car door. The screen door would be the same thing under that case, just differnet kinds of oscillating motions, one swinging back and forth, one compressing and uncompressing.

Alert | IP

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

KevarcHow about a metric ton (= 1000 kg) Muumiw

Alert | IP

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

Yeah, I am really think about that, but that throughs all the revised physics out the window. Look at the default cars and see what their values are, bet the come out as US tons.Kevin Arceneaux
DEFAULT IS FOR DUMMIES
Lone Wolf Activities Forum on www.3DTrains.com

Alert | IP

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

From the techdocs
Mass Mass of the wagon in tonnes – supply a number followed by “t”, e.g. 109.47t.
Note that these are 1000kg tons. Not US tons.Might be useful to compare real world with the sim.mervyn@madasafish.com

Alert | IP

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

Actually, they used metric tons, although sometimes with confounding lack of understanding. For example, they use a weight which is much too light for the Dash 9, which starts at 185 metric tons unballasted. Their weight is about right for an unballasted GP38-2, 113.4 metric tons (250,000 pounds). Most mainline roads run a SD40-2 ballasted between 387,000 and 390,000 pounds(coal versions get up around 415-417,000 pounds), in other words 175.5 to 177 metric tons.
Bob

Alert | IP

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

I got some info for Dash 9 from the GE site:
- The GE Dash 9-44CWTM Locomotive –
- Designed and Built for the Burlington Northern Santa Fe Railway
- Length: 73 ft., 2 in.
- Height: 15 ft., 10 in.
- Width: 10 ft., 3 in.
- Weight: 415,000 lbs.In metric tons that's about 188,5 t
In US tons 207,5The MSTS Engineers handbook has it
190,5 metric - 210 USThe eng-file has 155 tNot a very close match here.What is interesting is that Acela HHP and Kiha 31
have correct figures as far as I can check..

Alert | IP

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

Hi,
I can understand the difference between an unballasted 408,000 pound Dash 9, A 415,000 BNSF Dash 9, and a heavily ballasted 420,000 Dash 9. I can't possibly see a Dash 9 of 341,717 pounds????? This just is another example of KUJU having less appreciation for freight service, and putting all their focus on passenger service. I think they thought the folks using the sim would only want the SD40-2 setting on a siding as scenery. Can't figure why they would botch the Dash 9 as badly as they did??
Bob

Alert | IP

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

I don't know if at Kuju they know physics better than train engineering... :-DDamping effects, which are present in every real spring and are in particular deliberately assigned to shock absorbers, are a force directly proportional to the speed of motion. The force of the fluid against the piston is directly proportional to speed.So, in SI,
- force is expressed in newtons (N)
- speed is expressed in meters per second, that's to say m/sforce per speed, alias force/speed, is then N
-
(m/s)nicely formatted as a mathematical fraction.Maths fans know that's equivalent to N · s / m that's to say Nm/sSo Kuju expression is, let's say, not well-written, it's a little ambiguous. It should be written N/(m/s) (but maybe parenthesis are a problem for the .eng parser...) or Nm/s. However, it's indeed true that seconds enter in the expression.N/m is, instead, the elastic coefficient of a spring, and tell us with how many newtons the spring pushes or pulls if we elongate it one (!) meter. Obviously normally it's a huge value (and most times calculated, since it's impossible to elongate a normal spring one meter without destroying it).About the signs, normally they're negative, because the forces are opposing to the movement direction, but in many cases just the absolute values are indicated as a simplification.Now I'll make a consideration. That's not the whole real picture, because it doesn't account for the slack present in freight trains. The coupler starts to engage before the buffers play a role. Yes, buffers run into each other, but a little later on. Only in passenger trains you can simplificate, since there is pratically no slack because less weight is involved and confort is important.The real picture is that buffers are involved when cars run into, while couplers are involved when cars tear apart. Moreover, there is the slack to account for between the two actions. Both actions have a pure elastic (spring) component and a damping one. Multiply that times the number of couplings between cars present, taking account for the fact that, for each coupling, the two cars involved may be different (actions are always reciprocal and depend on both cars), and taking into account that you have to consider the cinetic energy continuously exchanged between the cars along the train. Not easy indeed!
About braking levers parameters, I also like to increment the responsiveness of the keyboard. Expecially with the steamers...
For me, they're more realistic. In fact, I wouldn't move the lever so slowly. Indeed, they're a compromise, because the keyboard is a whole-or-nothing interaction, we haven't a real lever. Maybe in MSTS 2, joystic-like peripherals will hopefully be supported. Clearly, in reality I would move the lever very fast until the lapping area and modulate when starting to apply or release. But after my modification keyboard commands are already usable. I keep HUD (F5) display open, and I drive steamers in S-F1 outside view. Obviously I've corrected Flying Scotsman and Gölsdorf outside views so that I face the right side (to the left). Annoying that I've to change it manually again to drive on American routes. They should make the outside view depending on the track. We need two outside views, left and right. Left view should be selected when driving on a track with signals on the left, and vice versa. Of course, it would be nice too if I could change loco when I have to go backwards or perform similar tasks. Maybe one day...Umberto

Alert | IP

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

Hi Umberto,
I don't find anything to dispute in what you discuss. I do want to point out though that the buffer section seems to be out of service as to it's impact on the sim. Seems as though KUJU had more equations than they had time to code into the sim. Curve resistance is another of these frustrating inoperative lines. We will just have to do our best with what we were given, and hope it gets fixed in version 2!
Bob

Alert | IP

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

"Yeah, I know, aside from some specialty side dumping cars with rotating couplers real life freight cars aren't like that, somebody go tell KUJU."
Just for the sake of technical correctness here, I have been reading some of the BNSF manuals, and they actually devote several pages in teaching brakemen how to tell which end of every type of freight car is the "Front".
Inquireing minds want to know. Larry

Alert | IP

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

LAST EDITED ON Jun-02-03 AT 05:23 PM (EDT)

Well, there is that. Funny you should bring it up, I've been repainting boxcars. Most have only a single end panel that gets skinned to both ends, and one side panel that goes on both sides. This 40' Roger von Ahrens model has one side panel but two different end panels, so I decided to paint "one" and "two" temporarily on the ends to see what difference it made. Note that there is a brakewheel on one end of the car, and as far as I know all freightcars only have one handbrake wheel, usually on one end. Got nothing to do with the couplers tho, the dump cars have to be oriented in a certain direction to work, but standard freight cars can be turned either way. I dunno why the BNSF manual would even screw around with which end is which, turntables used to be a lot more common when steamers were the norm, since a steamer running tender first is more prone to derailment. Diesels used to run long hood first because that's what the old teakettle drivers were used to, nowadays they run short hood first, and there have been center cabs over the years. Mostly road engines are MUed with the lead and trail engines facing opposite directions, so either end is the front, just change cabs.But even if a BNSF employee has which end is front tattooed on his forehead, I doubt like hell regular freight cars are rolled onto a turntable, wye, or ballon track for the specific purpose of getting the "front" of the car facing front, there's no real point to it, the couplers and air brake hoses work the same either way.It does matter in the sim tho, the front and back couplers are definitely different. Those of you who have PO&N6 and haven't hacked the undriveable SD40s yet try this;Start at Johnsburg, back into the yard and grab some cars. Pull up and back onto the main, until clear of the wye switch. Change the wye switch left, head up the South Pass. Stop at the helper shed, uncouple the train, and back into the helper shed. Pull the Dash 9 on the straight track out, back it into the curved track to get it out of the way. Go back to the straight track, grab the undriveable SD40 that's reversed, so your back coupler is connected to the SD40s back coupler. Pull out, throw switch, back down on the train (brakes, it's on a grade) at 2mph. Crash! That's because of that 200kN value in the .eng file, the front coupler of the SD40 derails at a much lower speed. Open the activity editor, find that SD40, and click on it, "toggle start direction". Save, exit, try the same excercise again. Now you can bang into it at 4 or 5mph without derailing, because the back coupler isn't as touchy.Having a hard time following Kevin's argument about the Karo syrup, fluid damping is fluid damping, the laws of hydraulics are gonna apply with any fluid, and the thicker it is the more damping effect it's gonna have. Using the car door opening as an example, fling it open in air and watch it bounce back and slam, fling it open (with an explosive, perhaps, to get enough "fling" into it) in Karo syrup, and the fluid it's moving thru is gonna slow it way down so it wouldn't even hit the stop, let alone bounce back.While we're on the subject, idle curiousity, anyone got any dope on what coupler boxes use for springs & shock absorbers, how they're maintained, all that stuff?

Alert | IP

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

Just a couple observations;Cars do have "different" ends, however they are not called the front or rear. They are the "A" and "B" ends. The B end is the brakewheel end, making it simpler to remember. We use this to deferentiate which end of the car has a problem.Also, occasionaly cars are loaded in such a way they must be unloaded from one side. You see this fairly often with boxcars.Finally, I would like to know how to simulate the typical, non cushioned, draft gear. Most freight cars have little if any damping in the draft gear. They instead use a wedge design. If you watch a freight train start or stop, watch the couplers. You will see little if any movement of the drawbar. There is a little slack in the knuckles themselves, and a little, basically undamped, in the drawbar/draftgear. A total of 3 to 6 inches for each coupling between two cars.This undamped style of coupling is what makes running a train difficult at times. You don't have a bunch of cushioning protcting your knuckles. If this could be simulated properly, it would greatly improve the realism of the sim. For the hard core guys that want to try and do it like the real thing anyway.I've run with break values at 1.1 and with the cushioned draft gear it is still not realistic. Shoving the train backwards, a 14,000 ton grain train was what I was using, and then quickly going forward did not result in a busted knuckle. NOT realistic.It should also be noted that cushioned draft gear is only cushioned for buff forces. When you stretch them, they slam against the stops.Todd Jones

Alert | IP

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

Hey--What about an "Invisocoupler"!! If it worked for sounds on AI trains--then why not front couplers on any engine??? Or how about running 2 locos as 1 engine with both facing each other. that way both rear couplers are a front and a rear with same coupling values??
I'm no "techie" in this area, but what the heck!! Jim

Alert | IP

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