Those Darned SPADs

Mick_Berg

New member
My route is being hampered by one signal that causes SPADs on a regular basis. The track is level and there is plenty of time for the train to stop, and the speed limit is 25mph. Any suggestions as to the best way to stop the SPAD happening? A major problem with SPADs is that after the train has waited the two minutes, it just takes off, regardless of whether in fact the signal is on, and it should not move. This can cause Serious Consequences, to say the least.:eek:
Mick Berg.
 
Is the offending signal on a down-grade? If it is you could add an 'Ai_BrakeFix' to the consist http://www.auran.com/TRS2004/DLS_packcontents.php?AssetPackID=13312
If the "AI_Brakefix" is anything like "AIBrake", it causes all kinds of other problems (stopping at stations etc.) and isn't worth it. And the track is level.
Captain Collins said:
Try putting an invisible signal in front of the problem signal and see if that solves the problem.
I'll try that.

Thanks,
Mick Berg.
 
Did you not read his post?

Oddly enough I did :) There are darn few reasons for a SPAD and downgrade is top of the list. Track may appear level but not be and it doesn't take much of a grade to cause one with a heavy train. Sincere apologies if I caused you to needlessly read a post, and sincere apologies for you having to needlessly read this one. And also many thanks on behalf of Mick for so many constructive suggestions! :)

@ Mick - at the risk of wandering slightly off topic the AI_Brake is a wonderful asset if somewhat temperamental. It works well in TRS06 or later if used correctly (it can't lead a train, two of them can't be coupled together, and it pulls better than it pushes) where it has saved the day in many a session. If you are using TRS04 or earlier though it IS unreliable. There was nothing in your first post to indicate which version of Trainz you are running....

Andy :)
 
Last edited:
Oddly enough I did :) There are darn few reasons for a SPAD and downgrade is top of the list. Track may appear level but not be and it doesn't take much of a grade to cause one with a heavy train. Sincere apologies if I caused you to needlessly read a post, and sincere apologies for you having to needlessly read this one. And also many thanks on behalf of Mick for so many constructive suggestions! :)

@ Mick - at the risk of wandering slightly off topic the AI_Brake is a wonderful asset if somewhat temperamental. It works well in TRS06 or later if used correctly (it can't lead a train, two of them can't be coupled together, and it pulls better than it pushes) where it has saved the day in many a session. If you are using TRS04 or earlier though it IS unreliable. There was nothing in your first post to indicate which version of Trainz you are running....

Andy :)

Thanks everyone. My apologies for using an abbreviation without clarifying it first time. A SPAD is a "Signal Passed At Danger." And BTW I'm using TC3, the route was started in UTC and passed through TRS06.
Actually this time I'd be willing to try an AIBrake, as the driver in question has very little to do, in fact his only demanding task is to stop at the offending signal if needed! But it's only a light little train, a Jinty pulling three coaches. (Who knows if the coaches are braked - how does one know?)
I'll report back.
Thanks,
Mick.
 
Stopping distance

Hi Mick - Just an oddie to throw in but have you checked the stopping distance in trainzoptions? You should see something like this - -"autopilotsignaldistance=500". This is a set distance for your driver to "see" the signal and react.

Just a thought....??

Regards Doug
 
Another possible solution is to open the Jinty config, find the enginespec, then open the enginespec config and edit the 'maxdecel' value to about double whatever it's current value is. That will make it stop quicker. If you want to also run 'unaltered' Jintys, clone the loco and enginespec, modify the cloned spec and edit the cloned loco config to call the modified enginespec...
 
Another possible solution is to open the Jinty config, find the enginespec, then open the enginespec config and edit the 'maxdecel' value to about double whatever it's current value is. That will make it stop quicker. If you want to also run 'unaltered' Jintys, clone the loco and enginespec, modify the cloned spec and edit the cloned loco config to call the modified enginespec...
That's a good idea. I could call the new version "Jinty in need of a lube job....":)
Thanks,
Mick.
 
I have discovered that GP's and SD-40's, 45's--- any trains with a narrow cab are very prone to SPADding. Wide nosed locos, however, rarely SPAD. Must be somewhere in the engine specs, but, as I am not too familiar with that, I don't know how to "fix" it.

Just an observation I have made.
 
I have discovered that GP's and SD-40's, 45's--- any trains with a narrow cab are very prone to SPADding. Wide nosed locos, however, rarely SPAD. Must be somewhere in the engine specs, but, as I am not too familiar with that, I don't know how to "fix" it. Just an observation I have made.

I haven't delved very far into enginespecs but I believe there is a parameter for wind resistance. That would relate to the width of the loco, wouldn't it?
Is the offending signal on a down-grade? If it is you could add an 'Ai_BrakeFix' to the consist
I tried it and it did in fact cure the problem, but in a very ungracious way. The train now decelerated from 25mph to stop in about a second! Doesn't look right.
Another possible solution is to open the Jinty config, find the enginespec, then open the enginespec config and edit the 'maxdecel' value to about double whatever it's current value is.
I haven't tried this yet but will do so soon. I think it will be the solution.
Thanks,
Mick.
 
Back
Top