Train-Sim.Com
Microsoft Train Simulator

Front coupler bug revisited

Notice to all visitors and members of the Train-Sim.Com message forums:
If you plan on using a signature banner in your posts, we would like to remind you that there is a maximum size for banners. That maximum is 450 pixels wide by 120 pixels high, and not to exceed 25k. Your compliance is appreciated. FORUM RULES Problems? There are two common reasons for problems with logging in and posting messages. The first is that you are running a firewall that prevents your messages from being sent to the server. The other is that you have cookies disabled; the DCForum software requires cookies to work properly.

Previous Topic | Next Topic

Printer-friendly copy Email this topic to a friend

Reading Topic #18876

Charter Member · 4950 posts

LAST EDITED ON Jul-02-03 AT 00:25 AM (EDT)

Those of you unaware, in the beginning there was MSTS, and trainfans saw it was good. Then all the switching/shunting fanatics saw it was not so good. When you attempted to couple on to a loose consist with the front coupler, the brakes on the cars wouldn't release.MS/KUJU came out with a patch for that;http://microsoftgamesinsider.com/TrainSimulator/NewsAndFeatures/InsideTrainSimulator/New_Microsoft_Train_Simulator_Update_4-18-02.htmAnd that fixed the brake release problem, so you could couple on to a cut of cars and pull it backwards. For switching purposes that wasn't near enough, since it was very difficult to get it to uncouple, and using it often led to program crashes, lockups, and send/don't-send love letters to Uncle Billy. MS/KUJU is oblivious to this, the readme says "the front coupler is now functional", altho it only fixed one of many problems.There are a number of factors causing the problems remaining, the primary one is all the physics for the game are geared toward the back coupler, and the front coupler is an unwanted stepchild. Engines obviously have a front and back end, but even cars have a "designated" front and back coupler which causes them to behave differently. A reversed car or engine in a train will have the wheels rotating in the wrong direction, and on curves the trucks pivot the wrong way. The coupling/uncoupling is also affected by this, certain cars and engines that are not perfectly centered will have problems coupling onto one end or the other. The US2chemicar is a good example, and so is the piggyback trailer flatcar.Coupling takes place only when the cars/engines are moving in the expected direction for the back coupler, so when you're moving toward a car with the front coupler of the engine, what actually happens is it hits the coupler and bounces backwards, and couples on the rebound. Derailment also happens at much lower speeds when using the front coupler.So here's my latest hacks;http://www.train-sim.com/dcforum/User_files/3f0259991808590c.zipThere are two modified versions of Bob's physics 4.5 GP38s in there, as well as a hack to the default.wag file that should work for any engine. The default.wag hack is the most important, with all the engine/car combinations I've tried so far it makes uncoupling easier and (knock on wood) so far seems to eliminate the lockups.The one thing it doesn't fix is the coupler window, once the front coupler engages you're limited to the first 7 cars in the train displayed in the window, so you still have to uncouple long strings in sections.There's a readme included, but basically you unzip to the \Train Simulator folder, answering yes to overwrites (backups of the original files plus batch files to restore them are included), then go into the \Trains\Trainsets\Default\ folder and run the hackit.bat to change to new values, restore.bat to restore the old default.wag. For the default GP38, \Trains\Trainsets\GP38\ folder, run passview.bat, which will give you the geep with a #5 passenger view on the left side, or nopass.bat, which gives the same geep with no passenger view for those who prefer the cupola of the caboose for a passenger view. Both have increased derailbufferforce values and throttle notches optimized for switching/shunting activities, otherwise they're physics 4.5 throughout. Run restore.bat to return to the original KUJU 1.2 GP38.Feedback, don't be shy. Less lockups, more lockups, (Luck be a Lady Tonight) no lockups? Easier/harder to couple/uncouple? Does it fix the infamous Cutbank Coupler Curse on Marias or not?

Alert | IP

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

RE: Front coupler bug revisited., DCRR1, Jul-02-03, 10:26 AM, (1) RE: Front coupler bug revisited., fixin2, Jul-02-03, 04:26 PM, (4) RE: Front coupler bug revisited., Coonskin, Jul-02-03, 12:35 PM, (2) RE: Front coupler bug revisited., rgh69, Jul-02-03, 01:38 PM, (3) RE: Front coupler bug revisited., sniper297, Jul-02-03, 07:10 PM, (5) RE: Front coupler bug revisited., rgh69, Jul-02-03, 08:39 PM, (6) RE: Front coupler bug revisited., sniper297, Jul-03-03, 07:11 PM, (7) RE: Front coupler bug revisited., drjoe, Jul-04-03, 11:00 AM, (8) AACK!!!! OHIO RAILS AGAIN!!!!, sniper297, Jul-04-03, 12:25 PM, (9) RE: AACK!!!! OHIO RAILS AGAIN!!!!, drjoe, Jul-04-03, 02:49 PM, (10) RE: AACK!!!! OHIO RAILS AGAIN!!!!, robertreedy, Jul-04-03, 03:20 PM, (11) RE: AACK!!!! OHIO RAILS AGAIN!!!!, sniper297, Jul-04-03, 04:11 PM, (12) RE: AACK!!!! OHIO RAILS AGAIN!!!!, baldwin, Jul-04-03, 04:36 PM, (14) RE: Front coupler bug revisited., ckawahara, Jul-04-03, 04:36 PM, (13) RE: Front coupler bug revisited., sniper297, Jul-04-03, 09:24 PM, (15) RE: Front coupler bug revisited., ckawahara, Jul-04-03, 09:35 PM, (16) RE: Front coupler bug revisited., stationmaster, Jul-04-03, 10:18 PM, (17) RE: Front coupler bug revisited., baldwin, Jul-05-03, 03:26 PM, (22) RE: Front coupler bug revisited., Stooopid_person, Jul-05-03, 05:19 AM, (18) RE: Front coupler bug revisited., sniper297, Jul-05-03, 11:03 AM, (19) RE: Front coupler bug revisited., ckawahara, Jul-05-03, 11:58 AM, (20) RE: Front coupler bug revisited., Stooopid_person, Jul-05-03, 12:19 PM, (21) RE: Front coupler bug revisited., OTTODAD, Jul-05-03, 05:31 PM, (24) RE: Front coupler bug revisited., RevnJeff, Jul-05-03, 04:05 PM, (23) RE: Front coupler bug revisited., sniper297, Jul-05-03, 10:07 PM, (25) RE: Front coupler bug revisited., Stooopid_person, Jul-05-03, 10:32 PM, (26) RE: Front coupler bug revisited., RevnJeff, Jul-06-03, 01:10 AM, (27) RE: Front coupler bug revisited., sniper297, Jul-06-03, 01:59 AM, (28) RE: Front coupler bug revisited., Stooopid_person, Jul-06-03, 11:45 AM, (35) RE: Front coupler bug revisited., baldwin, Jul-06-03, 06:08 AM, (30) RE: Front coupler bug revisited., ckawahara, Jul-06-03, 11:44 AM, (34) RE: Front coupler bug revisited., heffed, Jul-06-03, 04:10 AM, (29) RE: Front coupler bug revisited., sniper297, Jul-06-03, 09:29 AM, (31) RE: Front coupler bug revisited., sniper297, Jul-06-03, 10:48 AM, (32) RE: Front coupler bug revisited., Bing, Jul-06-03, 11:20 AM, (33) RE: Front coupler bug revisited., baldwin, Jul-06-03, 04:16 PM, (36) RE: Front coupler bug revisited., sniper297, Jul-06-03, 06:16 PM, (37) RE: Front coupler bug revisited., sniper297, Jul-06-03, 09:25 PM, (38) RE: Front coupler bug revisited., Coonskin, Jul-07-03, 03:15 AM, (40) RE: Front coupler bug revisited., baldwin, Jul-07-03, 03:11 PM, (44) RE: Front coupler bug revisited., Coonskin, Jul-07-03, 09:07 PM, (48) RE: Front coupler bug revisited., heffed, Jul-07-03, 01:20 AM, (39) RE: Front coupler bug revisited., blattan, Jul-07-03, 10:14 AM, (41) RE: Front coupler bug revisited., sniper297, Jul-07-03, 10:54 AM, (42) RE: Front coupler bug revisited., jleslie, Jul-07-03, 01:08 PM, (43) RE: Front coupler bug revisited., jtsdadinaz, Jul-07-03, 08:18 PM, (45) RE: Front coupler bug revisited., rgh69, Jul-07-03, 08:49 PM, (46) RE: Front coupler bug revisited., sniper297, Jul-07-03, 09:02 PM, (47) RE: Front coupler bug revisited., jleslie, Jul-07-03, 10:32 PM, (49) RE: Front coupler bug revisited., sniper297, Jul-07-03, 10:56 PM, (50) RE: Front coupler bug revisited., Brad 110, Jul-08-03, 08:00 PM, (51)

Conferences | Topics | Previous Topic | Next Topic

Member since Apr-17-03 · 48 posts

RE: Front coupler bug revisited.

