Drive to problem

Ghost42

Well-known member
I don't think it is just my copy of TRS22 but 'Drive to trackmark' does the same thing as 'Navigate to trackmark'.
I find consists static in queues and when I try to manually kickstart them I find their direction has reversed, behaving as though they are trying to find a way around the consist in front..
Normal behavour is to plough on ahead to the trackmark.
 
This usually happens if there's something wrong with the track ahead such as a broken connection, missing junction lever, or maybe a direction marker facing the wrong way. (I have much experience with the latter...)

Check the message history and scroll through the driver messages. You can find that option under the gear located over the driver's image on the left side. The message(s) may have zipped passed too quickly for you to see due to the number of superfluous messages such as approaching signals.
 
One of those improvements that came with '22 was the fact you can 'view details' of the engine and check its movements, though nothing seems amiss.
The last command will be to a trackmark usually though it is trying to reverse away from it.
If I drive it manually its heading will change and the Schedule will then kick in again.
 
One of those improvements that came with '22 was the fact you can 'view details' of the engine and check its movements, though nothing seems amiss.
The last command will be to a trackmark usually though it is trying to reverse away from it.
If I drive it manually its heading will change and the Schedule will then kick in again.
I haven't checked out the details like that. Hmm.

There's something (doh, that's obvious right), amiss here. I have seen drivers get stuck at signals and had to give them a poke. I wonder if you're seeing the same thing.
 
I do not know much about the other issues, where the train is failing to do what you want, but I can confirm that there is very little visible difference between the Drive To commands and their Navigate To equivalents. I do know that they call different native-code entry points, though, so there should be some difference, however subtle. The fact that neither causes the train to go anywhere does strongly indicate that there is an issue with the route itself (or the session, perhaps). Like they said above, check that there are no other trains, junctions, signals, or other obstacles in the way that could be preventing successful navigation.
 
I do not know much about the other issues, where the train is failing to do what you want, but I can confirm that there is very little visible difference between the Drive To commands and their Navigate To equivalents. I do know that they call different native-code entry points, though, so there should be some difference, however subtle. The fact that neither causes the train to go anywhere does strongly indicate that there is an issue with the route itself (or the session, perhaps). Like they said above, check that there are no other trains, junctions, signals, or other obstacles in the way that could be preventing successful navigation.
Here's a good explanation from a relatively recent forum discussion on the subject.

 
Good to know. Now if someone could tell us how they were intended to differ so we can decide if this is a bug or just a misunderstanding.
There may be a bug with Ron's signals. He uses the UK signals with feather indicators and other scripts that may have been impacted by the latest updates. Thinking about his problem, I've seen others mention similar issues as well with their routes.

If it isn't the signals, sometimes resaving the route and session to update to the current version may solve the problem. I have found this has helped in the past with issues like this.

As always, backup the routes and sessions just in case something doesn't go as planned.
 
I have an instance that when I start my session there are two lumber consists waiting to feed Sap_factory_8_gengoods, the nearest one proceeds to deliver, when it reaches its destination the second one reverses up to jump the queue.
The track direction marker seems to have no authority and can be ignored by the consist.
I back it up by putting an invisible signal nose to marker nose, that works!
As soon as the first consist clears the second then behaves normally.

When a queue refuses to restart I usually find, by driving the lead consist manually that it was trying to reverse up, as a consist had previously stopped in front of it.
I never had these problems with TRS19.
 
There may be a bug with Ron's signals. He uses the UK signals with feather indicators and other scripts that may have been impacted by the latest updates. Thinking about his problem, I've seen others mention similar issues as well with their routes.

If it isn't the signals, sometimes resaving the route and session to update to the current version may solve the problem. I have found this has helped in the past with issues like this.

As always, backup the routes and sessions just in case something doesn't go as planned.

I'll take note of the signals used in the built-in routes which appear to work flawlessly.
 
That's both good and bad to hear/read. The content-creator, or someone else, needs to look into the signal problem.
Perhaps someone can give indications of signals that do work. I want signals that look like Australian or British ones and which normally stand to the left of the track. I don't usually have problems wtth the ones I have picked, but if there are better suggestions or suggestions on which signals to avoid, I would like to read them.
 
