Is AI stupid on purpose?

Well I agree with CRR. My switches are always on the edge of the spline circle, see pic.

junctions_zps5ef4c9bf.jpg


Note I also have an invisible signal on a crossover, this causes the trailing junction to change much sooner that if you have no signal there.
Generally speaking, trains must have at least one signal between each junction.

Cheers,
Bill69
 
I could never understand why when you put a track speedboard of 10 mph, and the HUD says it is a 10 mph speed zone ... all of a sudden AI goes suddenly ludicrously increases speed to 24 mph, and then slows back to 10 mph, in a 10 mph speed zone.
 
Hi

I have been following this thread over the past few days waiting for someone to state exactly what they want from the AI. There are a lot of comments about what the AI isn't doing right but exactly what they think it should be doing is rather vague. I think that the AI does quite a good job bearing in mind that the number of variations of routes that can be built with Trainz is more or less infinite and the combinations of consists on each route is the same. Programming it to cover every eventuality that someone, somewhere may think is essential is a near impossible task.

If you look at the ECML route in TS12, running a train from King's Cross to Newcastle involves negotiating multiple running lines, passing loops, yards and multi-platform stations. The possible combinations of routes to get between the two stations must run into the hundreds if not thousands so it is vital that we give the AI as much assistance as possible with path selection.

The way that it works now seems like a good compromise to me as, if you feed it information about your route (through trackmarks, direction markers, priority markers, rules, driver commands, etc), it can be persuaded to do what you want it to do. When I first started with trains I felt the same as many people who have commented here but eventually realised that it could be made to work better with some input from myself. There are a wealth of rules and driver commands on the DLS which can be a great help with the AI if you have the time to explore what they do and learn how to use them correctly.

In my experience I get out of the AI what I put in to it. A bit of time invested in setting up a route correctly to start with, using trackmarks etc can save hours of frustration when creating a session. I am retired and I do appreciate that not everyone has as much time as myself to spend on getting to grips with the AI, but I still think that many of us expect too much from it.

Regards

Brian
 
Hi.

I have been following this thread over the past few days waiting for someone to state exactly what they want from the AI.

That's a good point. My answer would be, that all trains should successfully complete the instructions given to them in the driver commands window. Without any signalling, it would be fair enough if some collisions or standoffs occurred. It is up to us to add the necessary signals to protect the trains.

What is not acceptable, is when trains disregard instructions to "drive via trackmark" at a properly placed trackmark, and when trains just take the alternative direction at a junction, in the hope that there might be an alternative path, when doing this causes the train to behave "stupidly", like backing on to a main line, and when no possible alternative path exists.

And one pet peeve of mine that I have mentioned before, when I get the warning at a signal "line ahead is occupied," when there is only one train in the session!

I agree that it can become massively complicated. AFAIK no-one has made a successful session for ECML, dealing with realistic traffic in and out of Kings Cross. At least, no-one has offered one on the DLS (or am I wrong??) I think this is partly due to the close spacing at KX, the AI just can't handle those short distances between junctions.

Mick Berg.
 
Last edited:
Hi Mick

The junction spacing at King's Cross isn't a problem if you use a path rule to set the path for the train. I have found the biggest problem is the junctions having the default names as they just look like a confused mass of writing, particularly if you have the trackmark names showing as well. I have renamed all the junctions to K 001 etc which simplifies the problems and have also removed most of the trackmarks in the station throat as they aren't needed when using the path rule.

I have been slowly building up a session based on the 1974 working timetable but the biggest difficulty is getting the inbound locos across to the loco yard after their train has been removed to the carriage sidings and then getting them back again onto the empty stock trains ready for departure. There is a considerable amount of shunting involved with even a relatively short session of a couple of hours and it makes you realise why the HSTs were so welcome. Unfortunately this session will never get onto the DLS as some of the changes that I have had to make are on the route layer and therefore save as a new route. This is because the path rule requires signals along the path to have a unique name and there are a number of signals on the route that are either un-named or have duplicate names. As the route was then compromised I decided to rename the junctions as well to make it easier to use.

Regards

Brian
 
I have a question. I have a point where one main line crosses another and does so with crossovers. The result is that south and northbound trains use a short section of common track. Every once an awhile I get a Mexican standoff. Would changing one train's priority make the AI choose which one goes first? And based on a statement above, should I put 2 invisible signals in the shared section (one facing each way)?
trackdiagram-standoff_zpsd186eb74.jpg
 
^^^Correct signal placement should really prevent this. Depending on how long the shared section of track is, I would put any signals in the shared block.

-Joe
 
Hi Frogpipe

Despite its name, priority doesn't favour one train over another. What it does do is match a train priority to a track priority. eg if you have a double track main line running east to west, you can set the track to priority 1 for eastbound and leave the westbound track at default priority value of 2. Similarly give the eastbound train a priority of 1 and leave the westbound at default value of 2. The trains will then select the appropriate track automatically when leaving a single line section. As for the signalling, I would think that it would require signals on the approach to the single line section at each end but none in the short single line section itself. Whichever train gets the junctions first should set the signal on the other route to red. I would use the path rule and driver commands to ensure that both junctions switch at the same time and ensure that the path is set against the other train.

Regards

Brian
 
I have a question. I have a point where one main line crosses another and does so with crossovers. The result is that south and northbound trains use a short section of common track. Every once an awhile I get a Mexican standoff. Would changing one train's priority make the AI choose which one goes first? And based on a statement above, should I put 2 invisible signals in the shared section (one facing each way)?snip

Hi Frogpipe,

