How do I fix this " Gap " ?

I have learned to do alot of things with MSTS since it was released.This is however one of the things I have NOT learnedNows a better time than ever.How do I go about fixing this " gap " between couplers ( same unit....different reskin )Thanks.............LaterTim Kent
96th_Malice
" Power for You "

Alert | IP

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

RE: How do I fix this " Gap " ?, GrizzlyBear, Jun-07-03, 00:15 AM, (1) RE: How do I fix this " Gap " ?, CPR_Malice_96th, Jun-07-03, 00:29 AM, (2) RE: How do I fix this " Gap " ?, controll, Jun-07-03, 01:07 AM, (3) RE: How do I fix this " Gap " ?, CPR_Malice_96th, Jun-07-03, 03:00 AM, (4) RE: How do I fix this " Gap " ?, buzzbenz, Jun-07-03, 12:50 PM, (5) RE: How do I fix this " Gap " ?, yellowdog, Jun-10-03, 09:36 PM, (9) RE: How do I fix this, KnightTrain, Jun-07-03, 02:43 PM, (6) RE: How do I fix this, sniper297, Jun-10-03, 07:27 PM, (7) RE: How do I fix this, buzzbenz, Jun-10-03, 08:15 PM, (8) RE: How do I fix this, sniper297, Jun-10-03, 10:34 PM, (10) RE: How do I fix this, steam4me, Jun-10-03, 11:00 PM, (11) RE: How do I fix this, Motley24Crue2, Jun-11-03, 00:45 AM, (12) RE: How do I fix this, sniper297, Jun-11-03, 01:16 AM, (13) RE: How do I fix this, baldwin, Jun-11-03, 04:08 PM, (14) RE: How do I fix this, mickoo, Jun-11-03, 04:54 PM, (15) RE: How do I fix this, sniper297, Jun-12-03, 00:05 AM, (16) RE: How do I fix this, steam4me, Jun-12-03, 01:05 AM, (17) RE: How do I fix this, mickoo, Jun-12-03, 01:41 PM, (18) RE: How do I fix this, sniper297, Jun-12-03, 02:15 PM, (19) RE: How do I fix this, b101uk, Jun-12-03, 05:03 PM, (21) RE: How do I fix this, steam4me, Jun-12-03, 08:10 PM, (22) RE: How do I fix this, b101uk, Jun-13-03, 03:43 AM, (24) RE: How do I fix this, baldwin, Jun-12-03, 03:46 PM, (20) RE: How do I fix this, sniper297, Jun-12-03, 11:53 PM, (23) RE: How do I fix this, b101uk, Jun-13-03, 04:00 AM, (25) RE: How do I fix this, sniper297, Jun-13-03, 09:55 AM, (26) RE: How do I fix this, Brad 110, Jun-13-03, 08:42 PM, (27)

Conferences | Topics | Previous Topic | Next Topic

Hey Tim
I had a similiar issue with a project I've been working on where I could not get correct spacing between a locomotive and the tender. I don't know if this could work for you, but it's how I fixed my problem. Open the eng file of the lead unit and near the top you'll find a line labeled "size" that consists of three values. It's the third number you want to adjust. In order to bring them closer, your going to want to make this number smaller. It looks like you don't have to much of a gap there, so it shouldn't need too much, maybe one or two tenths of a meter. I don't know if this will work for your situation here, but it's how I adjust locomotive to tender spacing if it doesn't look right to me, so you might want to try it.Grizzly

Alert | IP

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

>It looks like you don't have to
>much of a gap there, so it shouldn't need too much, maybe
>one or two tenths of a meter.Thank you very much. I'll give that a tryLaterPS: I'll let ya know either wayTim Kent
96th_Malice
" Power for You "

Alert | IP

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

Hey Tim,This is also sometimes a problem with the model design itself...the center of the unit was eyeballed and it is off from one end to the other....the modeller can correct it if you notify them of the issue.Rick

Alert | IP

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

Yup,That somewhat did the trick. It seems the problem is worse ( not really that bad ) when the units are lashed up rear to rear.Rear to front is not that bad.I adjusted them a tiny bit and things are better nowThanks for the helpLaterTim Kent
96th_Malice
" Power for You "

Alert | IP

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