Sniper;
Excellent discourse on front couplers. Have downloaded suggested fix and will post results. One question for you. A while ago you did a post on how MSTS reads characters, like l/c 'd' before cap 'D' etc. I spent an hour looking through the archives and couldn't locate it. Do you recall the Post Name or approximate date? I like to list my locomotives by class then road name then number. They come out perfect in Conbuilder but are so disjointed in the MSTS locomotive list. I am hoping your essay will help.
JohnPS: my Trash 80 died at the age of 20 years !!!

Alert | IP

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

Charter Member · 81 posts

RE: Front coupler bug revisited.

John,
hope this is what you are asking. Think this is how your files will be listed#_file = special characters
&_file
0_file (zero) = numbers
1_file
2_file
3_file
9_file
A_file = caps
B_file
C_file
Z_file
a_file = lower case
b_file
c_file
z_file

you can experiment with this in Winders Explorer

Alert | IP

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

Member since Aug-1-02 · 2522 posts

RE: Front coupler bug revisited.

Sniper:Looks like some good detective work you've done there. I would help testing, but am up to my neck in other MSTS projects. Hopefully the troops will test/report for you... and the input will be positive.Andre

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Uh, right,
http://www.train-sim.com/dcforum/DCForumID3/18620.htmlWas that thread. Caps before lowercase, not lowercase before Caps. And as fixin2 and Phil pointed out, punctuation also takes precedence, " zebra" would precede "1AAA", since the space as the first character makes it king of the sortorder. Don't ask me what the activity editor's consist editor uses, seems to be a shotgun that scatters them to hell and breakfast without regard to names, filenames, or folder names. I gotta look up in the attic now, I think I still got my TRS-80!"any change on how to transfer this to an European engine?" They got trains in Europe? Seriously, the default.wag file doesn't specify coupler types, so I'm pretty sure all engines and cars regardless of nationality will be affected by the hack to default.wag. The only change in the default.wag is doubling the collision threshold velocity from 0.05 to 0.1, which makes it slightly less touchy. My suspicion for a while now is the lockups/crashes are caused by the derailment subroutine kicking in when the front coupler attempts to engage but can't do it going in the wrong direction. As for the derailbufferforce and throttle notches in the GP38, those aren't part of my "MSTS 1.3 (unofficial) patch", just an added enhancement. The real key is that default.wag file which affects all engines and wagons. You could hack a European diesel (or any diesel) the same way, if it has 8 throttle notches they're always divided equally by 8, which Plainsman says is not prototypically correct. The lowest throttle notches on real diesel-electrics have less percentage of power and are closer together, for the same reason I made them that way, better low speed control. I never asked, but I suspect the physics gurus didn't put that in cuz they don't have the precise values yet, me being a heretic I just went with TLAR values.Here's a wierd example of how the front/back couplers are screwed up by the sim, Johnf's 0-8-0 switchers coupled back to back.Front coupler bug revisited – image 2On add-on steamers, since engines and tenders in the US are generally drawbarred together, the .eng and .wag files have two coupler entries. The engine.eng has front coupler automatic and back coupler drawbar, the tender.wag has front coupler drawbar and back coupler automatic. Coupled into a train backwards, the tender wheels rotate the wrong way, but the drivers on the engine rotate the correct direction. However, the front & back couplers of the engine swap ends, since the front coupler of the engine is now the "designated" back coupler, it's now a drawbar and can't be uncoupled from the train.Front coupler bug revisited – image 3Back coupler of the engine now being an automatic, you can uncouple the tender.Front coupler bug revisited – image 4Nose to nose same thing, front/back couplers swap ends, once coupled they can't be uncoupled.

Alert | IP

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

Member since Apr-6-03 · 299 posts

RE: Front coupler bug revisited.

Front coupler bug revisited – image 5

Righto Sniper, I'm going to try this on an European engine.
(first I need to read all of this a few times)Thanks!

Best regards,
Richard.

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Lost this thing for a minute."first I need to read all of this a few times", maybe I shoulda simplified it, I do tend to get blabby! Just got off the phone with an old geezer who's not too bright about computer stuff anyway, so if I can make him understand it then anyone can.
Download this;http://www.train-sim.com/dcforum/User_files/3f0259991808590c.zipExtract or copy or move the packed \Trains folder to your \Train Simulator folder, answer yes to overwrites if prompted. That won't actually overwrite anything, you next have to go into the \Train Simulator\Trains\Trainset\Default folder, and double click on hackit.bat. That's it, it globally changes the collision threshold velocity for all installed engines and cars, original or add-on, since they all use that default.wag as a reference. To undo it, go back to the same folder and run restore.bat.Confusion is my fault, my favorite switching engine is the GP38, so I also included some hacks to the default GP38 engine, go to the \Train Simulator\Trains\Trainset\GP38 folder and run nopass.bat (no passenger view) or passview.bat (has a conductor's side view when you hit the #5 key). Again to undo it run restore.bat. If you don't ever drive the geep you don't need it, the hack to the default.wag alone should make front coupler switching/shunting easier and more stable on any engine.

Alert | IP

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

Member since Apr-23-03 · 97 posts

RE: Front coupler bug revisited.

LAST EDITED ON Jul-04-03 AT 11:03 AM (EDT)

Sniper,
I applied the hack to my default folder. Then I went to the Ohio Rail activity with the most problematic front coupling. The hack seemed to certainly improve things. Coupled at 2 mph ( still had to begin to back away for coupler to grab, but process was much smoother ). Uncoupling also was improved. Still had to set loco brake slightly to successfully uncouple, but was using an RS-3 that has "stock" throttle notches. It seems that if I hack the throttle similarly to your GP-38 hack, I might pull back slowly enough without setting the loco brake. Thanks. With further testing, this hack may become "required" on OVS. Would like your permission to "package" just the default.wag hack for OVS if we decide to adopt it. Please post your "results" from the entire group, since that data will be useful in our decision to "adopt" the hack.
BTW, are the speedo and clock/aspect .ace file public domain. I might like to add them to the OVS cabviews. Just wondering. Thanks again.

Joe Morris
WV&O #33
Vice President, Equipment & Physics
OVS

Alert | IP

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

Charter Member · 4950 posts

AACK!!!! OHIO RAILS AGAIN!!!!

LAST EDITED ON Jul-04-03 AT 12:27 PM (EDT)

Man, Port Ogden & Northern don't get no respect these days, everything's about that Pineapple King.Front coupler bug revisited – image 6Got an email from somebody too shy to post, was using the Canton GP9s in some ORRR activity or something, was getting lockups prior to the default.wag hack, afterwards got no lockups, but was constantly derailing. The front coupler is a lot more touchy than the back coupler, as far as I know there's no cure for it that will make it exactly the same as the back coupler. The one hack that does work is to open the offending engine's .eng file in wordpad, and change;DerailBufferForce ( 238kN )or whatever it says, to:DerailBufferForce ( 800kN )That's still realistic enough for me, with the back coupler it couples on at up to 4mph, bumps the car without coupling at 5-6mph, and derails (the CAR, not the ENGINE!) at 7 or 8mph. Values with the front coupler are lower, it will derail on straight level track at 4mph+, lower if the couplers meet at an angle (if the loose consist is sitting on a grade and/or curve)."still had to begin to back away for coupler to grab", yeah, no cure for that, it's hard coded in that the - how to explain this? Well, the simple version is, the coupling engagement physics are designed for the back coupler only. So if the engine is moving backwards, and the couplers are within the "engagement zone" of 30cm from each other, it will couple. If the engine is moving forwards the coupling engagement is disabled even with the couplers in the proper proximity to each other, so it doesn't couple. It affects the front coupler the same way, altho the proximity logic works, the movement direction doesn't change, so the couplers need to be seperating rather than approaching to couple on. That may sound wrong, but check it out by moving (front coupler) very slowly up to the car, and pushing against it won't engage the couplers. Backing away quickly enough to trigger the movement direction + speed + coupler proximity does engage it. When you do seem to couple on while moving forward, if you examine it closely what's actually happening is you collide with the car and rebound, and the coupler engages on the rebound if it's moving backwards fast enough. That's also why the uncoupling is so difficult, coupler proximity =<30cm + backwards movement of the engine at 0.2mph+ = engage couplers. The collision threshold velocity doubled in the hacked default.wag helps, problem is if you raise it too high you won't be able to couple on to some cars with the front coupler. So the trick to that is releasing all the brakes and backing just enough to pull the slack out, then when you uncouple you're already at the extreme range of the coupler proximity envelope. "With further testing, this hack may become "required" on OVS. Would like your permission to "package" just the default.wag hack for OVS if we decide to adopt it. Please post your "results" from the entire group, since that data will be useful in our decision to "adopt" the hack."What, for that Pineapple bum?! Where's my M40, I'm gonna take care of that guy once and for all!
Front coupler bug revisited – image 7Damn, I missed again. Seriously, yeah, go ahead, you don't really need permission, same answer as the next question;"BTW, are the speedo and clock/aspect .ace file public domain. I might like to add them to the OVS cabviews. Just wondering. Thanks again."Don't any of you guys read the readmes? I know I'm a blabbermouth, but you could at least skim thru my drivel occasionally!"This is public domain, upload, modify, use in other engine types, distribute at will."Plainsman posted a chart:http://www.train-sim.com/dcforum/DCForumID3/17856.htmlFor TLAR it's not really necessary to hack throttle notches precisely, so for most engines used for switching just cut the first two notches in half, adjust notch 3 and possibly 4 to hit a middle ground so you don't get a huge jump in power going from the lower notches used for switching to the upper ones used for dragging heavy tonnage up the hill. Or, since most diseasels I've seen use 8 throttle notches plus the idle, just copy that whole throttle notch datablock from one of my engines and paste it into whatever you're using. Look at that Plainsman link tho, I'm not sure why anyone would want to use a heavy road engine like a Dash 9 for switching, but if you do hack something like that you also need to change the power display values in the cvf file to get the little newfangled digital monitor thingy to display the correct power values.Once any and all bug reports come back (knock on wood, could this really be it?!), I was gonna post it in the file library with just the default.wag hack. Hopefully others (like Bing or Baldwin) are experimenting with additional hacks to the default.wag file, may come up with something even better.

