AI and the useless "Drive" command issue ..Tony are you listening ???
- Thread starter Railhead001
- Start date
Railhead001
New member
So how goes Euro truck simulator these days Dave ?
Vuil_Sekreet
Member
Why is it cancelled?
Vuil_Sekreet
Member
Deleted by poster
Railhead001
New member
The "Drive" command itself probably has a time delay feature that checks every so often to see if the signal/junction is clear ahead but if that time limit is passed then that check is not performed anymore so the train will just stay where it is even though the junction/signal is clear to proceed.
Example: train comes to red signal, time delay for Drive command in loco say is 2 minutes. train waits for 2 miunutes. Signal stays red. At two minutes and 30 seconds signal turns green because block ahead is now clear but since the Drive command is set for only 2 minutes, it does matter what happens after that time passes. Train will just stay at location now until manually taken over or issued another command.
Last edited:
Vuil_Sekreet
Member
That is exactly how I perceived it as well. I agree with you the simplest solution is to extend the time it takes the "drive" command to time-out, or change it so it doesn't time-out at all. I am wondering whether there is a reason to have it time-out.
I think the timeout is a function of the computer controlled driver being stuck and issuing a message to player that the CC driver needs attention. If the player does nothing the current command is abandoned. I've seen that happen on other commands besides Drive. Sounds like an error trap subroutine to kill an endless loop. Back in the old days Trainzscript could eat up a lot of CPU cycles and really slow down the game so it makes sense to kill a stuck command.
William
William
Railhead001
New member
Watch my video, it only gets stuck when the wait is longer, the 1st train has no problem changing the junctions or the second, but when it returns back the 1st train is now slower making more stop and proceeding but making 2nd train wait longer, not in the video I posted but I can if needed
Railhead001
New member
Wrongo again, look at my video previously, geezuz..........the train is stopped at a red signal, the junction changes and it goes green........what part is so hard to comprehend ??? that's the point of drive..............lord this is hilarious.....................you have proof in front of you and you can't even see it. Chug that koolaid....
Here you go so you don't have to reread to find it: Watch as the Only command selected is "Drive" for both trainz...magic as the train proceeds onwards without being programmed for an industry or trackmark, amazing how the AI can function at times.....maybe its voodoo, the signals change, trains move on yadda yadda
Bigger is better: https://www.youtube.com/watch?v=yGdJX851Q0U&t=22s
You sir are a wee bit misinformed.........drive actually can do a lot more than you think it can, maybe before jumping to conclusions you should see the previous comments such as the above reference video or jsut for giggles, try it yourself..............
Last edited:
That was the case the last time I used the "Drive" command without any "to" or "via" qualifiers - and that was a long long time ago.
I took Railhead's advice, purely for a "giggle" (as he described it), and tested the loco popup menu "Drive" operation on a large layout with only the one loco. Ahead of the loco was a signal and beyond that a switch set against it. The signal was obviously at red, as expected. The loco moved up to the signal where it halted and waited. After a short delay the switch was thrown and the signal changed to "proceed" to give the loco the road, and off it happily moved.
The question then becomes how long should this special Drive command wait if it has an opposing switch/signal? It is not a normal driver command sitting in the Driver Command Bar so it cannot be cancelled by the user, nor can the user see that a Drive command is active on the loco.
A similar problem occurs with the "Drive To ...", "Drive To Trackmark ..." and "Drive Via Trackmark ..." driver commands. They will not attempt to find an alternative path around a blockage, like the "Navigate ..." driver commands do (sometimes annoyingly), so a consist can sit at the blockage point for an eternity.
IMHO it is a minor issue and not a show stopper. It can wait on the "to do list" until other more pressing issues have been resolved.
Railhead001
New member
Pware,
Its your opinon it is not a show stopper, for me it is and that is my opinion and it has been known issue/bug since TMR2017 when I reported it directly to Tony. So how long should it be before its resolved ?? a year, a decade never ? Sorry, I degress...if you jsut want to watch or "railfan" it is a total disappointment for multiple trains but for "operating" you are correct and definitely not a show stopper in that scenario (no pun intended or maybe it was). Again eye candy over AI, TSW anyone ???
Its your opinon it is not a show stopper, for me it is and that is my opinion and it has been known issue/bug since TMR2017 when I reported it directly to Tony. So how long should it be before its resolved ?? a year, a decade never ? Sorry, I degress...if you jsut want to watch or "railfan" it is a total disappointment for multiple trains but for "operating" you are correct and definitely not a show stopper in that scenario (no pun intended or maybe it was). Again eye candy over AI, TSW anyone ???
I reported a "bug", using the bug reporting system, in the way driver games were saved 4 or so years ago in the early days of TANE (if I can remember correctly) and posted about it in these forums. Basically data about the state of layers (hidden/locked) was not being correctly saved in the games. No-one else confirmed my report or posts so it seemed that I was the only one that had the issue or the only one for whom it was important. But as I was able to reproduce it on multiple routes and on 3 different PCs it was clearly not an issue with my hardware or software setup.
I resolved the issue by using a complex workaround in my sessions that mostly overcame the problem and I then forgot about it and moved on.
When TS19 was released I decided, for a "giggle"(TM) , to try it again and was amazed to see that the bug had been fixed.
I resolved the issue by using a complex workaround in my sessions that mostly overcame the problem and I then forgot about it and moved on.
When TS19 was released I decided, for a "giggle"(TM) , to try it again and was amazed to see that the bug had been fixed.
Railhead001
New member
Growing up, as a kid, my favorite cartoon was RoadRunner, gotta love that Wile E. Coyote. They say he was a "Super Genious"
"
"
It can be cancelled by the user at any time. Same as you can right click on the loco or in the Driver Command bar and select "Drive" you can also select "Stop Train"
That will kill the Drive command.
Ahhh. I did not know that. Until yesterday I have never used that "Drive" command.
I'm not certain that I've read anything about the drive command. I just learned what happened when i used it.
Railhead001
New member
So then that's just your opinion and nothing more, my experience with the Drive command is different than yours and I took the time to document mine. I also find as long as the block signal system is correctly set up the only issue i have is with the timing out issue. It takes time to set up a functioning signal sytem with trial and error but I managed to do so on Coal Country with the addition of several signals and then rearranging them so they could function togethor correctly and have the proper space to have the correct length of trainz fit.