Tim,Your answer lies in the .sd file. Adjust the values of the bounding box. If it is worse in one position that the other, then the model is not 100% centered. It will take a little more tweaking, but there is a positive and a negative value for the bounding box. You'll have to play with the values to adjust for the model being a slight bit off kilter.I'm obviously not at home right now, or else i'd happily tell you the exact name of the values you need to edit. Just tweak a little at a time! (Hint: it'll be the two largest of the numbers in the set that'll adjust your length. I also then adjust the size in the .eng file to be roughly the same...)------ BUZZ ------

-- Power For You --

Alert | IP

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

How about using Bounding Box editor? Or is this a different issue?

---------Clayton---------

Alert | IP

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

Several things needs to happen before units will couple correctly in MSTS.(1) In the eng-file, the overall length of the model as given in the Size ( x-value, y-value, z-value) value should measure from the center of the coupler to the center of the other coupler and not from the very extremes ends of the model.
(2) The centre pivot point of the model must be dead-centered on the model. This is extremely important if the unit is to couple correctly both front and back. If the pivot-point is off centered, MSTS will not accomodate for this until you uncouple and then re-couple the units after the sim has started.
(3) The z-values in the Sd-file should be exactly 1/2 of the Z-value given in the eng-file and exactly equal to each other.The actual physical length of the model as given in the s-file is actually irrelevant and can in general be safely ignored (but should not be altered).

TRACKDANCER

Attachments

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

Alert | IP

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

Got another thread going in the main trainsim forum;http://www.train-sim.com/dcforum/DCForumID3/18452.htmlOne thing we were trying was double coupler entries in the .eng and .wag files to see if that would fix the different results when trying to use the front coupler of the engine on certain cars, and not only getting different results from different cars, but also different results from opposite ends of the same car. Your explanation seemed to make more sense (and I'm still not convinced that the sim isn't completely ignoring the second coupler datablock anyway), so I tried it on one car that had two different values in the SD file, and it didn't work with the front coupler until I changed the r0 (20cm 30cm) to r0 (5cm 30cm). I think it's a combination of both things, the #3 fix to make both length values in the SD file the same to make the front & back couplers of the wagon work the same, and the r0 change to make the front coupler of the engine engage it. So, couple questions;In your #2, Where do you find the "pivot point", or is that defined by the first and second Z length values in the SD?What exactly does the r0 values do?If it's not in the r0 values, where is the actual drawbar runout distance defined? Seems to me it should be about 3 feet of slack travel on a real freight train, some cars look like they do and some don't.

Alert | IP

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

The pivot point will be in the .s file. The modeler is the one that sets that...------ BUZZ ------

-- Power For You --

Alert | IP

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

OK, Buzz, copy that. As trackdancer says tho, "The actual physical length of the model as given in the s-file is actually irrelevant and can in general be safely ignored (but should not be altered).", I'm inclined to agree with that, since my suspicion is the size defined in the shape file is for visual info only, the size line in the .eng file is used for the actual physics. I found out with that invisocar project that the sim don't like 0.0 meters length for player trains, but it will accept it for AI trains in general. 0.1 meters works for both AI and player. Actual collision detection seems to be in the SD file tho, since if the bounding box in the sd is extended past the coupler it bounces off without coupling. In theory making the bounding box too short should result in cars telescoping into other cars before coupling, but my one experiment with that didn't bear it out.Obviously size, inertia tensor, and the bounding box are all 3 connected into this, since changing one doesn't necessarily do anything if it's overridden by another. My previous hacks merely involved jacking the derail buffer force up to 800kN for engines, since the front coupler has always been considerably more touchy than the rear about derail buffer forces, but that merely kluges around the problem without solving it. Then there's the random lockup problem, which I get the same frequency of occurence in WinXP despite claims of better stability than 98SE. Half the time I actually have to pull the plug since it won't respond to anything including the power switch.As far as BBoxedit, I tried that plus the default wag fix in the file library, no improvement on any of the default cars and some it made worse. The random nature of the front coupler lockup has been the bane of my existance since microstupid came out with the half hearted 1.1 patch that did nothing more than make the brakes on the loose consists release when the front coupler engaged, and everyone who does any switching with the front coupler has reported lockups, crash back to desktop, and BSOD with it.
So with that in mind, before hacking the US2chemicar I set out to make sure it was still buggy. Set two US2chemicars on a yard track, reversed one, then went to it with the front coupler of the geep. Coupled on, pulled one car out, set it on another track, pulled the next one out and coupled it to the opposite end of the first so they're in reverse order now, no problem. Hmmm, that's why I do testing like this, you skip this step and you think "Eureka! I fixed it!", when in actuality the bug is still waiting for you. So after that I pushed the two tankers in to couple up to the gondolas that previously didn't work and worked after hacking, coupled on no problems. Hmmm, so I pulled all four cars out, thinking I was gonna drop them on the runaround track, reverse he engine on the wye, and go at them with the loco front coupler from the other end. Locked up solid about a minute later, had to yank the power cord.
So the question is, US2chemicars still buggy and that was just a delayed reaction? It has happened before, use the front coupler and think everything's jake, then get a lockup. Not the usual kind, more often than not it's instant lockup when the front coupler touches, but it does sometimes have a delay fuse. Or are the gondolas still buggy and my previous testing, regardless of how thorough, just didn't happen to trigger the bug? I dunno, obviously further testing with each car type individually in long strings is necessary. Maybe that r0 (5cm 30cm) hack didn't actually do anything either, it just decided to lock up before the hack and then figured it was gonna be sneaky and let me think the hack worked afterwards.
MSTS 9.0, anyone?

