Oddities with AI and signals

[Approach_Medium]

Hi;
I have been doing some experimenting with AI on my mainline route.
It is mainly single track with passing tracks along the way. I am using Norfolksouthern37's Safetran 08 interlocking signals at the interlockings, and 06 diverging signals at the controlled sidings.

I observed the following when two trains were headed towards each other.

Train 1 is heading north at CP5
Train 2 is heading south at CP26

There are passing tracks between CP7 and CP10, and CP22 to CP26.

I have set AI to drive both trains to and via trackmarks I have installed.
Basically, I placed trackmarks wherever there are diverging routes so that I can tell AI which track I want the train to use.

I have set the southbound train to use the main track at CP26 and again at CP10.
The northbound train is on another track that merges into the single track main at CP10.

The southbound train takes the signal at CP22 and occupies the single track main before the northbound train reaches CP10, so the northbound has to wait; and does (although the train stops a little bit too close to the signal, IMO, so that the driver can no longer see the signal; he is almost directly underneath the gantry when he stops)

So the northbound train is sitting on track 1 at CP10 while the southbound is lined to take track 2 at the interlocking.

Funny thing happens; When the southbound train approaches the signal at CP10, it is a clear signal on track lined main to main. The train slows from the 40mph track speed it was going to 17mph before reaching the signal. Then it speeds up to 40mph again after passing the signal and the junction.

Why did the train slow on approaching a clear signal, and junction lined to a non-diverging route?

Also, I found that the AI trains do not heed restricting (approach, etc) signals if they are permissive; the AI train will slow at the signal, but then accelerate again until reaching the next restrictive signal.

Another thing about AI is that it uses DCC, which is so non-prototypical. The mile+ long train is moving at 32mph approaching an absolute stop signal, and slows to a stop over a distance of about 1/4 mile.

I wish that AI would use the cab controls with better physics than the DCC.

Maybe the next version of Trainz??

One more thing; When a train is approaching a signal, that signal will only "see" the train when it comes within 10KM (6.2mi) of the signal. This causes signals to indicate the wrong aspect, if the next interlocking signal is more than 10KM away.
I don't know, but this may have been the reason my southbound train slowed when approaching the clear interlocking signal. That signal was indicating advance approach, because the next interlocking was still indicating stop (more than 10KM distant), and there was one permissive signal between the two interlockings which was indicating approach.

Still, with the AI running DCC, it should have been able to accelerate fast enough so it would not have slowed so much approaching a clear signal (and had been clear when the train was 1 mile distant).

So it's not perfect. I only wish that I could create some scripts that would override the built-in code in Trainz. This may be possible, but I have to understand the method calls a bit further.

FW

 

[wholbr]

Hi There.
The problem is that trainz is a complex software program and it is not perfect.

However, do you know of any large software program that is perfect. I have certainly never come across one. You just make the best of what you have through workarounds etc.

That would probably be the best solution to your problem just look for a workaround. Re-timing the consists by no more than a minute or two sometimes makes quite a big difference I have found.

Hope this helps
bill

 

[Approach_Medium]

Hi There.
The problem is that trainz is a complex software program and it is not perfect.

However, do you know of any large software program that is perfect. I have certainly never come across one. You just make the best of what you have through workarounds etc.

That would probably be the best solution to your problem just look for a workaround. Re-timing the consists by no more than a minute or two sometimes makes quite a big difference I have found.

Hope this helps
bill

You're absolutely correct. I have never found a perfect software program. I'm not so much complaining (although it may appear that way) as I am trying to glean information from other Trainz-ers who get serious about signaling and AI.

There may actually be a method to change the way AI behaves with signals; by creating or adding to an existing script, that calls Trainz "Accessor methods". Depending on how Trainz was coded, it may or may not be possible to override the default code.

One thing I found is that the 10KM limit on train distance from a signal is hard coded. I have already attempted to alter the signal.gs script, but it generated errors, and the signals refused to work at all.

I agree with you 100% that one needs to be intuitive and create work-arounds. That's one of the things that makes this game so interesting.

I am learning Java programming, and since it is close enough to game script, I can use what I have learned to better understand the various script files in Trainz and its assets.