Alert | IP

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

Member since Apr-23-03 · 97 posts

RE: AACK!!!! OHIO RAILS AGAIN!!!!

I read the readme, but out of respect ( or fear of the coconut god ), I wanted to ask.

Joe Morris
WV&O #33
Vice President, Equipment & Physics
OVS

Alert | IP

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

Charter Member · 866 posts

RE: AACK!!!! OHIO RAILS AGAIN!!!!

Click to send message via ICQ

Sniper, lady luck seems to be with you I've had absolutely no problems with this particular setup after much hard and serious use. Everything seems to work together with the only problem being the coupler window, but as you say .. nothing can be done about that.RobertR .. ADF-M&RM at http://www.adfrr.com

Alert | IP

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

Charter Member · 4950 posts

RE: AACK!!!! OHIO RAILS AGAIN!!!!

Hmmm, thanks, I think."I've had absolutely no problems with this particular setup after much hard and serious use",
The question is were you having problems before with lockups, crashes back to desktop, blue screen of death, and/or send-don't send prior to trying the default.wag patch? Also, if you had previously identified problem cars like the US2graincar that seemed to cause more random errors than average, have you tried again with those cars? The fact that you're having no problems is great, but unless you had problems previously it don't prove anything about whether this patch is valid or not.As for the coupler window, there's a guy named b101UK in the loco design forum who (I think) said he might be able to come up with a hack for that which would display up to 24 cars in the window with the front coupler engaged. His spelling is almost as bad as my Dad's spelling, but I'm pretty sure that's what he said. Once this is a proven concept we can always build on it later.

Alert | IP

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

Charter Member · 618 posts

RE: AACK!!!! OHIO RAILS AGAIN!!!!

LAST EDITED ON Jul-04-03 AT 04:38 PM (EDT)

SniperI have tried your Default hack with the proper timestep in place running my test train (with default coupler settings) over Piegan and Cutbank. The result is perfect for most of my runs through. On some of them I am getting the odd car which slams back for a full car length and then returns to normal, and as I dont spend all of my time watching the train, thats OK. As that seemed to be working well, I decided to drop the break values down to 3.6e6N 3.6e6N for a run at each place. In both cases I had a clean run through, which I have never been able to do before at those values. Whilst one run does not a test complete, I am sufficiently encouraged to retain the normal timestep, and try to find just how low those can go before breaking.Edit
Then I must repeat the whole series with my softer coupling.mervyn@madasafish.com

Alert | IP

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

Member since Aug-22-02 · 41 posts

RE: Front coupler bug revisited.

Hello everyone:I tried the fix with the Whitcomb 30 Ton/Sweethaven Route, and I did not see any improvement in the front coupler operation.Guess the physics in the fix aren't right for this engine.Craig

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Hey, Baldwin, 'wassup? "I have tried your Default hack with the proper timestep in place running my test train (with default coupler settings) over Piegan and Cutbank."I never did get an answer to that, where's the starting point for testing the Cutbank Coupler Curse, and what's a good default consist for testing it? Worst trouble with any hacks is that restoring saved games is iffy at best, as the train tries to adjust position/spacing to reflect the new values you get wierd effects, so it probably needs to be restarted from wherever the starting point is for each test."The result is perfect for most of my runs through. On some of them I am getting the odd car which slams back for a full car length and then returns to normal, and as I dont spend all of my time watching the train, thats OK."Well, that sounds promising!"As that seemed to be working well, I decided to drop the break values down to 3.6e6N 3.6e6N for a run at each place. In both cases I had a clean run through, which I have never been able to do before at those values. Whilst one run does not a test complete, I am sufficiently encouraged to retain the normal timestep, and try to find just how low those can go before breaking."Wait a second, I thought you said you used "default" coupler settings. "Default" as in KUJU May 2001 values for all cars and engines? Or as in physics 4.5 default?"Edit
Then I must repeat the whole series with my softer coupling."I dunno why, if it works with Plainsman's 4.5 values, those have the best looking slack action. I'm all in favor of mathematically correct precise physics if it don't blow up in the sim, so if the default.wag hack makes physics 4.5 work without derailing/uncoupling/breaking couplers why change it? The only things of Bob's that I changed in those geep38 hacks were the throttle notches to make uncoupling with the front coupler easier, and the derailbufferforce to keep the blasted thing from jumping off the track with a slight bump of the front coupler. I left all the coupler spring and stiffness values the way he had them, it looks good that way.The rest of you guys, I know I come off like a (CENSORED!) sometimes, but that's only because I AM a (CENSORED!). I don't intend to change, I like being a (CENSORED!), and I'm really good at it, I've been a (CENSORED!) for a long time.I appreciate the fact that you're trying to help, "it's the thought that counts", but I ain't Emily Post so I ain't gonna be polite and keep my mouth shut if it isn't helpful.Specifically, when using the front coupler, I previously had the problem(s);
Crash back to desktop.
System lockup.
Fatal exception error.
Send/don't-send.
Difficulty coupling without derailing.
Difficulty uncoupling.
Other.Now that I tried the default.wag hack,
The problem is worse.
The problem is about the same.
The problem is better.
The problem is eliminated.
I didn't have this problem before, and now I do.
It got rid of this problem but now I have that problem.
Works better with this engine/car but is worse with that engine/car.
It got my dog pregnant.
Other.Craig, I'm assuming you're talking about difficulty uncoupling, you didn't say. "did not see any improvement" to me means it's about the same, but what is it that was wrong that didn't improve? I didn't get very many lockups previously with the Whitcomb/Sweethaven, Ron made some well balanced cars. But the Whitcomb itself has the throttle notch 1 set for 15% power and it accelerates pretty quickly, so I used the old trick of applying 30% engine brake before uncoupling, notch 1 reverse, then slowly reduce engine brake until it just starts to creep backwards. I did hack the Whitcomb throttle notches so I don't have to use the engine brake to retard acceleration anymore, but that being a payware add-on I sent the hack to 3Dtrains for approval before I'm gonna post it here. Meantime try the engine brake to slow it down.

Alert | IP

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

Member since Aug-22-02 · 41 posts

RE: Front coupler bug revisited.

Hi Sniper:Yes, my reference was to uncoupling. I did not see any improvement in my ability to uncouple from the from enging coupler. I also sent an email to Ron telling him that I tried the mod and asked what could be done to utilize the theory to thw Whitcomb advantage.I hope Ron will accept your hack, it could do nothing but improve the situation in my opinion.Thanks again for the insight you have provided, I await the Whitcomb hack.Craig

Alert | IP

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

Charter Member · 618 posts

RE: Front coupler bug revisited.


"where's the starting point for testing the Cutbank Coupler Curse, and what's a good default consist for testing it? "You either run the route or make a path starting before the troublespot, the end result is the same, it just takes less time for each test run if you make the path. I have mine started about 2 miles out which gives enough room to get a big train rolling. As to consist, anything over 20 cars will do, they all suffer to some degree, the longer ones are the worst. "Wait a second, I thought you said you used "default" coupler settings."Thats exactly what I said, default as in KUJU. I have now changed over to the v4.5 values and am running tests again. I'm not knocking Bobs' physics when I say I will try with my softer couplings, I just need to know for myself if there is any improvement or otherwise, if not then I drop that avenue of investigation.You can be a (CENSORED!) for as often as you like and as long as you like, its what makes your subject matter so interesting.Just one point about those 4.5 physics, the coupling values are not the same for all units, including the r0 in at least one case. mervyn@madasafish.com

Alert | IP

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

Charter Member · 2626 posts

RE: Front coupler bug revisited.

I think the Series2000 had also the same problem with this front coupling at back coupler problem, with Bar coupling at the front and automatic at the back.