Alert | IP

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

>you think "Eureka! I fixed it!", when in
>actuality the bug is still waiting for you.
<snip>
>So the question is, US2chemicars still buggy and that was just a
>delayed reaction? It has happened before, use the front coupler and
>think everything's jake, then get a lockup. Not the usual kind, more
>often than not it's instant lockup when the front coupler touches,
>but it does sometimes have a delay fuse.

Jim,I don't think it's just the US2chenicars.I'm currently having those exact problems with an Aussie steam loco and its front coupler and difficulties exactly as you describe with a variety of passenger carriages. A gang of three of us have tried just about every combination of size, inertia tensor and bb in the .sd file and we get a delayed TS failure (rather than instant lockup), usually just after we yell "gotcha" as the train gathers speed running tender first. Mostly I don't get a full PC lock-up .... there's a 10 second pause, then MSTS just quietly vanishes.
RegardsYuri.
(steam4me)
-------------------------------------
Webmaster
Australian MSTS Add-ons Page
-------------------------------------

Alert | IP

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

<<there's a 10 second pause, then MSTS just quietly vanishes.>>hehe i like thatRobert Steskal
Philadelphia, Pa

Alert | IP

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

Me too, beats the hell out of the lockup. I dunno, Yuri, I screwed around with the .eng and sd bounding box for the GP38 until I had the red box looking like Trackdancer's pic, altho the geep coupler is higher than the gons, and made sure the ESD box values were exactly the same, and half the size value. I also corrected the values for the US2chemicar, and spent an hour switching two fixed US2crgons and 2 fixed US2chemicars around, rearranging in different orders, and turning on the wye to go at them from the other end. Since I didn't get even a hint of any trouble, I decided to try something really stupid, coupling the gons and US2chemicars onto two sets of the cars that started all this, the empty log flats and loaded plywood cars, and those coupled with no problems. So after setting out the gons & tankers, I dragged the four culprits up onto the switchback bridge so I could go at them on a grade and curve.No problems (knock on wood throw salt over left shoulder luck be a lady tonight) so far, I guess now I oughtta try the activity Ray had trouble with in the other thread without fixing the log flat or plywood car first, see if just fixing the engine makes enough of a difference. Anybody else wants to try it, here's the hacked default geep:http://www.train-sim.com/dcforum/User_files/3ee6b8d1321f6f0e.zip

Alert | IP

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

Sniper, if you go look at my 'hack' again, you will see that I have done both ends of r0 so max runout is only 25cm. From the techdocs r0 - The first value in here describes the rest length of the spring. The second indicates the length at which the second set of values kicks in.
Coupling springs work in compression as well as extension.It seemed to me that if the coupler were to be made slightly shorter then the values would kick in earlier and maybe make a difference in behaviour.The lockups, although they are related to using the front coupler, are actually a failure in the DirectX system, which by default runs in debug mode. By habit, I always run with my firewall active, and all .exe and .dll accesses are monitored, including the s/ds box. I recently changed from DX8.1 to DX9 in order to run a game demo, and the very next time I used the front coupler - wham - and up comes the call to Uncle Billy. So I hauled out my trusty Dxapplet and fixed it again. The said file is attached for those who want to try it. If you do, extract it onto your desktop, and run it from there, saves making a shortcut or trying to remember where you put it. Run the thing abd go to the tab Directsound. There you will find a slider called Debug Output Level. Slide it all the way to the to the left, close it and then go check and see if the sim runs. If it does, OK, if not, back to the applet and move the slider a bit to the right and keep on until the sim runs again.
mervyn@madasafish.com

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

