I'm playing experimental 2.1.14, it seems like RLD combinator doesn`t output L value properly. I wired it to the station and set train lim to 1 in the combinator, some time later I noticed another train stuck around the stop because it was already busy. Inside the stop gui L value(number) doesn't show up(as if there wasn't a L signal in the net at all), unlike with a regular combinator. Is it some kind of bug or is it supposed to be like this?
with rld combinator - https://postimg.cc/8Jqfhmbv
regular combinator - https://postimg.cc/w1fvXkqd

L is only used internally RLD managed train limit on how many trains can be in flight a requester at once, or to a provider. I don't believe this is ever sent as an output signal anywhere on a wire. The RLD scheduler uses this value when calculating deliveries only. when a train delivery is calculated if the provider or requester cannot match because train limit is already at max, the scheduler simply drops the request and picks up up on the next time slice for request checking and notes it in the deliveries (with a yellow warning under the station in RLD manager with the limit being hit). I will double check the logic.

I can can confirm this, and have play tested the scenario laid out, I could not catch this in our mega base testing because there is so much throughput and we are deep into play (why this mod was created) I missed a very simple scenario. I will need to update the code for this. Here is the summary:

Variant 1: one provider, two requesters
Setup:

Provider "Acid Pickup" offers 50k sulfuric acid. Owner sets Limit Trains = 1 on its RLD combinator — the station has one bay, they want one train at a time. Spec and tooltip both tell them this is supported ("concurrent trains allowed at this stop").
Requesters A and B elsewhere on the network, each short 20k acid, thresholds met.
Two idle trains at depots.
Plan tick walks the request list:

Request A → find_provider picks Acid Pickup (only source). The checks that run: A's own committed cargo, A's own max_trains budget (dispatch.lua:614-629) — all requester-side. Provider side, only committed_out runs, which subtracts cargo: 50k − 20k = 30k still offerable. Nobody reads the provider's max_trains. Delivery 1 commits, Train 1 dispatched to Acid Pickup.
Request B, same cycle → Acid Pickup still offers 30k ≥ threshold → match. The only provider-side gate is again cargo, and cargo passes. Delivery 2 commits, Train 2 dispatched to the same stop.
On the rails: RLD never writes the native trains_limit, so the game's pathing sees no limit and paths both trains in. Train 1 docks and loads; Train 2 arrives and parks in the queue/main line — "stuck at the stop because it was already occupied."

The user configured Limit Trains = 1 on this exact stop to prevent this exact outcome, and every piece of documentation told them it would. The setting was silently ignored because enforcement only exists for requesters. That's the bug.

Variant 2: one big requester, split deliveries — no second requester needed
A single requester is short 120k. The split loop (dispatch.lua:673) breaks it into three 40k train-loads. The loop decrements the requester's budget — but if the requester's max_trains is unset (0 = unlimited), all three chunks commit in one plan tick, each independently picking the best provider… which is the same provider every time. Three trains converge on a provider whose owner set Limit Trains = 1. Same pile-up, no second requester required.

When it is not a bug
If the reporter's stop is a requester, the limit works — budget counted against live inbound deliveries, held until departure, airtight through the split loop. Then their report reduces to the L-icon/native-display confusion only.

Fixed in 1.0.10 / 2.0.10 (live on the portal now). After updating, the limit on your provider works as you'd expect: the dispatcher won't send more trains to a pickup stop than its Limit Trains value, counting trains already on their way. Once a train finishes its pickup, the slot frees up and the next delivery can be assigned. No rewiring needed — the signal you already set will just start being respected.

If every provider of a cargo is at its limit, the waiting request now raises a "provider is at its train limit" alert instead of the old (misleading) "No provider" message, so you can tell the difference between "out of stock" and "just busy."

Thanks for the report!

Thanks for replying so fast! To be honest, I'm amazed by how dedicated you are. I love your mod, it has exceptional potential, soon everyone will use it for sure!

The factory must grow