--You are reading my signature now, don't waste your time reading it!--
Eh, where did my signature go?
Where has my favourite LUL train gone? Maybe it was sent for bolt checking again...

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Ok, thanks, Craig. Ron, you gots mail. It isn't perfect, works OK with the mouse or keyboard, Raildriver don't like it tho. Pull the throttle handle back to notch 1 and it wants to jump to notch 2 instead, push forward and it wants to bypass notch 1 and go back to zero. I've seen that before with the geep and SD40 throttle notch hacks I've been playing with, only on those it wants to skip notch 2 and jump back and forth between 1 and 3. Difference is probably due to the Whitcomb having 8 notches instead of the traditional 9. Following Bob's ideas on the Dash 9's power display I tried editing the .cvf file to change the power percentages in the .cvf to match the ones in the .eng file, but altho that makes the notches display correctly it don't seem to help Raildriver. I don't know why, if I hack an .eng file to change power percentages in the throttle notches and don't update the .cvf to match, the throttle notch number display in the cab is mismatched, but the label at the bottom and the F5 hud correctly display the new power percentages for each throttle notch in the .eng file no matter what the .cvf says. In fact if you look at the Whitcomb's Whitcomb30.cvf file;Lever (
Type ( THROTTLE LEVER )
Position ( 68 400 120 76 )
Graphic ( WhitcombThrottle.ace )
Style ( SPRUNG )
MouseControl ( 1 )
NumFrames ( 8 4 2 )
NumPositions ( 8 0 1 2 3 4 5 6 7 )
NumValues ( 8 0 0.15 0.3 0.45 0.6 0.75 0.75 0.9 )
Orientation ( 1 )
DirIncrease ( 1 )
ScaleRange ( 0 1 )
)Idle, 15%, 30%, 45%, 60%, 75%, 75%, and 90%? Since the Whitcomb don't have a notch number display it's not noticeable, but I suspect if I were to study it closely enough it probably affects the animation of the throttle lever in the cab. Don't affect Raildriver tho, cuz I did already hack the .cvf (after I sent you and Marc that one, didn't occur to me until last night), and it doesn't fix the Raildriver jumping from zero to 2 and back. Supposedly Raildriver only reads the F5 hud, but I suspect it's reading something else as well.Stooopid (GREAT nickname!),
"I think the Series2000 had also the same problem with this front coupling at back coupler problem, with Bar coupling at the front and automatic at the back."Still has, this hack don't fix stuff like that. We've been kicking ideas back and forth in the loco design forum for about a month, and some people thought that adding double coupler value datablocks to all engines and rolling stock would fix the front coupler. My theory was that the sim read only the first coupler statement and ignored the spring, damping, and break values in the second. Turns out that was wrong, it probably does read all the values in both statements, it just swaps them around to orient them in the "correct" direction depending on which way the engine or car is facing in the consist. Kinda negates the whole purpose of having two different coupler types and values in these specialty engines/cars, but don't tell me, somebody go tell KUJU.

Alert | IP

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

Member since Aug-22-02 · 41 posts

RE: Front coupler bug revisited.

LAST EDITED ON Jul-05-03 AT 12:14 PM (EDT)

Great work Sniper!Whitcomb here I come. Bummer about the Raildriver though.My 2 cents also...content is more important than screen size!Lets see if I can uncouple now....Craig
PS-sent a email to Raildriver tech support with this url asking if something can be done on their end. Who knows, all they can say is 'nothing'.

Alert | IP

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

Charter Member · 2626 posts

RE: Front coupler bug revisited.

>Stooopid (GREAT nickname!), That means you have never noticed me before?

--You are reading my signature now, don't waste your time reading it!--
Eh, where did my signature go?
Where has my favourite LUL train gone? Maybe it was sent for bolt checking again...

Alert | IP

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

Charter Member · 2533 posts

RE: Front coupler bug revisited.

Jim is just pulling your leg, Phil ! Nobody can miss that handle of your's, trying to camouflage a wealth of MSTS knowhow in case you get it wrong ? O t t o

Alert | IP

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

Member since Apr-5-03 · 18 posts

RE: Front coupler bug revisited.

Sniper,I have to thank you for at least making front coupling easier. I can't say it doesn't lock up at all, but it is working A LOT better.I have the Timesaver Route. There are several facing point industries. Running around a car almost ALWAYS meant "Crash, Send/Don't Send." Today, I installed your hack...loaded up a consist with an SW1200 and hit the car at 3 mph. It did not derail, and coupled first try. Then pushed it onto a siding, and bingo, it uncoupled instantly. I got so excited, I forgot to slow down and crashed into another car...oops!Thank you. I will stick with MSTS. I found Passenger activities too slow for me, but switching almost always caused Send/Don't Send errors. I was ready to give up trains and play Solitare! Jeff

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Gotta check into this more often, piled up like the Dan Ryan at rush hour here.Geez, Merv, "make a path starting before the troublespot", where exactly is the trouble spot? I tried running from "East of Cutbank" and never saw it, I heard it was westbound somewhere in the vicinity of Cutbank, but I can't remember exactly where.Craig:"sent a email to Raildriver tech support with this url asking if something can be done on their end. Who knows, all they can say is 'nothing'."Gotta have patience, Tim is currently out of the country according to an email response I got from somebody named Dan (do I know him?), and it is, after all, a holiday weekend here in The Land of the Free and the Home of the Brave, something about a 227th Birthday party. I think Tim went over to England to see if he could start another fight. They usually respond by the next business day, which ain't until next Monday. Meantime;http://www.train-sim.com/dcforum/User_files/3f077a6b63d96fdd.zipThere's the current "official" hack set for the Whitcomb, includes both passenger view and non-passenger view options, read the 297readme.txt for info. Works well with keyboard or mouse, the Raildriver still requires you uncouple, set reverse, and bump into notch 1 then back to idle again to keep it from jumping to notch 2.Yeah, Otto, I pulled his leg and it came off in my hand! I think I did mention it in another post a long while back, stooopid_person, that from whatever it was you said you din't seem to be all that stooopid! Route Design forum maybe? I'll have to look it up, I got DSL and it don't take that long to search.And last, RevnJeff:I don't know if you missed it, you did get a response about your "Little Brother" in this thread:http://www.train-sim.com/dcforum/DCForumID7/1742.htmlTrust me, try ponV6.zip, it's probably the best all around switching route there is, and ideal for playing 10 minutes or 10 hours, however much time you have."I can't say it doesn't lock up at all, but it is working A LOT better."Finally a negative report, this does not cure lockups completely. I was fiddling around with an activity I made for a beta of Rich Garber's next route, using a whole bunch of non default equipment (all beta PO&N rolling stock, just to be obnoxious! ) and after assembling a train with the front coupler (probably a dozen or so front coupling and uncoupling and running around to the front) I pulled it the length of the route, stopping twice to pick up and set out cars with the front coupler and the back. When I reached the end of the line I hit the escape, exit activity, and instead of going back to the menu I got a black screen and then send/don't-send. That's the kind of real tough error that you're never sure of, I used the front coupler during the activity and got an error on exit, altho I hadn't used the front coupler for about an hour prior to the error. Cause and effect? Probably, but hard to tell."loaded up a consist with an SW1200 and hit the car at 3 mph. It did not derail, and coupled first try."Curious, which SW1200 and which car? Some are so bad they require additional hacks to make them work at all, even with the back coupler. I've been changing the derailbufferforce line in all my engines from 200kN to 800kN, since most cars default to 400kN and it always seemed kinda silly that a locomotive would derail before a car did anyway. The front coupler being so much more sensitive than the rear coupler it's like catching eggs to try to couple on with the front coupler of an engine with a derailbufferforce of 200kN, so I don't see the point af leaving them that way. I didn't change that in the Whitcomb, Ron had it set to 375kN, which seems to work okay. That would make it derail at a slightly slower impact speed than the car, which is 400kN, and for a 30 ton switcher that makes sense. For a Dash 9 to jump the rails after hitting an empty flat car at 5mph and leave the flatcar on the tracks don't make sense. "I got so excited, I forgot to slow down and crashed into another car...oops!"Hee-hee, not much room for error on them Timesaver routes, is there? I normally don't recommend payware to anyone, since there's so much good free stuff in the file library (and IMAO, the Port Ogden & Northern beats the pants off of all routes including the payware routes!), but www.3Dtrains.com has that Whitcomb 30 ton switcher bundled with a bunch of custom cars and another one of Ron's evil sadistic timesaver style routes, the Sweethaven Harbor. All for only $10 buckazoids US, and almost as much fun as the PO&N!

Alert | IP

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

Charter Member · 2626 posts

RE: Front coupler bug revisited.

>Yeah, Otto, I pulled his leg and it came off in my hand!
>
>I think I did mention it in another post a long while back,
>stooopid_person, that from whatever it was you said you
>din't seem to be all that stooopid! Route Design forum
>maybe? I'll have to look it up, I got DSL and it don't take
>that long to search. So which posts is it? Eh? You have DSL? Then you must be one of the people trying to show off, sky's the limit in the post where you asked about 56K downloads...