Alert | IP

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

Mmmm interesting, l'd had some problems with my recent locos and after much dabbling found that l needed to add the buffers section and to increase the coupling to quite large lengths, l then copied that buffer and coupling section to all the required stock and the front coupler bug went away.l never have had crashes or lock ups but frequently get stock that l cannot uncouple from, sure you uncouple but move a few inches away and the bungie cord snapped back together, it was impossible to get away from stock dropped off , by incresing the length of the coupler it seemed to allow the loco to get outside of an invisble MSTS coupling box before MSTS rescanned to see if anything needed to be coupled or uncoupled. With short couplings you could get away by applying full power, uncoupling the releasing brakes quickly so that the loco was outside this invisble box with in the specified time.As far as l know no beta testers have had a front coupler crash yet ( theres still time ), only difference here is l'm using chain and you guys are using buckeyes, btw if you add the line coupling has rigid connection it makes the coupling act like a buckeye with little or no play at all, weired !.Best regardsMichael

Alert | IP

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

Huh. I always found that backing away slo-o-o-owly (less than 0.5mph) was what prevented all them "ka-CHUNK ka-CHUNK ka CHUNK *&^%$#! UNCOUPLE!" problems with the front coupler. Steam is pretty simple, open the regulator a little and close it again as soon as it starts to creep. For diesels, I always used the independent brake at 30%, slowly release to about 12 to 15%, and that makes it creep away slowly enough to prevent recoupling. See the GP38 hack in the zipfile in my previous post tho, the throttle notches are reduced in the .eng file so you get less power in notch 1-3, notch 1 being only 5% power instead of 12.5% it makes fooling around with the loco brake unneccessary since it don't accelerate like a dragster in the lower notches. This is the KUJU factor tho, the problem being the front coupler is different from the back coupler in coding, so when the engine is backing up at a speed high enough to engage couplers, front coupler in proximity to car coupler, sim says "reverse + speed above 1m/s + coupler proximity = engage". That's why the back coupler don't have these problems, the whole coupler window/couple-uncouple subroutine was written for the back coupler with no thought for the front coupler. Different hacks work for different situations tho, somebody once wrote a "running in reverse" manual prior to the halfassed 1.1 patch, and supposedly that fixed the brake release problem. It didn't, I tried it, so I can only conclude he did some hacks, made up a consist with the engine reversed at the front, and since it would drive that way it never occured to him to see if uncoupling and then recoupling would still work. It didn't, again, without the 1.1 patch the brakes are locked hard on for loose consists and don't release, and making up a consist even without all the "running in reverse" hacks would work until you uncoupled, since the brakes were already released when you started. So then they came out with the 1.1 patch, at least the brakes released, then we had this new problem with the crash/lockup/send-don't send.I looked at "Manual for .ENG and .WAG files" by Rudolf Richter on the
http://www.railpage.org.au/steam4me/trainsim/tutorials/ website, didn't get a lot out of it, but some. Got the r0 being spring length, and for whatever reason that first value at 5cm seems to be the main trick. I've been switching cars with the front coupler for two days now without a single crash, and I replaced all the default wag hacks with the originals, so the only thing I'm working with that does not have a file date of May 7th 2001 is the hacked geep I'm driving. Still not exactly sure what inertia tensor does, or if it has any bearing on front coupler behavior. I changed some of the values since that zipfile above, coupler break strength is now from Physics 4.5, here's what I'm using now;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 30cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 0.13m/s )
)Haven't had a derailment or broken coupler, and I've been switching cars around with the front coupler probably 6 hours total now.Baldwin, GET THEE BEHIND ME, SATAN! Hee-hee, I was sorely tempted to try your zipfile immediately, I downloaded the little beggar but I'm gonna hold off on it until the rest of this is worked out. Don't want to introduce yet another variable into all this! Once I'm reasonably certain we have a tried and tested formula that will work with the default OS, I'm definitely gonna try that DirectX hack!