The simple way to avoid this is use a 'junction link' Link the two crossover junctions so that when one junction is changed to the crossover the other one will change also. That way which ever train controls the crossover junction first will cause the signals for the other train to change to red.
Below is a quick hash up of what you need.

J-link_zpsa4b6a2f5.jpg


I hope it is clear enough to see. The junction link kuid number is at the bottom right of the screen. Junctions are set to symetric.

If the train in the distance had reached the junction trigger point first the steam train in the foreground would have a red signal.

Also note the diverge signal, one each way, on the short section of common track.



Cheers,
Bill69
 
Last edited:
Despite all the above posts AI trains do behave in a manner that could only be described as unrealistic. A few years back an AI train in a passing loop (on Wadalbavale route TRS2006 biult in route) was under "drive to" orders, instead of driving straight ahead to the far end of the loop and exiting with green sig and correctly set point, train backed out of loop and proceeds up the other side of loop. There were no direction markers. A route I made about 5 years ago AI trains would run into every industry loop along the way instead of sticking to the main line, even going so far as to run 2 loops off the main line. Help Desk couldn't explain that one.What I would want from AI is for trains to run in a realistic manner given correct signalling and correctly set points.
 
frogpipe --

You might like to look at the placement of Track Markers and signals in my IntenCity and Krashnburne routes, and the way the AI is set up in the sessions to proceed from one marker to the next.

IntenCity has short sections of single track, very similar to what you show above; Krashnburne considerably longer single track sections.

The additional complication in both routes is the player train that is under human, not AI, control.

Phil
 
My favorite AI move is the backward/reverse move to an industry track in which you told AI to drive (industry name) & load or unload, he won't take the obvious 200meter run, nope, reverse heading, go down the ranch a couple of miles before deciding to reverse direction and maybe go where instructed the first place.

John
 
My favorite AI move is the backward/reverse move to an industry track in which you told AI to drive (industry name) & load or unload, he won't take the obvious 200meter run, nope, reverse heading, go down the ranch a couple of miles before deciding to reverse direction and maybe go where instructed the first place.

John

That's one of my peeves to with the AI drivers! I have found that if you stop the driver then tell him to continue the schedule, he'll go about it the right way. It's like "Oh, thank you. Sorry about that, and never mind then" and he's back to normal. We shouldn't have to do stuff like that when delivering goods or shuffling cars in a yard. I tried to setup a yard switching job with the AI and gave up. It was faster if I intervened and did it myself.

John
 
I find that generally speaking, AI will behave great if things are set up properly, but every now and then, AI will just go crazy. I've got a session that I've been testing and 75 or 80% of the time, it performs exactly like I want it to, but the rest of the time, it will just start acting stupid. My two biggest problems is when a train will just sit and wait at a junction when there's no train in front of it for 5 miles or when a train just decides to start backing up for absolutely no apparent reason when most of the time, it executes its orders just fine. It's enough to make me pull out my hair at times, if I had any to pull out.

Mike
 
I think Bill69 has given me the best answer, since there would be no case where the switches would not be switched together. At least not in the session I'm making.
 
You have to watch the junction link thingy unless your traffic density is light - and if it's light you probably don't get Mexican Standoffs! In a situation where a train has cleared one junction but is still occupying the second junction a second AI train can throw the first (cleared) lever. Junction Link will then also throw the lever under the first train leaving you with a derailment rather than a standoff.....

Andy
 
I had an ai train in TRS 2004 stop at a track buffer, then back up, then crank up the throttle, ramming right through the buffer and derailing.

Also, a train backed down the main line once, and kept going until it derailed by entering a portal tunnel that only produces trains. All of this occured after loading a saved session...
 
You have to watch the junction link thingy unless your traffic density is light - and if it's light you probably don't get Mexican Standoffs! In a situation where a train has cleared one junction but is still occupying the second junction a second AI train can throw the first (cleared) lever. Junction Link will then also throw the lever under the first train leaving you with a derailment rather than a standoff.....

Andy

Hi frogpipe and dermmy,

If you do get that problem use a control junction command in each drivers command list. i.e drive via trackmark(aa), control junction xx, drive via trackmark (bb), free junction xx. Which ever train gets to the control junction trackmark will lock the two junctions until it gets to the free junction trackmark. If one train is in control of the junctions when the other train arrives at it's control junction trackmark the second train will drop out of AI control and regain control when it can control the junction.
I have used this system many times and it never fails.

Cheers,
Bill69
 
I'm not knocking Bill or his solution, it's just that to my mind it's another example of needless complexity in a session with command stacked on command to solve a problem that can be fixed with NO commands, no extra scripted bits nor anything else....

Back at the original drawing, if you just treat the whole thing as an interlocking with one signal protecting each of the four trailing approaches and no signals in the 'middle bit' a standoff is impossible unless you get 4 trains arriving simultaneously. Not 'Proto'? There are to all intents and purposes no sigs anywhere in the centre of a track arrangemnt like that because a red sig on either facing junction fouls TWO approach roads. You place sigs to keep tracks clear, not to foul multiple tracks. Oh - and if the Proto got four facing trains there (a) somebody gets fired and (b) they have a stand-off also!

I say again that IMHO the single biggest cause of foul ups in sessions is spaghetti-code instructions stacked one on the other attempting to fix a fundamental issue that never gets addressed directly. Too many trackmarks, too many signals, too many commands.....
 
Last edited:
Hi dermmy,

I will complete a couple of loops to test you theory, let you know what happens.

Cheers,
Bill
 
Back
Top