Are fluid requester stations hard-capped at 1 train request at a time, regardless of capacity?

[Slade]

I'm 500+ hours into K2SE here and in the process of mothballing my Calidus orbit base and moving the entire operation to Nauvis Orbit. I've been using LTN the entire time.

While setting up my space fluids, I noticed an odd behavior that I can't explain.

My LTN supply station is primed with 200,000 fluid and a train limit of 4. These are 1-1 Fluid trains, so I assume LTN is smart and knows that each train can hold 25,000 fluid.




My requester station was empty, had a train limit of 3, and wanted what amounts to 8 full train loads of fluids. However, only one train was ever requested at a time.



Note the above screenshot was taken after it filled, 1 train at a time. I realize it's full now, but most definitely wasn't when the behavior above was observed.

This prompted me to do some experimentation.

Here's a video I took of the issue, recreated without any distance between the stations so you can see all the pertinent info: https://streamable.com/p255os

I took it one step further and used the empty supply station above to create another Cosmic Water supply, and added a second requester station. This meant I had two separate supply stations with 16 trains worth of fluid, and two separate requester stations wanting 16 trains worth of fluid. When everything was enabled, only two trains were dispatched. One from each supply, heading to separate requesters.

When I disabled a requester station and left both supply enabled, still only one train was requested.

When I disabled a supply station and left both requesters on, again only two trains were triggered and both filled from the single supply station.

I thought maybe there was an issue with the item coding where it thought the Huge 200k modded storage tank could only fit one train worth, and was a failsafe to avoid orphaned fluids. So I plopped down 2 more storage tanks and wired them up to the requester station, changed the request total to 600k, and STILL only one train was dispatched, despite the glut of supply.

Am I doing something wrong? Is this intended behavior and I am somehow only noticing it now, 500 hours into the save?

[Slade]

Sorry for the self-reply.

I just set up a test using Blank Data Cards as well, and had the exact same results.

I feel like I'm taking crazy pills and am missing something obvious, since traffic jams on brand new city blocks have been a problem on Nauvis as too many trains scramble to fill buffers.

See video here:

https://streamable.com/st24ex



Edit: I have determined that LTN will only generate a single train per Request station each time the Dispatcher updates, regardless of combinator settings or station capacity. I went into the Settings window and changed "Update frequency (ticks)" from 2 to 1, which reduced the delay between batching of trains, and was able to get some delivery overlap on a test station. It would still only request one train at a time, but the requests came more rapidly.

Edit2: Further confirmed by changing "Updates per tick" setting to 10 with a frequency setting of 1. It still only requests one train at a time, but it appears to trigger dispatch once a second or so. Instead of a large batch of notifications, they trickle in constantly, and all three trains in the case of my test station, were ordered in rapid succession. Just not all at once.

Mystery solved.

[Optera]

Update frequency (ticks)
How fast stops and requests are updated. Higher numbers improve performance by spreading out updates over more ticks. When set > 1 forces Updates per tick to 1.

Updates per tick
Limits the number of stops and requests updated per tick. Lower numbers increase performance. Ignored when Update frequency > 1.

I wouldn't recommend using anything above 2 updates per tick.
Reading signals at stops is an expensive operation.
Also it's hardly necessary to dispatch trains multiple times per second.

Regardless of settings, LTN will only create one delivery per requester every dispatcher update.
This is done to prevent all trains rushing to one (badly configured) requester at once starving all other requesters and gridlocking intersections.

Going by your screenshots you use L-T train configuration.
For more throughput use longer trains before tweaking LTN settings.

[Slade]

Thanks. I did ultimately leave my settings as default. I changed them just to follow through on confirming what the underlying cause of this behavior was.

The true nature of the issue was that my Nauvis base had 1200 LTN stations on it. As was explained to me elsewhere, that's what caused the abnormally long delay in Dispatch calls at default settings. Each of these fish icons was an empty Requester station with a blank combinator, but nonetheless set to "Requester" status:



I have simply deleted those 400+ unused stations in empty blocks awaiting assignment. They'll be put back as needed.

I primarily use 1-4 trains. It was just the space-specific things I intended to move with 1-1 trains because of how little throughput is needed.