One variable I gotta chop out, apparently, is the PO&N update. I replaced only the .act file with the original, so I still got AI trains running around honking their horns, but all the US2chemicars are back. I started in Texas Tea, collected 30 tank cars, ran to Northland Grain #2 and dragged 4 grain cars out with the front coupler, and after reassembling the train heading towards Northland Grain #1, suddenly I'm getting "failed to add/remove west15oil from world" half a dozen times, followed by about 30 "failed to create sms object" errors, then the same with west15log. All the .srv, .trf, and .pat files are the same, the only thing changed was the .act file for the US2chemicars instead of US2freightcar3. The .act file does list the .trf and all the services within it, along with a string of numbers which I assume are the starting times for each. I have no idea why they need the same listing in the .act file as they have in the .trf, but there it is. Runs fine in the VCR, the two services it claims it can't load are loading and running the whole route, so I have no idea what it could be. Haven't gotten much feedback on the invisocar or the two activities so far, LHW's MOW rescue for Maris and the PO&N updated activity pack, so I have no idea if we have another limit bug here with number of sounds in an activity.Well, back to the grindstone, but this engine hack definitely looks promising. Wonder how many switching fanatics are still around? Probably a lot of them got disgusted when the 1.1 patch fixed the brakes and intoduced even worse bugs, and went to play with Trainz. (OopZ, I said the "T" word!)

Alert | IP

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

Jim,
This is the KUJU factor tho, the problem being the front
coupler is different from the back coupler in coding <snip>I looked at "Manual for .ENG and .WAG files" by Rudolf RichterThat manual also states that if there's two coupling statements, the first refers to the rear coupler and the second to the front coupler: this may mean you can use different figures in the second set of coupler statements to achieve the desired result (introducing yet another set of variables).RegardsYuri.
(steam4me)
-------------------------------------
Webmaster
Australian MSTS Add-ons Page
-------------------------------------

Alert | IP

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

Sorry what l meant was that "was" the only way l could uncouple before l extended the chain coupling lengths, now that section is better you can uncouple slowly or quickly ( 0-3mph ).I dont think there is one golden bullet to fix this what works for one type seems not to work for another type of coupling, l have not looked at Buckeyes but have seen some dreadfull effects in multi unit lash ups where connections between locos close up to a meter or more.l'd be guessing but settings of r0 ( 5cm 15cm ) would seem logical, stiffening and damping would play some part as well those for a loco being higher than stock.I do think there is an answer, what l have here works for me on chain couplings but it may not be everybodies cup of tea and yes your probably right, most shunter type people have probably become so disenchanted they have given up.Best regardsMichael

Alert | IP

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

Yeah, 10cm difference seems a little tight tho, that's about four inches. I know the space between cars can vary from max stretch to max crunch by about 3 feet or so, but getting the couplers actually working correctly is more important to me.Yuri,"That manual also states that if there's two coupling statements, the first refers to the rear coupler and the second to the front coupler: this may mean you can use different figures in the second set of coupler statements to achieve the desired result"Like I said the jury's still out on that one for me, what testing I've done with double coupler entries in .eng and .wag files appears to show that the sim uses the first coupler statement for both ends and completely ignores the second statement.

Alert | IP

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

Hithe second coupler entrie(frunt) dose work ok you can have difrent setings for each (chane, auto, bar, Hydraulic) ,but you have to remember that the sim uses the the setings for the rear coupler entry for the frunt coupler of the ajoining car, so couplers propogate from the frunt to the rear of the train, its only when you datach wagons that the sepret frunt coupler value will come into play, but agen once reasenble wagons the rear coupler entry is used for the frunt coupler of the ajoining car, if you flip a wagon in a consist the what would be the frunt coupler is now the rear one so is used on the ajoining car.b101uk

Alert | IP

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

The attached image shows a pair of steam locos. Coupling is bar, followed by automatic in the .ENG file. The tender's .WAG file has Coupling set to automatic, followed by bar.Point #1: it would appear that the two different coupling settings are used by the sim and Point #2: I don't think that the settings propagate or the coupling between the locos wouldn't work. When running these locos on a train, couplers move in/out between locos and between cars, but not between either loco and tender (and the rear coupler setting for the loco has "RigidConnection"), so that setting doesn't propagate either.As with so many things in MSTS, nothing is as simple as it appears <sigh>.
RegardsYuri.
(steam4me)
-------------------------------------
Webmaster
Australian MSTS Add-ons Page
-------------------------------------