What I would like to do eventually, is create a "signal controller" thingy, similar to mizi's Junction Controller. This would allow us to have better control over what the signals do. Thing is, I have to get a much better understanding of how Trainz interacts with the scripts, and how AI reads signals.

Actually, I can completely avoid any of the AI problems by not using AI<g>.
But it gets a bit tough to handle a local working the industries while trains are running on the mainline. At least AI works well enough to keep things running, and so long as I pay attention to the signals while running trains myself, I can avoid the embarrassing corn field meets, or worse; the crashes.

Edit: Actually, taking a closer look at the script files in Trainz, I think it's closer to c++ than to Java. The :: gives it away.

FW

 

[norfolksouthern37]

Hi;
I have been doing some experimenting with AI on my mainline route.
It is mainly single track with passing tracks along the way. I am using Norfolksouthern37's Safetran 08 interlocking signals at the interlockings, and 06 diverging signals at the controlled sidings.

Frank, are you are still using my first version of the re-written signal code? this has had many many revisions since it was made and only you have had it to test. this cannot be confused with normal trainz signals. they are not the same.

I wish that AI would use the cab controls with better physics than the DCC.

i dont think this would be wise. this would use more resources with hardly any effect. the real answer is to properly configure the max accel and max decel values of that engine.

Also, I found that the AI trains do not heed restricting (approach, etc) signals if they are permissive; the AI train will slow at the signal, but then accelerate again until reaching the next restrictive signal.

trainz has no way of determining a permissive approach or anything else as they do not exist. the only permissive aspect is the permissive stop. other than that, there is no difference from any other signal.

One more thing; When a train is approaching a signal, that signal will only "see" the train when it comes within 10KM (6.2mi) of the signal. This causes signals to indicate the wrong aspect, if the next interlocking signal is more than 10KM away.
I don't know, but this may have been the reason my southbound train slowed when approaching the clear interlocking signal. That signal was indicating advance approach, because the next interlocking was still indicating stop (more than 10KM distant), and there was one permissive signal between the two interlockings which was indicating approach.

yes if there are not enough signals to clear through, you will get a lower aspect, this is an expected behavior under both mine or trainz signals.

Still, with the AI running DCC, it should have been able to accelerate fast enough so it would not have slowed so much approaching a clear signal (and had been clear when the train was 1 mile distant).

was it clear or was it advance approach? trainz will always slow for an advance approach. this is not part of the signal scripting but built in. i have since tried to keep this aspect from happening as much unless it absolutely needs to., it sounds like in your case it would still have shown if the signals were too far apart to clear the farthest signal.

 

[Approach_Medium]

Norfolksouthern37;
Frank, are you are still using my first version of the re-written signal code? this has had many many revisions since it was made and only you have had it to test. this cannot be confused with normal trainz signals. they are not the same.

The version I am using is "Safetran_Colorlight_SH_V2.cdp, and "Safetran_clight_v2.cdp.

These are the ones you e-mailed to me back in Oct 2009.

FW

 

[norfolksouthern37]

yes you were the only one to have them, and they are not what i would call a finished state. send me a message ill see if i can update you.

 

[Approach_Medium]

I found the reason for the train slowing on approach to the clear "08" signal. It was the track marker I placed on each track (3 tracks).
When I use a "Navigate via trackmark", the train slows down at the junction where it has to throw the switch (but in this case, the switch is already in the correct position) to proceed on the proper track according to the navigate via command.

If I simply give the Navigate to trackmark without any navigate via command, the train will not slow down at the junction.
It apparently has nothing at all to do with the signal.

Now there's another oddity: The train is proceeding on the single track with max speed (default) of 40mph, at track speed.
After proceeding past the junction which branches into 3 tracks (two junctions), and the last car is about to clear, but has not yet cleared the junction, the track speed jumps to 50, and the train speeds up to match that.

As far as I know, I don't have any speed markers, but I once did, so there may be one left. I'll have to look around for it.

So, I don't know if this is a "bug" in TS2010 with the Navigate via trackmark command, or if it's the expected protocol, since normally, the train crew would probably have to slow down to at least check the position of a manual switch. This is not a manual switch however; it is controlled by the dispatcher's CTC system. Of course Trainz doesn't have a CTC system, but maybe there is a way to alter this action?

FW