AI Gets Dumber

Alikiwi

Apprentice Creator
I know we've talked about this before but the AI in TRS19 is beyond pathetic. If the game is to continue I hope they make this a priority, or we may as well give up. My latest hurdle with dumb... hm, is trying to get the AI to couple to 6 of 18 wagons, drop 12, move out of the siding, then back up to the container terminal, and load those six. It should move forwards again, then back into another siding, drop those 6 and collect the next set. There are only two trackmarks to guide it and I specify which wagon to couple or uncouple, not that complicated really.

The best I get is it loads the first 6, and then sits there, but now only loads the first one and stops.

However, in Tane, on the same route (Port Tillamook) with the same orders, it works perfectly from the very first attempt to set it up! I can see why some people have dumped TRS19 and gone back to Tane, the frustration is huge, putting it mildly. I don't suppose anyone has some tricks to get the AI to follow simple clear instructions?
 
I don't suppose anyone has some tricks to get the AI to follow simple clear instructions?

Anyone who could do that will be instantly offered a position on Google's Quantum Computing Project.:)

I know that the AI can be a "hot" topic but I have rarely had any problems with it - mainly because I keep my expectations low. The "I" in "AI" has never stood for Intelligence.

There are too many variable involved in even a simple set of instructions, especially when coupling, decoupling and loading/unloading operations are involved. For example: are you using the built-in <kuid:-3:10082> Decouple command? This command does not work correctly when used in the Driver Setup Rule - use one of several alternatives such as <kuid2:160293:100120:2> Decouple DLX
 
No, not using that decouple command, but then that isn't the problem as stated. It simply will not drive out of the container terminal, a simple 'drive to' trackmark, followed by halt, then drive to another trackmark to uncouple the first set. I might try removing the halt command, but it just got worse! Thinking there may be something hidden or faulty in the route I took a close look at the track into the container yard. The last junction didn't show a gap between the end of the blade, so it couldn't show switching from one direction to another, so I fixed that....

Well that just made it horribly worse, the AI now doesn't stop at the first trackmark (which is 'drive to'), followed by 'halt.' No it just keeps going at full speed no matter what!!! So, it doesn't reverse and go through the fixed junction into the yard, so doesn't even load. Makes absolutely no sense and yes the "I' in AI must mean illiterate!

As for the uncouple which isn't a problem, I use <kuid2:66277:80005:2> UnCouplezFrom. The problem is purely ignoring trackmarks, of which I'm only using two, so hardly a case of too many which has been a problem in the past. Must admit to getting tired of all these issues, I think if I can't resolve it soon, I'll just make it in Tane were it works perfectly, bad junction included! :)
 
Do you have any signals within the yard? I found that if there's a signal placed so that the aspect faces towards incoming trains, the AI will sit there and not move, but maybe at 0.5 km/h if we're lucky. The other thing I noticed is junctions if the junctions were aligned ahead of time, once the signals were removed, the I switched fine, but if the junctions were left randomly aligned, they acted stupid When instructing the AI to do something, I find manually stopping them once they've executed some commands seems to shock the driver into submission. If this isn't performed, the AI have a tendency to drive off to nowhere before returning to couple to the next consist.
 
Does the static population(trains) have any bearing on the faulty operation in a yard? Perhaps as the incoming train approaches the yard a sudden exposure to a new set of data overwhelms it. This could be exasperated by the AI uncovering more and more data to process while it deals with things it already has whose locations are changing due to motion of the incoming train.
 
Does the static population(trains) have any bearing on the faulty operation in a yard? Perhaps as the incoming train approaches the yard a sudden exposure to a new set of data overwhelms it. This could be exasperated by the AI uncovering more and more data to process while it deals with things it already has whose locations are changing due to motion of the incoming train.
Thanks Dick. You just left me with a mental picture of an overwhelmed Artificial Idiot in a corner having a blathering anxiety attack:hehe:
cheers
Graeme
 
Does the static population(trains) have any bearing on the faulty operation in a yard? Perhaps as the incoming train approaches the yard a sudden exposure to a new set of data overwhelms it. This could be exasperated by the AI uncovering more and more data to process while it deals with things it already has whose locations are changing due to motion of the incoming train.

This used to be a problem in the past, but more recent railcars have a "kill switch" script that disables their train-car status until a consist is coupled to a locomotive. I know Jointed Rail does that, and I think others have adopted the same feature. This doesn't say that this isn't the case for all the freight cars we have are setup this way.



Thanks Dick. You just left me with a mental picture of an overwhelmed Artificial Idiot in a corner having a blathering anxiety attack:hehe:
cheers
Graeme

I had the same. I can see it now. The AI pulls into a terminal and sees an overwhelmingly large array of tracks and lots of freight cars. The AI driver stops the train in emergency, takes a dive into the corner while screaming loudly and grasping both sides of its head!
 
I discovered too if the point work is really complex, the AI will sit and ponder before moving. They act as if they're figuring out what each and every junction does and where each track goes. If there are any signals in between, the process doesn't go well. My patience with the AI runs pretty thin, and I end up intervening.
 