Alert | IP

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

LAST EDITED ON Jun-13-03 AT 03:48 AM (EDT)

Hi1st when I say propagate from the rear of one wagon/loco coupling to the front of the next wagon/loco, I assume that thay are using the same type of coupling (either chane, auto, bar, Hydraulic), but what dose propogat is the Stiffness, Damping, Break, r0, CouplingHasRigidConnection and Velocity, coupling type is not propagated unless the consist is pre assembled in a .con file.If you don’t believe me then add a very lose coupling setting in wag file e.g.
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 4.45e5N/14m 2.937e6N/12m )
Damping ( 1.8245e6N/24m/s 2.937e6N/12m/s )
Break ( 2.2e7N 2.2e7N )
r0 ( 30cm 46cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 0.12m/s )
)
#adjust r0 to sute wagon vs size/InertiaTensorNow put a fue of threes wagons in a consist, put some next to each other and some on there own separated by default wagons or ones with normal settings, enter the sim, load up the consist and drive and see what happens.Repeat the above, but put a 2nd Coupling statement in the file for the front, but give the front a normal setting, then agene enter the sim and load up the consist and drive and see what happens agene, you will see that the front Coupling statement it over ridden by the rear Coupling statement of the prior wagon/loco.If we take your example
“The attached image shows a pair of steam locos. Coupling is bar, followed by automatic in the .ENG file. The tender's .WAG file has Coupling set to automatic, followed by bar”so looking from the side it would look like this
front: automatic-----bar-bar------ automatic-automatic-----bar-bar-----automatic
now place the above coupling setting as the front coupling of R711 and see what happens, then reset the coupling value for the frunt of R711 and change the coupling settings for the tender and see what happens.“Point #2: I don't think that the settings propagate or the coupling between the locos wouldn't work”? you have lost me, y wouldn't it not work?B101UK

Alert | IP

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

I have just started in on Texas Tea with your invisocars and almost leapt out of my seat when one of the little beggars started honking, thought I was about to get run over.mervyn@madasafish.com

Alert | IP

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

