SPAD rule

[ctclark1]

I'm curious if a rule or script exists to intercept SPAD events from drivers and change the behavior when one occurs?

I'm thinking the easiest method for this would be to monitor the Message que for these messages and insert a "Wait for" command (time to wait could be chosen in the rule options?) at the beginning of the driver's command list to have them wait for the player to investigate (or at the very least elongate the post-emergency waiting period to make sure things clear up if there was a train in the block that the offending train entered on the red), but don't know how I would begin to script this.

The reason I ask is that most of the SPADs I've experienced end up with the offending trains ending up connected to an innocent bystanding train ahead of it that hadn't cleared the block yet or was waiting for its own green signal, and the 10 second wait after emergency braking is just not sufficient to ensure "safety".

 

[oknotsen]

SPAD abbreviation

SPAD events

For those (like me) who could not remember what the abbreviation SPAD stands for:

Signal Passed At Danger: an incident in which a train goes through a red light

 

[shaneturner12]

I'm not personally aware of one - the only thing we currently have is the 10 second penalty.

Shane

 

[Kennilworth]

Hi

I assume that you are talking about AI trains here? If so then I would be looking at why the train was failing to stop in the first place.

Are you using older locos built for editions pre TS2009? If so the physics were changed in later versions of the sim and the engine-spec may need updating by multiplying the max-accel and max-decel figures by approx 4 times.

Another possible cause is signals incorrectly spaced and not giving the train time to react. A heavy train on a down grade will need signals further apart as it will take longer to stop than it would on an uphill grade.

Regards

Brian

 

[ctclark1]

Brian - I'm well aware and mitigation techniques are usually taken (and in these specific cases I'm mentioning have been attempted) in instances where this happens. That's not what I asked for, but thank you.
Where this typically ends up happening for me is locations where the following driver doesn't change the required junction until it is too late (due to a number of junctions in the same area) and gets the red signal because the route he needs to take is still occupied by a train in front of it (the main line was clear, for example, so the signal was green - upon switching the junction to the spur where his destination is the signal turns red but spacing means it is impossible to stop in time, it is either this or have no signals there at all)- This doesn't happen all the time, but it does happen from time to time. While it may hold up things on the main line if the post-E-braking wait is longer, it would prevent the consists from joining and creating all sorts of chaos (Suddenly a double length train is running somewhere where the original following train has no right being and everything is messed up.) I get it, its not ideal to have happening at all, but that doesn't mean that mitigation of the causes is failsafe, nor does it avoid the fact that a 10 second wait after the fact does not solve anything.

So it sounds like no, there isn't. Like I said I have no scripting experience within Trainz, but I guess I'll spend some time working on learning it and see if there's anything that can be done. I had seen another rule where drivers received penalty points for incurring a red-signal e-brake, so there must be some way to intercept that message, I just have to figure out if this can be turned into a command put at the beginning of the driver's command list.

If anyone has any ideas of how this might be done, I'll be grateful for your help. Thanks. (I know, that's a better question for the scripting forum, but this thread is already here. If I get really stuck I'll post into there.)

 

[Ricke82]

...and insert a "Wait for" command (time to wait could be chosen in the rule options?) at the beginning of the driver's command list...

If you decide to pursue this, you might want to consider using WaitForUser (<kuid:131986:1088>) rather than "Wait for". The AI train will wait until the user manually removes the command from the queue before executing the next command. This will allow player to pause the train as long as needed and remove the need to configure anything.

 

[ctclark1]

Thanks Rick! I actually didn't know there was a command for that, I'll definitely look into it when I get there.

 

[Kennilworth]

Hi again

I'm a little confused here. Whenever a SPAD occurs with an AI train there is a two minute delay before it resumes its schedule. All the scripts used by Trainz are in the Scripts folder and I have just had a look through trainz.gs to confirm this two minute delay (the SPAD section starts at line 5010). Does the 10 sec delay that you mention happen after a SPAD, or does it follow some other event?

If the SPAD is caused by the train setting its final junction too late then I would try one of the path rules to set the full path early enough to give it time to react.

Regards

Brian

 

[ctclark1]

Did it change for 2010? I started in 2006 (haven't yet really run routes in 2010 since I got it, I've been building a new one lately and haven't run into a SPAD problem yet... if I get a chance I'll try to find the route that caused the most problems again and load it up in 2010 to see what happens). In 2006 there the driver would apply the emergency brakes, and then resume schedule 10 seconds after coming to a stop. If this was increased to 2 minutes it would be better and lessen my desire for a script to do this.

 

[fran1]

I've been following this thread and when 10 seconds was mentioned I knew it was wrong, it's 2 minutes in 2010 and 2012.
The only thing to watch out for is if the loco or consist is straddling a set of points, they tend to revert to default settings sometimes.

 

[JCitron]

I have areas like that too but rarely have SPADs. I found that if I slow down the AI ahead of time to 15 mph or less through those areas, they seem to be able to negotiate the junctions pretty well.

John

 

[fran1]

I have areas like that too but rarely have SPADs. I found that if I slow down the AI ahead of time to 15 mph or less through those areas, they seem to be able to negotiate the junctions pretty well.

John

About the right speed, I've noticed on a ladder junction 3-4 sets of points is all they can see ahead.

 

[JCitron]

About the right speed, I've noticed on a ladder junction 3-4 sets of points is all they can see ahead.

I've noticed that too. I have built a substantial yard on the Gloucester Tram route I've reworked (again), and the AI drivers can't seem to find the freight cars that right ahead of them. They happen to be about 5 junctions up the ladder. It takes a bit of coaxing (human intervention), and then their off on their merry way.

John

 

[fran1]

I've noticed that too. I have built a substantial yard on the Gloucester Tram route I've reworked (again), and the AI drivers can't seem to find the freight cars that right ahead of them. They happen to be about 5 junctions up the ladder. It takes a bit of coaxing (human intervention), and then their off on their merry way.

John

The couple to vehicle facing track mark rule is similar, on one side of the yard is the shed with 2 ladders with 5 or 6 points each. Set the default on all points to straight through and they can couple ok, they'll creep down and switch the correct point.
The other side where they couple to a consist anything can happen unless I set the point, they'll go up and down the yard searching usually.

 

[JCitron]

The couple to vehicle facing track mark rule is similar, on one side of the yard is the shed with 2 ladders with 5 or 6 points each. Set the default on all points to straight through and they can couple ok, they'll creep down and switch the correct point.
The other side where they couple to a consist anything can happen unless I set the point, they'll go up and down the yard searching usually.

That is the same as I've seen. They also will drive forever away from a junction unless I stop the drivers and tell them to continue their schedule. Then it's like "Okay, sorry I was talking on the phone and not paying attention. I'll get back to work, and they're off on the right track." This doesn't happen all the time either which is frustrating. Other times the drivers will stop just short of the junction, which I've set with a small radii, and go up the line like they're supposed to.

Ah, the fun of AI drivers.

John