--You are reading my signature now, don't waste your time reading it!--
Eh, where did my signature go?
Where has my favourite LUL train gone? Maybe it was sent for bolt checking again...

Alert | IP

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

Member since Apr-5-03 · 18 posts

RE: Front coupler bug revisited.

>
>And last, RevnJeff:
>
>I don't know if you missed it, you did get a response about
>your "Little Brother" in this thread:
Yes, I saw the response, and have downloaded the route. Trouble is (not a criticism, just a comment), Greg needs structure (pick up this, drop off that). I am going to try the Random Generator activity and check that out.
>Curious, which SW1200 and which car? Some are so bad they
>require additional hacks to make them work at all, even with
>the back coupler.
The SW is the CNW repaint of Kevin Combs model. I also have the EMD cab for it and love how it handles for switching. The car is the stock gondola. >www.3Dtrains.com has that Whitcomb 30 ton switcher bundled
>with a bunch of custom cars and another one of Ron's evil
>sadistic timesaver style routes, the Sweethaven Harbor. All
>for only $10 buckazoids US, and almost as much fun as the
>PO&N!
I will have to check this out. Thanks again for the heads up. Thanks for being so helpful as well.
Jeff

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

I think you mean the random work order generator, if you can figure that out let me know too. I like the guy, but his English is a little incomprehensible sometimes, and I can't figure out how to work it. Not really a huge problem tho, if you're sitting next to the kid all the time he's playing you can make up a work order and write it out beforehand, and then require him to follow it. Assuming he can read at all, having him read it will also reinforce reading skills. Structure is a great thing, but thinking and decision skills are also important, so having a by the numbers do it this way every time activity isn't necessarily the best. With the freestyle activity, if the work order says these 3 cars over here and those four cars over there need to be picked up, then set out these 2 at destination A, those 3 at B, and the other two at C, the freestyle lets the player decide what order they get picked up and dropped off in, and how and when to sort them in the train. You can make suggestions at first, and as he sees the logic let him take over the decision making process. Try the same activity with the same work order and see if he can complete it in less time by doing it differently, that sort of thing. The PO&N freestyle activities can be structured with flexibility, it just depends on how you write out the work order.
Just some suggestions, I'm a father of 4, grandfather of 14, a semi-retired CPS Teacher's Aide, and my youngest son is an autistic 13 year old that makes his own routes and activities. One thing I do know about is kids.Front coupler bug revisited – image 9
Stooopid, I knew you actually said something intelligent once, took me a while to find it tho:http://www.train-sim.com/cgi/dcforum/dcboard.cgi?az=show_thread&om=13106&forum=DCForumID3# 3 and 4 in that one.
Hee-hee, and you thought YOU were stooopid, I never woulda got TSunpack to work without your help! And yeah, I'm a showoff with DSL, but I do remember the bad old days of 56k dial up, which is why I did the poll. Like I said, my oldest daughter is married to an Ameritech LAN guy, and they can't get DSL anyway cuz it's not available in their area. The poll helped me make a decision tho, when I finally finish and package all that it's gonna be one megapack for the DSL/cable people, and a bunch of little packs of less than 5 megs for the 56k people. As long as we're stuck with two connection systems with such major speed differences, that kind of extra work is gonna be necessary if you don't want to exclude one crowd or the other.

Alert | IP

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

Charter Member · 2626 posts

RE: Front coupler bug revisited.

>Stooopid, I knew you actually said something intelligent
>once, took me a while to find it tho:
>
>http://www.train-sim.com/cgi/dcforum/dcboard.cgi?az=show_thread&om=13106&forum=DCForumID3
>
># 3 and 4 in that one.
>Hee-hee, and you thought YOU were stooopid, I never woulda
>got TSunpack to work without your help! And yeah, I'm a
>showoff with DSL, but I do remember the bad old days of 56k
>dial up, which is why I did the poll. Like I said, my oldest
>daughter is married to an Ameritech LAN guy, and they can't
>get DSL anyway cuz it's not available in their area. The
>poll helped me make a decision tho, when I finally finish
>and package all that it's gonna be one megapack for the
>DSL/cable people, and a bunch of little packs of less than 5
>megs for the 56k people. As long as we're stuck with two
>connection systems with such major speed differences, that
>kind of extra work is gonna be necessary if you don't want
>to exclude one crowd or the other. Something inteligent only once?
I thought LAN connection would deliver great speed? I've got 4.8MB/sec in the newtwork and 200+kb/sec in other places. With Train-Sim.com, a non-premium subscriber, it started out at 100kb/sec, then dropped to about 50kb/sec in the first 20sec, then to about 30kb/sec in the next 20 sec.

--You are reading my signature now, don't waste your time reading it!--
Eh, where did my signature go?
Where has my favourite LUL train gone? Maybe it was sent for bolt checking again...

Alert | IP

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

Charter Member · 618 posts

RE: Front coupler bug revisited.

"Geez, Merv, "make a path starting before the troublespot", where exactly is the trouble spot? I tried running from "East of Cutbank" and never saw it, I heard it was westbound somewhere in the vicinity of Cutbank, but I can't remember exactly where."Cutbank for me is the crossover just before the East Spur immediately after the road crossing. At Piegan the location is very similar, and the break spot is between the ends of the two back to back switches. As far as I am aware, those two locations are unchanged in all versions of Marias. In your other thread in the locomotive forum Kevarc said this "2.5e7N=25,000,000N", that is 25 million Newtons. Taking that premise I have been running with a break figure of 10e6 which would make 10 million Newtons. What is the relationship between Newtons and pounds when considering coupler breaking moments. 1 pound = 1 Newton?mervyn@madasafish.com

Alert | IP

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

Member since Aug-22-02 · 41 posts

RE: Front coupler bug revisited.

LAST EDITED ON Jul-06-03 AT 12:43 PM (EDT)

Sniper:Downloading now, will run the hack and post my results for the record.CraigInitial impression: it does help.I like speed settings, seems more realistic. Uncoupling worked well, I did not have to do the "D" key quict tap the "A" key routine. I was able to uncouple 90% of the time by just using notch 1 and back away.Coupling though, still was a problem. Had to be at least 3 or 4 mph to sucessfully couple. Anything less and I did not couple. Ocassionally I would break a coupler if I overshoot and went to 5 mph.Conclusion: Going to keep it. Craig

Alert | IP

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

Member since Apr-8-03 · 1024 posts

RE: Front coupler bug revisited.

LAST EDITED ON Jul-06-03 AT 04:14 AM (EDT)

Here is my input using your default .wag and GP38 hacks.I have to say that there is a huge improvement from the pre-hack values, but I still experience weirdness on my system.I need to be going at least 2mph to couple on the way in. Less than 2mph and I can only couple on the rebound. (when backing out) This is no big deal.When uncoupling, it gets a bit strange. My first attempt will always re-couple when I back up! The second time usually works, for reasons beyond me. Sometimes it takes three, but 95% of the time it's the second try. At first I thought It might be that the first try I've stretched out the coupler making the second try easier. But attempts at pulling out the slack before uncoupling still nets me the prize on the second try. I can't even begin to explain what might be going on here. But still, two attempts are better than half a dozen. No big deal here either.Now, do I still experience crashes and send/don't send? Yes. Does it happen when I couple? No... More oddness. Read on.I have yet to see a crash when attempting to couple. Instead, the crash doesn't happen until I hit the "end activity" button!! Strange huh? And it only crashes like this if I've use the front coupler. But, I have to admit that if it's going to crash, I'd much rather have it happen when I am exiting than during an activity when attempting to use the front coupler. So, I give this another no big deal.So there you have it. I give this front coupler/throttle notch tweak an overall no big deal when using the front coupler instead of the pain in the butt it used to be. The results aren't perfect, (yet ) but they are definitely liveable.As for the Raildriver issue, I've found that if you keep the stock gp38 raildriver .eng file (pigp38.eng) instead of changing your notches to match the tweaked GP38.eng settings, it behaves a bit better.Instead of jumping past notch one to notch two using the tweaked values as you mentioned, it jumps past notch two to three instead. I'd rather it jump notch two instead of notch one. And when it jumps to three, you can pretty easily back the throttle off to two.-Jeff