Know what you mean, I'm just south of the former C&NW Galena line about half mile west of 40th Street yards, and with eastbound Metra commuters and UP freights blowing for the grade crossing at Kostner Avenue every few minutes it's pretty hard to beta test AI horn sounds. The one time I had the windows shut and the computer volume cranked to max so I could hear my own horns, and starting that Texas Tea activity I ended up with two dogs and a cat hanging upside down from the ceiling by their claws. I didn't know dogs could do that.Yuri, BK101UK, like I said I can't either prove or disprove yet. Back before the front coupler patch (when the holding brakes on the loose consists wouldn't release with the front coupler) that was one of the things we tried, and altho it does indeed change the coupler type, I think the values are ignored. Coupling two engines back to back you could couple on with the front coupler of the back engine and have the brakes release, because for that purpose the back coupler of the lead engine was projected back thru the front coupler of the trailing engine, so the front coupler of the trailing engine became, in effect, an extension of the back coupler of the lead engine. Make a consist the other way, with the two engines coupled face to face, and the back coupler of the lead engine worked fine, the back coupler of the helper wouldn't release the brakes on the cars, since it was now an extension of the front coupler of the player engine. Adding a second coupler statement didn't change any of that. Like I said I'm keeping an open mind tho, if I can come up with a test that fails every time using the front coupler of the engine, I'll take shot at the double coupler statements in both cars to se if that fixes it. Maybe an activity starting in Combs Landing with them log flats and plywood cars will do it if I change back to the original geep 38. Possibly this engine hack is working well enough to mask some of the problems with default cars most of the time, I dunno.Well, back on the original topic, I found KnightRider/Trackdancer's thing isn't gonna work with the MS/TA SD40-2, it would appear the pivot point in the .s file is cattywampus or something. With a size of 20.8m in the .eng, and ESD bounding box -10.4 10.4, I get this:Can't get both to center on the knuckles without having two different values. So where in the .s file is the pivot defined?

Alert | IP

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

hiit looks like you nead "Shape File Manager" from
http://www.highworth.freeuk.com/
witch will alow you to move the .s files main pivot point.TA/MS eather fogot to reset the xform for the pivot or it is displaced in order to put it in the center of the 2 bogiesb101uk

Alert | IP

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

OK, thanks, already have shape file manager, forgot about it. I dunno if it will screw anything up, seeing KnightRider/TrackDancer's warning, but I got loads of backup copies.Hmm, as for the double coupler, I tried what I said in the previous post, moved the new hacked GP38 to a backup, replaced with the original default GP38, starting in Combs Landing and coupling with the front coupler to the log flats & plywood cars. Locked up the instant the front coupler touched at 1mph. So I hacked the .eng file:Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m 1e6N/m )
Break ( 1.1e7N 1.1e7N )
r0 ( 20cm 30cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 0.1m/s )
)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m 1e6N/m )
Break ( 1.1e7N 1.1e7N )
r0 ( 20cm 30cm )
)
comment( CouplingHasRigidConnection () )
Velocity ( 0.1m/s )
)And did the same to the log flats.
Then fired up the sim and tried again. Locked up the instant the front coupler touched at 1mph. What you said;"1st when I say propagate from the rear of one wagon/loco coupling to the front of the next wagon/loco, I assume that thay are using the same type of coupling (either chane, auto, bar, Hydraulic), but what dose propogat is the Stiffness, Damping, Break, r0, CouplingHasRigidConnection and Velocity"defines the problem with the whole idea of double coupler statements to attempt to fix front coupler problems, even if it's not ignoring the second statement it's not applying it properly. Best example, try the double coupler statement on an engine and car that you can get to couple with the front coupler, and has the usual difficulty uncoupling. Adding the second coupler statement does NOT make it disengage as easily as the back coupler does, that's because the programming is still using the whole back coupler physics on the front coupler. Engine moving forward at any speed = forget coupler proximity, engine moving backwards at or above 1mph = engage either front or back coupler if they're in proximity to another car's coupler. If you really study how the front coupler engages (with or without double coupler statements), it will NOT engage AT ALL when you push it. What's actually happening is you hit the car's coupler with the engine's front coupler (or the extension of the engine's front coupler thru other cars ahead of it), nothing happens, couplers don't engage. So you try smacking it harder, 2 or 3 mph, and it engages at that speed! Well, guess what, it DIDN'T engage, what happened was you collided at a speed too low to derail and bounced off, and while the engine/first car was moving BACKWARDS on the rebound, couplers in proximity + backward movement at or above 1m/s = engage couplers.
Why it randomly locks up I don't know, but the whole subroutine that governs coupling/uncoupling is programmed for the back coupler only, the only reason the front coupler works at all is due to the rebound (or you can just creep up and touch it, then put the engine in reverse and back up fast enough to engage) and the requirement for exceeding 1m/s is the only thing that allows you to uncouple when backing away.So I dunno, jury's coming back in with a verdict, and it looks like double coupler statements are not gonna be the answer to the front coupler bug. Nothing short of a massive patch that actually addresses the issue instead of just making the brakes release is gonna FIX the damned thing, so in all this kluging around the bug it's important to test thoroughly before (and make sure you can duplicate the failure consistently) and after.Same thing with the SD40 pivot point, if their intention was to center it between the bogies, given the forwards/backwards bugs in the main program what the hell difference does it make? So that's where I'm gonna go with the SD40, get the bounding box equal and where the couplers visually engage close enough, the important thing is to make the damn front coupler work without the lockup/crash/send-don't send.

Alert | IP

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

>Nothing short of a massive
>patch that actually addresses the issue instead of just
>making the brakes release is gonna FIX the damned thing, so
>in all this kluging around the bug it's important to test
>thoroughly before (and make sure you can duplicate the
>failure consistently) and after. I got a wild hair I want to explore this weekend. My understaning of the invisiocar is that it is essentially a zero length, zero power engine. I also understand the divable vcersion has some length, but not enough to screw up the looks. Assuming this is all true when I actually unzip the thing, I was thinking of trying to give it a cab (let's say my reworked cab from the GN GP9m) that faces backwards. (I think this can be done -- don't know for sure.) Then if I build a consist with the invisiocar in the lead, hooked nose to nose with my GN GP9m, then from "inside the sim" it ought to look as if I am drving the GP9m, but I will have a "back coupler" on both ends. If I have any luck I'll let you know. If not, I'll deny ever having the idea
Brad Meyer

Alert | IP

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