Is it just me? You used to be able to examine signals and switches and change their range of sensitivity, which is often a greater distance than is useful. Now, when I look at "details', I can't see anything like that.
 
You used to be able to examine signals and switches and change their range of sensitivity, which is often a greater distance than is useful. Now, when I look at "details', I can't see anything like that.
I have never seen the option to change the "range of sensitivity" of signals and switches in any version of Trainz.

You can change the "action range" of trackmarks and triggers. In S20, for example, there is a small green dot next to a selected trackmark that can be dragged forward and backward to adjust its action range. In Surveyor Classic you type the range value in the Track Tools advance tab.
 
In response to the original post, here is my reply to the same question in another thread. Nothing that I have seen in Trainz Plus or TRS22PE has altered my understanding (described below) of how this works.

Drive To
Instructs the AI driver to Drive, via the shortest available path, to the designated Track Mark, Industry or Destination. Switches ahead of the train that are not locked against the AI will be set to allow the train to proceed and reset after the train has cleared the switch. The AI driver will NOT attempt to find a way around blockages when calculating the shortest path to the Track Mark. All signals and speed signs along the route are obeyed.

Navigate To
Instructs the AI driver to Drive, via the shortest available path, to the designated Track Mark, Industry or Destination. Switches ahead of the train that are not locked against the AI will be set to allow the train to proceed and reset after the train has cleared the switch. The AI driver will attempt to find a way around blockages when calculating the shortest path to the Track Mark. All signals and speed signs along the route are obeyed.

Navigate commands can lead to the consist taking unusual paths to its destination. Drive commands can lead to the consist becoming "stuck" until the path is cleared.
 
You used to be able to examine signals and switches and change their range of sensitivity

To my original reply ...
You can change the "action range" of trackmarks and triggers. In S20, for example, there is a small green dot next to a selected trackmark that can be dragged forward and backward to adjust its action range. In Surveyor Classic you type the range value in the Track Tools advance tab.

... I would add Whistle Sign objects as having an adjustable "action radius" (or "trigger radius" as Surveyor calls it).
 
In response to the original post, here is my reply to the same question in another thread. Nothing that I have seen in Trainz Plus or TRS22PE has altered my understanding (described below) of how this works.

Drive To
Instructs the AI driver to Drive, via the shortest available path, to the designated Track Mark, Industry or Destination. Switches ahead of the train that are not locked against the AI will be set to allow the train to proceed and reset after the train has cleared the switch. The AI driver will NOT attempt to find a way around blockages when calculating the shortest path to the Track Mark. All signals and speed signs along the route are obeyed.

Navigate To
Instructs the AI driver to Drive, via the shortest available path, to the designated Track Mark, Industry or Destination. Switches ahead of the train that are not locked against the AI will be set to allow the train to proceed and reset after the train has cleared the switch. The AI driver will attempt to find a way around blockages when calculating the shortest path to the Track Mark. All signals and speed signs along the route are obeyed.

Navigate commands can lead to the consist taking unusual paths to its destination. Drive commands can lead to the consist becoming "stuck" until the path is cleared.
In my experience with Navigate To, at the slightest hint of a hold up, the driver will take any route possible to avoid it. If the route is circular the driver will frequently go the longest possible way round.
Drive To has its limitations, but it's easier to set and, in my opinion, usually works better.
 
There appears to be a snotty bug with these commands.
https://forums.auran.com/threads/ai-behavior.176531/

You are not going insane as you thought and are doing nothing wrong. The AI will back up, blow through track direction markers, etc. I solved the issue using wait... commands on my Gloucester Terminal Electric route, but that only has about 20 drivers, and I only had to modify five of them. I can't imagine how this would be for larger routes and sessions. Hopefully N3V solves this in a future update.
 
Have something strange, made a test loop track. all the joints are sealed as a loco on it's own goes around without a problem.
as soon as you couple a consist to it ,
it will not complete the loop and want to go backward to the siding.
you manually drive past the half way point and sit it back to auto it will drive without a problem.
does not matter how you tell it to goto the siding it will still want to go backwards.
 
Back
Top