Union Pacific is my drug.

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Crossover just before the East Spur, and another at Piegan, got it. I better write that down before I forget.

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Jeff:"I need to be going at least 2mph to couple on the way in. Less than 2mph and I can only couple on the rebound. (when backing out)"Yeah, I know it's hard to wade thru a lot of my incoherent babbling, but the explanation is above somewhere. For the slow speed couplings you have to be in external view and watch closely, but the couplers will not engage at all when the engine is moving forwards, fast or slow. "Backing away quickly enough to trigger the movement direction + speed + coupler proximity does engage it. When you do seem to couple on while moving forward, if you examine it closely what's actually happening is you collide with the car and rebound, and the coupler engages on the rebound if it's moving backwards fast enough. That's also why the uncoupling is so difficult, coupler proximity =<30cm + backwards movement of the engine at 0.2mph+ = engage couplers." That's somewhat simplified, essentially coupling takes place when the movement is above a given speed in the correct direction. The collision threshold velocity slightly increases that speed, harder to actually engage with the front coupler (I know it doesn't seem like it in most cases, but that's because the increased collision threshold velocity makes it possible to hit harder and therefore get a faster rebound), easier to disengage. When you try to uncouple the front coupler with the train moving in either direction the same thing applies, since the couplers are seperating, the relative movement (engine moving backwards in relation to car even if it's moving forwards, car moving forwards in relation to engine even if it's moving backwards) will re-engage the couplers as long as the speed of seperation meets or exceeds the coupler engagement velocity.The reason it would affect the infamous Cutbank Coupler Curse is because what happens there is the cars start jerking fore and aft, and the physics of them bouncing off each other gets them into out-of-phase oscillations that increase with each collision and rebound, and within a few seconds the jerking gets violent enough to break a coupler. Increasing collision threshold velocity would dampen that effect since each time the cars hit the fore/aft limit of the coupler their relative movement is momentarily at X meters per second, and if that meets or exceeds collision velocity threshold the collision and rebound take place. If no collision and rebound, then the normal stretch/compress governed by the stiffness value moves them back toward center less suddenly."When uncoupling, it gets a bit strange. My first attempt will always re-couple when I back up! The second time usually works, for reasons beyond me. Sometimes it takes three, but 95% of the time it's the second try. At first I thought It might be that the first try I've stretched out the coupler making the second try easier. But attempts at pulling out the slack before uncoupling still nets me the prize on the second try. I can't even begin to explain what might be going on here. But still, two attempts are better than half a dozen. No big deal here either."That gets into technique, prior to this I used the engine brake to increase drag and slow the acceleration so it don't recouple, other guys like Ron used the "bump in and out of notch 1 real quick" technique. Either one still works, difference is you don't need to bump in and out as quickly, or you don't need to use as much engine brake. For most cars I've found that I don't need either anymore when combined with the non-linear throttle notch hack. If it recouples, you're still going too fast. Sometimes it's hard to see that you've actually started moving without using the head out view, that's why I put that digital speedometer in there, when it shows 0.1mph kick the throttle back to idle and stop accelerating until you have 5 feet of seperation."As for the Raildriver issue, I've found that if you keep the stock gp38 raildriver .eng file (pigp38.eng) instead of changing your notches to match the tweaked GP38.eng settings, it behaves a bit better.Instead of jumping past notch one to notch two using the tweaked values as you mentioned, it jumps past notch two to three instead."I'm not getting that with the throttle notch hacked geep, only with the Whitcomb. With the throttle notched geep hack I do get a jump from 2 to 3, notch 1 behaves perfectly. I think the Raildriver .eng file uses the same as the default.Rats, I just looked at the piGP38.eng, have to send them a heads up on this.EngineControllers (
Throttle ( 0 1 0.125 0 0.
NumNotches ( 9
Notch ( 0 0 Dummy )
Notch ( 0.125 0 Dummy )
Notch ( 0.25 0 Dummy )
Notch ( 0.375 0 Dummy )
Notch ( 0.5 0 Dummy )
Notch ( 0.625 0 Dummy )
Notch ( 0.75 0 Dummy )
Notch ( 0.875 0 Dummy )
Notch ( 1 0 Dummy )

That "Throttle ( 0 1 0.125 0 0" line is from the original KUJU screw up, that extra zero is what makes it jump notches. Should read "Throttle ( 0 1 0.125 0". I'm not sure why that has an effect, but somebody found that mis\*.*teak a long time ago and posted the fix so it don't jump when you use the mouse, maybe I oughtta try fiddling with those settings to see if I can't get the non-linear throttle to stop jumping. Anyway, holiday weekend is over tomorrow, and Tim should be back soon, he'll probably have some ideas. I heard Plainsman is also out of town for the holiday, once he gets back I can pick his brains too. Already tried asking another guy who's supposed to know something about physics.Front coupler bug revisited – image 10"I have yet to see a crash when attempting to couple. Instead, the crash doesn't happen until I hit the "end activity" button!! Strange huh? And it only crashes like this if I've use the front coupler."Yeah, we were all getting that before too, if the car/engine combination wasn't buggy enough to trigger lockup/crash/send-don't send at the moment of contact, it would trigger upon exiting. I have gotten that twice now, but as you said it's a lot better to have the blasted thing wait until you're done playing before it acts up.Like I said, still in the "looks good so far" stage, possibly additional hacking to the default.wag may improve it further without screwing something else up. I just had a horrible thought, wouldn't it be rotten if we finally fixed it perfectly a year from now, only to find them KUJU Klutzes screwed it up worse for MSTS 2, with a completely different programming so we had to start all over?!

Alert | IP

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

Charter Member · 1015 posts

RE: Front coupler bug revisited.

"I just had a horrible thought, wouldn't it be rotten if we finally fixed it perfectly a year from now, only to find them KUJU Klutzes screwed it up worse for MSTS 2, with a completely different programming so we had to start all over?!"That happens a lot to me. Just when I thought I had Win98SE going pretty good - I mean it didn't crash or lock up ALL the time, just once or twice a day - out comes WinXP. I think I can say with confidence I will never reach that promised land per above with XP. Others may, but so far as I am concerned, it will be "Toto, I don't think we're in Kansas ...." Bing

Alert | IP

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

Charter Member · 618 posts

RE: Front coupler bug revisited.

SniperWhilst your default.wag hack is part of a simple and elegant solution to sort out the front coupler, it does not help the Cutbank syndrome. Now whilst this can be fixed by using super-strong break figures I think that the recouple(front coupler) and the uncouple(Cutbank etc) are linked by either Spring or Damping. One of those is too high or low in relation to the other. Assuming that the damping figure is adequate then the Spring is too strong, or viceversa.Going for the former assumption means that the Spring has to be reduced in strength, which should mean that the Damping has more effect on the Spring, and therefore reduce the chances of a recouple.It also then follows that because Damping has more effect on Spring the uncouple effect should be reduced leading to a reduction in Break strengths.To prove this theory, I took the v4.5 physics, and your hack along to Piegan. I then set the spring strength to 4e5 8e5 and went for a low break figure and slowly moved it up until I didnt get a break(uncouple). I then put the spring strength back to the v4.5 value and immediately got the break again. So I popped it back down again and the break went away. That was using a break value of 7e6 7e6.I have since reduced the Spring to 4e4 8e4 and Break to 7e5 7e5 and can still run through Piegan without breaking, though there is a little shudder sometimes. This was done with a short train of 2 engines and 31 cars. I have successfully started the big SF DD40 coal train on an uphill slope with those lower values, but had to use distributed power to do so, and even then had to go very slow and easy on the throttle.Now, if Kevarc is right and the figure after the e is the number of 0s then 7e5 is 700,000 which equates to 157,366 pound force and 7e6 is 1,573,662 pound force and somewhere in that bracket is the true figure for break values. But they will only work if the Spring value is also lowered.I have also briefly used the front coupler on the lowest figures here, with no lockup and no recouple, but the jury is still out on that one. It is very easy to make the changes needed in bulk using Engmod.mervyn@madasafish.com

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

"Cutbank for me is the crossover just before the East Spur immediately after the road crossing. At Piegan the location is very similar, and the break spot is between the ends of the two back to back switches. As far as I am aware, those two locations are unchanged in all versions of Marias."That's where I thought it was, it's the only crossover in the area. I just ran \Trains\Trainset\Default\restore.bat to change back to KUJU physics, made an activity starting at the oil spur going west (since I heard it was only westbound) with the default 2 Dash 9 x 40 mixed consist. Sailed thru no problems. So I thought "Hmmm, sim made by a buncha Limeys, who drive on the correct side of the road like the C&NW did, maybe they're unaware that most US railroads like this CB&Q/ATSF merger usually drive on the wrong track". So I changed the activity to start on the left hand track instead, still can't duplicate. I wenta ahead and drove all the way to Piegan, and DID finally get the coupler break there. Thinking I might have heard the "westbound" incorrectly, I tried making two new paths starting west of Cutbank going east, one on each track, still can't duplicate. I could swear I did get that broken coupler once at that same crossover by East Spur, I don't know why I can't duplicate it now using all default physics. I did check all the .wag, .eng, and .sd files, all dated 5/7/01 or 5/8/01, so it's all default, and I'm on the original unmodified Marias. Just checked my pockets, no rabbit's foot, maybe I oughtta call the Psychic Friends Hotline and buy a Lotto ticket tonight."In your other thread in the locomotive forum Kevarc said this "2.5e7N=25,000,000N", that is 25 million Newtons. Taking that premise I have been running with a break figure of 10e6 which would make 10 million Newtons. What is the relationship between Newtons and pounds when considering coupler breaking moments. 1 pound = 1 Newton?"You got me hanging. I asked Einstien and got the same response;Front coupler bug revisited – image 11I would assume Bob would know when he gets back, I was just taking a SWAG that "e" meant "times 10 to the power of the number that comes after this" based on Kevin's usual tactiturn response. That's how he passed me by in total number of posts, he says "No" and increments his post count by 1! Hee-hee, he KNOWS I can't be that brief, I drink 190 cups of coffee and type 60 words a minute with my feet!

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Ok, confirmed, at least at Piegan anyway. Ran thru Piegan with the 2xDash9x30mixed consist, broke a coupler on one of the piggyback flats. Ran \Trains\Trainset\Default\hackit.bat to change back to the modified default.wag, and ran it again, broke a coupler on one of them bathtub gons. I dunno what I'm doing wrong at Cutbank, but for some reason I still can't get a broken coupler there with or without on either track in either direction.Someone once proposed a theory that there was too much distance between nodes (there's a node at each switch where the position of each car is recalculated and updated in relation to the track database), and adding a switch somewhere along the long unbroken mainline would cure that. I'll give that a shot when I get time, unless someone wants to beat me to it, hint hint! There is a lot of very rough track both before and after the curse points, but as long as it's kept under the speed limit it don't uncouple or derail on those.

Alert | IP

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

Member since Aug-1-02 · 2522 posts

RE: Front coupler bug revisited.

"...and adding a switch somewhere along the long unbroken mainline would cure that. I'll give that a shot when I get time, unless someone wants to beat me to it, hint hint!"I already have. Added a spur on the north main at Ethridge with a westbound connection. For me it fixed the Cutbank syndrome. Downside: This resulted in me having a hybrid Marias 3 (MP 3a?) that no MP3 activities would operate on. So, I reinstalled the "stock" back up MP3 and moved on to other things.The switch node thing definitely works. Why it works, perhaps still has a bit of mystery surrounding it, but adding a switch in the middle of a long run w/no switches has resulted in a fix 100% of the time on routes I've built that had consistant broken couplers in specific locations. Re: Cutbank - To create the syndrome, the train will need to be westbound on the north main. The train will need to start EAST of the LAST switch west at Shelby. It's that long (18 mile?) run with no switch nodes that gets 'ya. Starting a train in the middle of the run will NOT create the problem. It MUST be run the entire length between Shelby and Cutbank. Don't know if this helps, but in view of your plea, thought I'd share.Wish you success on helping the front coupler to be more stable.Coonskin

Alert | IP

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

Charter Member · 618 posts

RE: Front coupler bug revisited.

"Starting a train in the middle of the run will NOT create the problem. It MUST be run the entire length between Shelby and Cutbank."Not so for me, I can create a path starting from anywhere on that stretch and I get the break just as the train runs over the road crossing at Cutbank. Funny thing is, I never had it happen for the best part of a year, now I cant get rid of the darned thing.
mervyn@madasafish.com

Alert | IP

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

Member since Aug-1-02 · 2522 posts

RE: Front coupler bug revisited.

"Funny thing is, I never had it happen for the best part of a year, now I cant get rid of the darned thing"And people doubt the reality of demons.Andre

Alert | IP

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

Member since Apr-8-03 · 1024 posts

RE: Front coupler bug revisited.

>Yeah, I know it's hard to wade thru a lot of my incoherent
>babbling, but the explanation is above somewhere. No, I saw that. I just thought you wanted corroboration of results. My bad.>That gets into technique, prior to this I used the engine
>brake to increase drag and slow the acceleration so it don't
>recouple, other guys like Ron used the "bump in and out of
>notch 1 real quick" technique. Either one still works,
>difference is you don't need to bump in and out as quickly,
>or you don't need to use as much engine brake. Again my bad. I had assumed your hack for the throttle notch changes in the GP38.eng was to slow your acceleration enough that such gymnastics weren't necessary. I was giving you my results without trying any finesse. As with I'm sure most of us that uses the front coupler regularly, I can finesse an uncouple first time, every time.>I'm not getting that with the throttle notch hacked geep,
>only with the Whitcomb. With the throttle notched geep hack
>I do get a jump from 2 to 3, notch 1 behaves perfectly. I
>think the Raildriver .eng file uses the same as the default. I get just the opposite. Default pigp38.eng jumps from notch 2 to 3. Tweaked values jump from 1 to 2.>Rats, I just looked at the piGP38.eng, have to send them a
>heads up on this. Good catch! I totally overlooked that. I'll have to make that change.>Yeah, we were all getting that before too, if the car/engine
>combination wasn't buggy enough to trigger
>lockup/crash/send-don't send at the moment of contact, it
>would trigger upon exiting. That's odd, the only time I ever got the crashes was when I coupled. I never had it crash when exiting until I installed the hacks. Man, is MSTS voodoo, or what?? >I have gotten that twice now,
>but as you said it's a lot better to have the blasted thing
>wait until you're done playing before it acts up. Amen to that!
-Jeff

Union Pacific is my drug.

Alert | IP

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

Charter Member · 29 posts

RE: Front coupler bug revisited.

One of the TP2 switching activities has a place where you can avoid a runaround if the front coupler will work. The first time I tried it, I coupled onto the four cars I needed to spot OK and got them to the spur they were going to. But I couldn't uncouple from them no matter what I tried.After installing the default.wag hack, everything worked, although I did have to set the handbrakes on the cars to uncouple. (The spur is on a downgrade toward the switch and I probably didn't use enough air to hold the cars when I stopped going in.) The activity has an action event that causes it to fail if you exceed the speed limit. So, after pulling out of the spur, I deliberately exceeded the speed limit and got the activity failed message that I expected. At that point my machine totally locked up. I ran it again, used the esc key and got a normal exit.Bert

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

"I already have. Added a spur on the north main at Ethridge with a westbound connection. For me it fixed the Cutbank syndrome. Downside: This resulted in me having a hybrid Marias 3 (MP 3a?) that no MP3 activities would operate on. So, I reinstalled the "stock" back up MP3 and moved on to other things."Hmmm, if it wasn't for MSTS 2 being on the way, I'd almost think it would be worthwhile to add the switches, fix all the activities to match, and upload a patch for default Marias and MP 3.1. Purists might whine petulantly about the route no longer being prototypical, but I don't see the point of prototypical that don't work. If somebody had done that a year ago there wouldn't be as many activities that needed to be updated to fix the broken paths afterwards. "The switch node thing definitely works. Why it works, perhaps still has a bit of mystery surrounding it, but adding a switch in the middle of a long run w/no switches has resulted in a fix 100% of the time on routes I've built that had consistant broken couplers in specific locations."Again, the theory is that the train is updated between nodes every so-many-milliseconds using some kind of rough calculations, and as it crosses a node the fine calculations kick in to reposition more precisely. As each car crosses the switch, the direction, height, and position is updated to realign it with the track database ( I never really looked, but presumably the wheels on the track would be slightly misaligned or something), and if it needs a large adjustment there would be a sudden large alignment mismatch with the car following that hasn't been updated yet. If you have PO&N with the default heavy scenery, you can see this in Anderson by changing to the #7 yard view and parking the view over a trailing point switch while driving a train slowly thru, as each car passes the back end snaps across to the straight track instead of following the front smoothly thru the curve. "Re: Cutbank - To create the syndrome, the train will need to be westbound on the north main. The train will need to start EAST of the LAST switch west at Shelby. It's that long (18 mile?) run with no switch nodes that gets 'ya. Starting a train in the middle of the run will NOT create the problem. It MUST be run the entire length between Shelby and Cutbank."Aha! That's what I was doing wrong, and why starting at "East of Cutbank" also didn't work. Pretty much confirms that theory about the updating at the nodes, driving the shorter distance don't put it far enough out of alignment for the cars to really whip.Well, my advice would be to forget Marias, Port Ogden & Northern is a much better route anyway! Jeff:Voodoo? Naw, more like a witch's curse. http://www.train-sim.com/cgi/dcforum/dcboard.cgi?az=show_thread&om=1145&forum=DCForumID6&archive=yesAs far as I know I'm the only one that ever had that problem, the defective disk 2 is something that could happen with any game, but installing without errors anyway was wierd, and why I was able to load and run Innsbruck-St. Anton at all with half the files missing is really wierd. The fact that it crashed after driving a few minutes is no surprise, the fact that it worked at all that way is really strange."I had assumed your hack for the throttle notch changes in the GP38.eng was to slow your acceleration enough that such gymnastics weren't necessary."Yeah, it does depend, like all the other sometimes/maybe stuff about MSTS. Using a single geep on most cars finesse isn't needed, some cars do require it, and if you have one or more helper engines behind you that increases the total power, therefore the rate of acceleration with a given percentage of power, so again requires either bumping in and out of notch 1 or a little engine brake to retard the acceleration.And as I found last night, it's NOT a global fix for all cars, I finally found one that will trigger instant lockup. US2FREIGHTCARYEL1, that oversized autorack car, will trigger send/don't send first time every time when you couple two together, reverse the back one and place as a loose consist, and couple on from the end with the reversed car with the front coupler of the geep. I also fiddled with some of the other buggy cars I haven't played with in a long time, the empty piggyback trailer in some directions lets you pass right thru it phantom car style.That's not discouraging tho, I looked at the size, bounding box, and inertia tensor for that US2FREIGHTCARYEL1 and adjusted to correct it, and it still locks up every time the front coupler engages. That at least makes it an ideal car to test various settings since the lockup is not random, I can duplicate it every single time. I have the DSL turned on while I'm doing this too, so I'm hitting the S key to bombard them Microsoft Morons with a steady barrage of front coupler error reports, maybe they'll finally get the *&^%$#@! message!

Alert | IP

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

Charter Member · 494 posts

RE: Front coupler bug revisited.

I've been back a week now from annual training where I was defending northern Minnesota from an attack by the Canadians, and I can't believe I completely missed this thread on the front coupler...Front coupler bug revisited – image 12Anyway, it took me over a half hour to read and digest the whole thread, which was more time than I spent testing your hacks. I have Kurt Kaminer's replacement GP38 installed (BNSF #2099) but I went ahead and applied the hacks to it anyway. It's basically a default engine anyway with the hack applied. Some preliminary observations:- I can now couple to the front at 4mph and under without fear of a lockup. Didn't have a single lockup with 3 consists I tested, 1 default and 2 non-default.- The wheels do indeed spin backwards on all the cars of the train. Has it always done that? - Dynamic brakes don't work in reverse. Has it always done that?- I did have a lockup exiting the sim. I exited the activity fine, then when I tried to "X" out of the sim, it gave me the S/DS screen.Also, here are a couple pics to show coupled state on 3 different cars, notice the gaps:(forgive me for putting BNSF equipment on AC&Y tracks....)US2Freight7
Front coupler bug revisited – image 13Bill Bzak's 100t hoppers
Front coupler bug revisited – image 14Svante Wendel's container cars
Front coupler bug revisited – image 15I dunno what causes the gaps, haven't looked into it yet.More tests to follow, now I will apply them to a different engine and more cars.Jeff L

Alert | IP

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

Member since Apr-6-03 · 299 posts

RE: Front coupler bug revisited.

Front coupler bug revisited – image 16

Jim,At first I thought you'd changed the GP38 eng file, but like you wrote the magic is in the Default.wag file. Anyway, did some testing and had the same results as mentioned before. <6Mph = coupling works
>8Mph = no coupling
>16Mph = derailmentSame (equivalent) values for European engines.
1 Mph = 1.6 Km/h Didn't have any MSTS crashes (knock on wood)So once again, thank you for another big improvement!

Best regards,
Richard.

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

I hate it when they throw a tread like that. Next time instead of hanging around waiting for the Canucks to invade, go ahead and invade them first, and bring back a few tank car loads of Canadian Whiskey. And send a couple shots over Johnf's chimney to wake him up, haven't heard from him in a while. Try not to bust any windows, it gets cold up there in the winter.
"The wheels do indeed spin backwards on all the cars of the train. Has it always done that?"When you couple on to a consist with the "designated" back coupler of a car facing the engine, it has always done that. Going around curves the trucks also pivot the wrong way. That's why this is such an iffy thing, possible combinations:Back coupler of engine to front coupler of car (only accepted "normal" coupling designed into the program).
Back coupler of engine to back coupler of car ("reversed", causes funky wheel rotation and truck pivoting).
Front coupler of engine to back coupler of car (same as above, only one wheel and axle set disappear from some cars).
Front coupler of engine to front coupler of car.The last two cause coupling problems that are different depending on how the car is "balanced", the pivot point in the shape file exactly centered combined with exactly equal plus/minus length values in the bounding box in the ESD file, which added together should match the size box in the .wag file exactly. Still not sure what the inertia tensor box does, the techdocs say the inertia tensor should be the same as the size box (altho they didn't always do it that way in the defaults, and the techdocs are wrong in a lot of other places, so who knows), other than that they don't explain what it's for. Numerous experiments with these values by a bunch of different people so far are inconclusive and contradictory, no surprise there. Sometimes you couple the front coupler of the engine to the front coupler of the car and think everything's hunky-dory, only to find later that coupling the front coupler of the engine to the back coupler of the same car causes problems. Some cars when reversed will work just fine until a certain combination of reversed and forward cars is tried, and then they refuse to couple on even when the back coupler of the engine is used to try to assemble the string. US2chemicar is one of those "sleepers" that seems to have no problems until you hit just the right combination and numbers."Dynamic brakes don't work in reverse. Has it always done that?"Yep. Independent brake also affects only the player loco and not the helpers in either direction, same thing with sanders, altho the dynamic brakes do MU together properly for all units when the player engine is running forward.I gotta download that 2099 and look at it, Brian was asking about it. I never saw that much gap with that default US2freight7 boxcar, that's usually one of the better behaved default cars. Just to make sure you're totally clear on what this is all about tho, the default.wag hack is what reduces lockups and makes the front coupler on all cars and engines work better, the throttle notch hack for the geep is merely an enhancement.

Alert | IP

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

Charter Member · 494 posts

RE: Front coupler bug revisited.

Geez, I gotta get out and drive trains around more often. 2 years messing around with RE mostly and I didn't even know there was a default.wag file. Definitely didn't know that wagons had a front and a back also.Up until now I've found that the 800kN fix was the biggest thing to prevent derailments when using the front coupler. I'll have to test the hack some more to see what else I can find, although I get the impression these tests have been done by many before me.I knew that the idea behind the post was all about the hack and not coupler gaps, I just have a nasty habit of going off on tangents whenever I see something worthy of including in a post. After all, I'm the "killjoy" that pointed out the lack of shadows on track textures back when you were tinkering with multiple track textures.One thing you might want to look into though is those 100t hoppers from LHW. I noticed that they seem to be really picky about using the front coupler of an engine, I'm guessing because of their realistic physics which seems to be something the sim can't handle properly. In the tests I did today, the 100t hoppers worked just fine.Later,CDAT

Alert | IP

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

Charter Member · 4950 posts

RE: Front coupler bug revisited.

Looks like we're gonn need to start another thread, took me 5 minutes to get to the bottom of this one!"People doubt the reality of demons" I sure don't, Andre. Had an activity set up last night with two of those big oversized yellow autoracks with one reversed, and got a send/don't-send every single time, either with the hack or with the original default.wag restored. I also tried the new Western Pacific 40 foot boxcar ( !), with one double consist second car reversed, front of consist facing the engine, the other double consist second car reversed back of consist facing engine, got a lockup on the second one every time. Now I can't duplicate it, same engine, same cars, same activity, same default.wag hacked/not hacked, won't send/don't-send. Good thing I'm already happily insane, the men in the white coats would be hauling me off about now.Richard:<6Mph = coupling works
>8Mph = no coupling
>16Mph = derailment What in the world are you using for derail buffer force, and with what engines and cars?!! Front or back coupler, max I get is couple on at 5mph sometimes, 6mph if the phase of the moon is right, and at 8mph+ it derails even with the back coupler. That's with the default 400kN for cars and 800kN for engines, I'm probably going to reduce the 800kN for my engines to 600kN, since Ron's Whitcomb uses 375kN and that seems to work okay.Jeff:"Geez, I gotta get out and drive trains around more often. 2 years messing around with RE mostly and I didn't even know there was a default.wag file. Definitely didn't know that wagons had a front and a back also."Was just talking to Rich via email, he's got the same problem! My brother also commented I seem to spend more time programming than playing, gotta keep our eye on the ball here, I didn't buy this thing for creating neat stuff, I bought it to play with trains! "nasty habit of going off on tangents", that's okay too, you can be on the right track and still get hit by a train! I wander all over the place but eventually wind up wherever it was I wanted to go, so I don't worry about it. "Laid back", I was born in the wrong town here, I'm really a California beach bum at heart.I'll take a look at the Wiz's hopped up hoppers, see if I can get them to do something awful.

Alert | IP

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

Member since Aug-31-02 · 356 posts

RE: Front coupler bug revisited.

>Was just talking to Rich via email, he's got the same
>problem! My brother also commented I seem to spend more time
>programming than playing, gotta keep our eye on the ball
>here, I didn't buy this thing for creating neat stuff, I
>bought it to play with trains! Back in the HO days of my youth, I found that for every hour I spent cutting ties, spiking rails, and scratch building switches, crossovers, ect., I'd spend maybe five minutes actually running trains (and half of that was by way of testing new trackwork). I find the MSTS ratio about the same -- especially if I factor in the time spent here in the forums. I don't see it as a problem though. I bought "this thing" for recreation and if I can enjoy myself of an evening building a route, or an activity, or tweaking in the trainset, or painting up a car, then I have gotten my intended value. I suspect I'd find it rather boring to do mostly running other people's activities on other people's routes. Brad "bliss is where you find it" Meyer

Alert | IP


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

Restored from the Train-Sim.Com archive, captured September 1, 2003. About this archive.