Is there a limit on the number of AI-trains running?

[hkoster1]

My route has Un-Portals at either end emitting trains at regular intervals. Everything seems to work fine at first, except that between these Un-Portals the maximum number of emitted trains is 7. The Un-Portals themselves have the maximum number of trains set at the default 25, and excess trains (if that number ever gets that high) are not removed.

Is there a setting that I'm overlooking that will bump the number of trains running? I would be happy if it could become 12, because then trains would start to be consumed by the opposing Un-Portal.

FWIW: I'm running TS:MAC, plenty of CPU/GPU power and 16GB RAM...

 

[cascaderailroad]

I use iPortal (as I want to send trainz, from one of my routes, to the other one of my routes, as well as sending trainz internationally via the internet), I have used Portal, but I will have to test Un-Portal ... I never heard of it before.

 

[dnevans8]

Without knowing the route or the frequency of emitting the consists I could be wrong here, but is it just a case of there not being enough time between a consist travelling from one portal to the other to allow more than seven consist to be produced. Try reducing the time for consists to be emitted.

 

[norfolksouthern37]

there isn't a maximum train count as far as i know. i think it would be dependent on your hardware. i have run as many as 25 trains at once on a large route, but the computer gets a bit sluggish at that time.

 

[Kennilworth]

Hi

I have been trying to use Un-Portals to add trains on the ECML route using the CPC: Emit train on trigger rule but found it unreliable after a number of trains were produced. They were required to be emitted at the correct time and the first five or six did so correctly, however the portal then started to either not emit the train at all or emit it late which is not good when trying to run to a timetable. I spent over a week trying to get it to work correctly but eventually gave it up as unsolvable (for me anyway). This was in TS12 so I was left wondering if this rule has issues in the later versions of trainz.

Regards

Brian

 

[hkoster1]

Hi

I have been trying to use Un-Portals to add trains on the ECML route using the CPC: Emit train on trigger rule but found it unreliable after a number of trains were produced. They were required to be emitted at the correct time and the first five or six did so correctly, however the portal then started to either not emit the train at all or emit it late which is not good when trying to run to a timetable. I spent over a week trying to get it to work correctly but eventually gave it up as unsolvable (for me anyway). This was in TS12 so I was left wondering if this rule has issues in the later versions of trainz.

Regards

Brian

That pretty much sounds like my problem as well... the Un-Portals just stop emitting trains after a combined total of 7. It shouldn't be the hardware, since my iMac has plenty of free RAM even with Trainz running. Anyway, are there settings in TS that indicate how much RAM or how many processor cores should be used?

BTW, I'm using this on the approx. 125 mile CPR Mountain RR, emitting trains at hourly intervals on both ends, so no chance of previously emitted trains interfering with the Un-Portal that emitted them.

 

[fran1]

Unless you have to use a specific portal type, try portal basic. Works every time on time. I've set mine up in conjunction with the schedule library.

 

[hkoster1]

Unless you have to use a specific portal type, try portal basic. Works every time on time. I've set mine up in conjunction with the schedule library.

Yes, good idea, I might as well consider that, since Un-Portals and iPortals (with or without CPC) don't seem to work in my setup.

 

[fran1]

Yes, good idea, I might as well consider that, since Un-Portals and iPortals (with or without CPC) don't seem to work in my setup.

On my route they emit 70-100 wagon consists every 40 mins without issues.

 

[llebrez]

Facts: You can run as many AI trains you like if your hardware allows it. But, at some point the more trains are running (even if the don't crisscross or meet), AI starts to do foolish things. Consider my test: Run two trains doing some repetitive complex work. Save the session and come back later. They do it again without problem all the time. Now add several, perhaps 10 trains doing again complex work.. and they at some point go nowhere, or back up unexpectedly, etc. No clue why...

 

[hkoster1]

[SOLVED] UnPortal maximum number of trains

The UnPortal code was written almost 10 years ago, and was meant to unify multiple UnPortals into a single rule. That last feature no longer works in TS12 or TSMAC, requiring a separate UnPortal rule for each emitting UnPortal. The maximum number of AI trains emitted by these UnPortals remains shared between the various UnPortal rules, whether unified in a single rule or spread over multiple rules. What's more, there is only a single MaxTrains variable in the UnPortal code which is set equal to the stated maximum number of trains divided by the number of UnPortal rules. I'm sure the original coder didn't intend it to work this way, but that's how it works out.

In my original post I had 4 UnPortal rules: 2 emitting and 2 consuming, and the maximum number of trains in each set at the default 25. The UnPortal code treats this as 25/4 = 6 trains maximum, and before emitting a train checks whether or not this number is exceeded. After 6 trains were emitted, it did emit a 7th train but stopped at emitting an 8th train -- it only did so a few hours later when one of the running trains had been consumed.

So, all UnPortal rules are treated as one by the underlying code, with the maximum number of trains allowed equal to the stated number (in each UnPortal) divided by the number of UnPortal rules. The maximum stated number of trains is 99, so with 4 separate UnPortal rules the actual maximum number of trains is 99/4 = 24.

 

[Kennilworth]

Hi

Many thanks for reporting this as I now understand what was happening with my session. I'll now try again with the maximum set to 99 and see what happens. Instead of using un-portals to delete the trains I now use the driver command Delete Train in a trains schedule to remove them from the route which should also help increase the number of trains available.

Regards

Brian

 

[hkoster1]

Hi

Many thanks for reporting this as I now understand what was happening with my session. I'll now try again with the maximum set to 99 and see what happens. Instead of using un-portals to delete the trains I now use the driver command Delete Train in a trains schedule to remove them from the route which should also help increase the number of trains available.

Regards

Brian

Good idea to use Delete Train to save on consuming UnPortals... I'm going to implement that as well.

Have fun!

 

[ldowns]

Facts: You can run as many AI trains you like if your hardware allows it. But, at some point the more trains are running (even if the don't crisscross or meet), AI starts to do foolish things. Consider my test: Run two trains doing some repetitive complex work. Save the session and come back later. They do it again without problem all the time. Now add several, perhaps 10 trains doing again complex work.. and they at some point go nowhere, or back up unexpectedly, etc. No clue why...

My experience too--except that I can normally run up to about 52 trains at once, after which the screen starts getting a bit jumpy, and, yes, the AI starts to do some unpredictable things such as ignoring direction markers. I've found that using the old Drive To instead of Navigate To seems to be more reliable, as trains don't start looking for alternative routes in unlikely places.

--Lamont