AI Driver Commands Skipped

jhdale65

Member
Could someone please explain why when I place a train on a route and put in AI driver commands, frequently the commands get skipped and I watch the commands disappearing, also trains will stop at AJS station doors open but passenger don't load This is beginning to get quite infuriating. I have TS 22 PE Build 123801
 
This sounds like you are probably issuing commands that are unable to execute for some reason. If you could give us more details, we can probably help more.
 
This is possibly another issue with the old AJS stations. The scripts for these stations are a bit flaky since the updates to TRS19 and TRS22 with such things as the station height, numbers, and number of passengers not "sticking" to the configuration when saved.
 
Sometimes placing a 5 second wait command between driver commands may help, but as John has said N3V's latest 'updates' have broken some assets that were working perfectly well before being 'upgraded' by the latest build version release.
 
I have this problem with skipping through commands. I give a train a set of commands either directly or using a library of commands from schedule library, and suddenly, it jumps from one command to the next then to the next... the train stops and no commands are left. Its racing through them without applying them - essentially deleting them. Is this an issue with Trainz22Plus? Not had it in the past. I'm using standard commands so there should be no issue with the command itself.
 
This is one of two failure modes when an AI driver cannot execute a command for some reason: The command that failed is removed from the schedule and the next command is tried in its place.

The other failure mode results in the driver dropping out of AI mode without removing the failed command. Instead, the train just sits there like a lump.

These two failure modes have been around since driver commands themselves were created.

To the best of my knowledge, any given command will always fail in the same way each time. In other words, when command X fails, it always drops the train out of AI mode, while command Y always deletes itself and allows the schedule to continue.

Sometimes we give a driver a command that simply cannot be performed. What happens apparently depends on how the command reacts to the failure.

Commands that report the failure would appear to always drop the driver out of AI mode, while commands that swallow the failure are simply allowed to drop out of the queue as if they had succeeded. I have not tested this to prove that this is why a command reacts a particular way, but it does explain the observed behavior better than anything else I know of, accounting perfectly for each observed possibility.
 
After an hour or so of testing, have tracked my problem, and it makes sense wrt what MasterTracklayer says above. I had copied a session and given new name to test an idea. basically was using THRoute paths instead of Enhanced Tower. I had not changed the Drive to or Drive Via commands to Autodrive to/through. It didn't like it, hence the skipping. Changing the Drive to Autodrive etc solved the issue. It can be inconsistent in the sense that previous Trainz versions sometimes allowed Drive via after THRoute or Path control - more recent 22+ seems unforgiving if you don't follow the rules! Thanks for the explanation MasterTracklayer.
 
You are very welcome. Having had this on my mind for a while, it occurs to me that there is a discussion of this in the include file that driver commands inherit their base class from, that I recall having read Back In The Day, when I was running Trainz 2004 and Trainz 2009/2010. I`m sure that it will confirm my analysis. It is also probably where I got my information from in the first place.
 
After an hour or so of testing, have tracked my problem, and it makes sense wrt what MasterTracklayer says above. I had copied a session and given new name to test an idea. basically was using THRoute paths instead of Enhanced Tower. I had not changed the Drive to or Drive Via commands to Autodrive to/through. It didn't like it, hence the skipping. Changing the Drive to Autodrive etc solved the issue. It can be inconsistent in the sense that previous Trainz versions sometimes allowed Drive via after THRoute or Path control - more recent 22+ seems unforgiving if you don't follow the rules! Thanks for the explanation MasterTracklayer.
That sounds like a bug since this worked previously. I would report that via the bug report form.

 
Contributed driver commands that do not function or choose not to function can have various outcomes depending on the author, In my commands, I tried to print a message to the driver console to indicate the situation. In most cases, a member function simply returns a false to the system.
 
Exactly. What happens afterwards depends on that return value. One value tells the system that the command failed and the schedule should be interrupted, and the other that the command succeeded and the next command should be run. Whether the return value matches the actual state of the command is up to the author. Not limited to contributed commands, either. Company-supplied commands run under the same conditions.
 
Exactly. What happens afterwards depends on that return value. One value tells the system that the command failed and the schedule should be interrupted, and the other that the command succeeded and the next command should be run. Whether the return value matches the actual state of the command is up to the author. Not limited to contributed commands, either. Company-supplied commands run under the same conditions.
With these particular commands it sounds as if the return was null therefore the commands were ignored and skipped over. If there was an error trap of some kind, the train could halt instead. Back in my olden days, I used to read through output logs from JCL scripts looking for error codes to ensure a job completed successfully on the IBM 3270. Any error code other than zero required us to report the error to the support team. JCL was fun to work with. A character out of place could cause the whole script to barf.
 
A return of false does not necessarily mean the command has failed. There are a of calls that the command does not need to process, but can wait for subsequent calls in the same command instance.
 
True. That is beyond the scope of what appears to be the original intent of the feature, but that just means that scripters have been clever about their use of the feature.
 
Not always. For example, I can return a null from drivercommand.gettooltip() without indicating that the subject driver command failed.
 
I upgraded to Trainz Plus Build 123794 and am having a similar problem with a session no longer operating the way it did in previous builds.

I have a route with several commuter rail lines and I use DRIVE TO and LOAD at each station. This always worked well until Build 123794. Now, at random stations on several lines, the train hangs up at LOAD and never leaves the station. This happens at both AJS Invisible Station 2T Island, kuid 2:122285:3403:20 and AJS Invisible Station 1T 3.5, kuid 2:122285:3401:22, but not at every station.

So, in my case, I don’t have skipped instructions but rather LOADs that never complete. Now I wish I had remained at the previous build. I have replaced stations but then the problem happens somewhere else. Are their better invisible stations out there to try?
 
Not always. For example, I can return a null from drivercommand.gettooltip() without indicating that the subject driver command failed.
That is beyond the scope of what appears to be the original intent of the feature, but that just means that scripters have been clever about their use of the feature.
I was comparing current usage against what I recall the code comments saying about the intended use of the feature, and complementing scripters in the process.
 
Back
Top