For one this is yard work so it's in the yards, not approaching then. And yes a lot of close junctions and small signals at every one of them, so I may try the wait for 5 secs. But N3V should take note of the fact the AI is very clearly dumber than in Tane and that's a horrible backwards step, and a game killer. As said in my original post, no problem in Tane. As for other trains in the yards, one leaves at start and is gone before the problem starts. One other comes in and drops some flats and parks itself after decoupling. There is only one junction against it (which it used) that it needs to throw after loading the containers, so not exactly busy but I'll get that 'wait' idea a go. Spammers bugger off lol :p
 
For one this is yard work so it's in the yards, not approaching then. And yes a lot of close junctions and small signals at every one of them, so I may try the wait for 5 secs. But N3V should take note of the fact the AI is very clearly dumber than in Tane and that's a horrible backwards step, and a game killer. As said in my original post, no problem in Tane. As for other trains in the yards, one leaves at start and is gone before the problem starts. One other comes in and drops some flats and parks itself after decoupling. There is only one junction against it (which it used) that it needs to throw after loading the containers, so not exactly busy but I'll get that 'wait' idea a go. Spammers bugger off lol :p

Yes, I agree this needs work again. The AI were tweaked and worked really well in TANE for awhile, but then SP2 came out and broke the lot. SP3 fixed things again, but that broke them again to a certain point because stuff was weird so the AI behavior was reverted to pre-SP2. This worked fine. Then comes TRS19. Everything worked the same until SP3. Now things are borked again.
 
Well this is TRS19 SP1. I added the wait... utterly useless, it just sits there, doesn't change it's direction facing, doesn't delete the wait 5 sec command even after 5 minutes! Ignoring the fact it works perfectly in Tane (even SP4), I got suspicious as the Tillamook route has a slight habit of crashing the game, always (mostly) on loading a session. I look at the log and found a few errors and oddities, a brief copy shows >>>
[h=2][FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]<NULL>VE170: Failed to open compiled texture 'ash3.texture' for'arc:fld:$(packages)/sc484f_8/content||kuid2 9000 38001 2.tzarc|' Nosuch texture mentioned in config file, no errors in CM!? Invisibletrack by Weevil[/FONT][/h][FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]-<NULL> VE170: Failed to open compiled texture'qrdarkgrey.texture' for 'arc:fld:$(packages)/sc484f_8/content||kuid29000 38001 2.tzarc|'[/FONT]
[FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]-<NULL> VE170: Failed to open compiled texture 'bark34.texture'for 'arc:fld:$(packages)/sc484f_8/content||kuid2 9000 38001 2.tzarc|'[/FONT]
[FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]-<NULL> VE170: Failed to open compiled texture'cattlefence.texture' for'arc:fld:$(packages)/sc484f_8/content||kuid2 9000 38001 2.tzarc|'[/FONT]
[FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]?- <NULL> ClientGeometryNode::UpdateInfluenceBufferNow> meshwas not loaded animated[/FONT]
[FONT=Tahoma, Calibri, Verdana, Geneva, sans-serif]Nowdeleted/replaced that with invisible track BNSF, now also see this>>[/FONT]
-<NULL> MeshObject::NotifyGameModeChanged> unable to findattachment point 'a.stop03' on asset <kuid2:39134:102036:2>"YARNish Intersection L2 -4Si +2Sh-2Sh, 09sp4"
; <NULL> World.NativePlaySound> Cannot find asset '<kuid2:39134:102036:2> "Grade Xing NRC LED Gated"' in scene.

NOTE <kuid2:506208:100023:3> YARNish Intersection L2 -4Si +2Sh-2Sh, 09sp4, so NOT same kuid as Grade Xing NRC Gated!!!!

It seems to be confusing kuids here, but I'll check the intersection for a missing attachment point.....
 
I would run a DBR, but I have run into errors like that shown in the log but the asset loaded. I ended up fixing the asset anyway and the asset loaded quicker.

This situation isn't unusual due to the error checking as it is. If the asset is very old, then the errors are ignored for that build-level and only a warning is produced. As time went on starting from TRS2006, the error checking has gotten stricter, but the error checking is only as good as the build-level. This has been the situation since this started in order to retain compatibility.

If you decide to repair the asset, don't change the build-number, otherwise, that can break something else.
 
Hm, I checked the Yarnish intersection (although I see no way it could have an effect on this problem) and found all 4 attachment points present. I am also seeing 40+ entries repeating this <NULL> World.NativePlaySound> Cannot find asset '<kuid2:39134:102036:2> "Grade Xing NRC LED Gated"' in scene.

Again, I can't see how it could affect the AI driver, but who knows. Admittedly that item is Build 2.7 so a tad old and they aren't being used in the area in question. I had one different wellcar so I replaced that and matched with the bulk of them, so I replaced the lone <kuid2:101046:100390:2> TTX 53 ft Wellcar with <kuid2:45324:300005:5> TTX weathered 53 Husky Stack to match the other 17. Result, it now loads the 1st end wagon and stops! Think this is getting to the point of giving up, it shouldn't be this hard to make a session.
 
I recently started using the AI directly from the Driver Command Bar in Driver mode - not through the Driver Setup Rule in Surveyor.

I have noticed that when issuing a "Driver To" command the AI will immediately take off in the direction that the train is heading (as indicated by the red/green arrows above the consist) even if the actual destination is in the opposite direction. After a period it seems to recognise its "error", stop and reverse direction but sometimes taking a different path back.

If the train heading is correctly set before issuing the "Drive To" then the AI will move off in the correct direction.
 
Back
Top