When items are consumed as soon as they arrive and no request threshold is used (which is what every construction reader will have) the platform will be overwhelmed with cargo pods, often carrying just one item instead of combining them into a single pod. This results in the pod sticking around on the sending platform a fixed amount above the sending hatch until a hatch frees up on the destination. This totally destroys the throughput and takes several (10+) minutes without requests to resolve.

Overall a state that is very easy to get into and looks like IPL simply isn't working.

The platform hub has an array of cargo hatches and each hatch has a 'busy' field:

https://lua-api.factorio.com/latest/classes/LuaEntity.html#cargo_hatches
https://lua-api.factorio.com/latest/classes/LuaCargoHatch.html#busy

I'm assuming when IPL sends a cargo pod the destination hatch becomes 'busy'. IPL should only send a new pod when one of the hatches isn't busy.

Alternatively, looking at the source, IPL seems to track pods in flight using the on_cargo_pod_delivered_cargo event. So it knows how many pods are in use by IPL and it should not send more pods than the platform has input compatible hatches.

Hello.

Thank you for your feedback. I didn't realise the construction reader would easily put players in such situation.

Ipl doesn't track the pods in flight, this is too performance heavy. It was like this before, and was changed for a more performant system that achieves the same result. But the actual pod entity isn't tracked.

About hatches : You are assuming wrong.
A hatch doesn't become busy, nor reserved, right when a pod targetting the platform is sent.

So checking if the hatches are busy would not prevent queuing pods, it would just prevent sending more pods in an already existing queue.
That would also deteriorate performance significantly (how significantly remains to be tested), as it would mean checking the state of the receiving hatches, with a time complexity of O(N), that would potentially run very often while the hatch keep being busy.
However that wouldn't prevent sending several volley of pods that could end up being queued.

What you want is a cooldown, that would be tied to the receiving platform. It would be clunky. There is no way to know for sure how much time a pod will take to arrive, because the pods might be queues by other platforms sending pods, or even planets. Using a fixed cooldown is not an option either. The goal of IPL is to offer a very flexible solution to players, where you can leverage your circuit skills to get the maximum throughput. I will not implement something that limits the players who are achieving high throughput by using circuits and thresholds properly.

You can build your own clock with circuits, or other circuit latches that will prevent being spammed by the fact the construction reader updates often.
I consider it is the player's responsability to avoid being stuck in this situation.

Every solution I can think of would only be a bandaid and would have side effects.
I could maybe consider try to implement a cooldown in a fair and parametrable way, but for now that's about it.

Using a clock doesn't work since I believe IPL only scans 2 platforms and 2 requests per tick. So if the request isn't activate the tick the platform is scanned you never get anything.

Limiting the pods to the hatches should be both simple and cheap. For each platform record the number of cargo hatches it has. That only needs to be updated when a cargo bay is build. Then keep a count of pods in flight for each platform. Every time you add a pod to the pod_buffer table increment that platforms pod count. Every time you remove a pod from pod_buffer (like in defines.events.on_cargo_pod_delivered_cargo) decrement it. Then it's a simple test of hatches[platform.hub.unit_number] > pod_count[platform.hub.unit_number]. That's 2 comparisons per tick.

The problem with thresholds and building is that when you only need for example one more centrifuge you never get it. On the other hand you don't want to request 10 centrifuges and then have 9 left over in the hub of a transport ship with limited storage space. I can figure out some clock mechanism that lowers the threshold if less than the threshold is requested for a longish time, like the last 5 transport belts and otherwise keeps it high. But I bet most people have a hard time with it. Would be nice it IPL would be less prone to suffer from simple, non-perfect use.

On another note: Do you pick a random item to send or rounbd-robin or do you always pick the first signal requested?

The later would also explain why it goes into overload so easily. Every space platform build will trigger another pod with 1 space platform to be send over and over despite the platform also needing 1000 iron plates. It leaves the game no time for the request count to increase and send a larger batch of space platform. If you already have some balancing there then I'm sorry, haven't read all the code yet.

I do not like to have to keep track of how many bays exist at a time. Moreover, every bay can have any number of hatches. And as said previously even if i can track ipl pods, i cannot track other pods sent by the game. My philosophy is to not half ass stuff. That's why ipl uses antennas instead of just using the hub's logistic sections. Because it can provider a more understandable experience rather than half assing some Frankenstein stuff. Sure your solution would work in most cases, but in some cases, the player could find himself in a new exotic situation like the one that brothers you. For instance, if a player is sure that his provider should be sending stuff but isn't.

I know that often, solutions seem simple, and you must think i'm a dumbdumb for not thinking this through before. But the simple fact is that finding a solution that satisfies all critarias isn't simple : maximal performance, understandable by the user (natural / vanilla feel)… maintainable, robust.

I'm afraid this solution would hinder throughput and change the way the mod behaves too much. Atm, a provider can dump several pods, put them in queue, and just go away. With such change, the provider would have to stay around until it can launch all its pods. This is a change in GamePlay that cannot be taken lightly.

As for your other question, every tick, IPL selects two platforms and two requests on each of these platforms. For each request, it calculates the deficit at the requester, accounting for pods in travel. So it should cycle signals. It's entirely deterministic.

I made the platform construction reader mod without really thinking much more ahead than "here is a way to get what the platform needs for construction". Ipl shouldnt be bent to the specifics of this addon.

Also ipl doesn't "scan". It reads the signals received by the antennas.

And anyways, i value every feedback, but you seem to want the mod to accomodate you and your own needs. There are solutions around the problem you are describing inside the game.

Controling what platforms send is under your control. The mod isn't meant to hold your hand in every case you want to explore. It already does a lot for user's confort under the hood.

So please, before Reading the code through and through... Try to find a solution ingame.

I will add to this that if there is no ingame solution or if it's too convoluted, then it means there is indeed a problem that needs adressing.

If you want to discuss it further, i invite you to join the discord link in the mod description. It would be easier to talk about how to mitigate or adress this issue.

Being stuck for several minutes because of the queue is not desirable if the player doesn't know this is a thing that can happen. So at the very least, the mod should communciate better about it.

I'm not closed to changing things, but as i said, it has to be the right solution that doesn't hinder other things and/or produces side effects.

Hello again.
I have made a prototype for a hard limit in order to avoid ending up in the situation where you are locked several minutes waiting for pods to arrive.
If you want to test it, I can send you the file over discord.

I still don't think using a hard limit based on hatch numbers is the best solution, but the current limit I put is 3x the number of hatches on the receiver (so there can be a queue, but it won't last minutes).

Also, as it turns out, I was wrong. I can access the number of hatches directly, so the time complexity is lower than what I thought. Should be about O(1) instead of O(N), which at least validates the first checkmark on your solution (performance).

It needs to be tested thouroughly tho, to find the cases where the tracker would... lose track for any reason and eventually crash.

Great, thanks. So you basically implemented my idea except with a 3x factor. I will have to check this out after easter and can then play arount with the over supply factor.

I doubt the 3x is needed. Unless the time between processing a platform is approaching the time a pod takes to fly from A to B a queue should be irrelevant. The throughput limit is how many pods can land at a time and you scale that up with cargo bays. Built more. :) And it does look really strange when you have a bunch of pods building a flock a bit north of the hub when they queue up.

And as said previously even if i can track ipl pods, i cannot track other pods sent by the game.

I'm playing Spaceblock so IPL is the only thing sending pods. But If I had planets sending rockets then I bet the IPL pod overloading the cargo bays would totally block the normal rockets because they can't find a hatch to land in. Not sure the rocket would even start with all hatches busy or if the rocket would join the queue. Something to test.

Yes. Told you, i value every feedback. Even tho i disagree, you made enough of an argument for me to dig a bit into it.

Well there is a fine line between "skill issue" and unfair punishment.

I personally think that what's happened to you is a skill issue. You should have planned your platform better to build more hatches sooner. And i don't think the mod should hold your hand too much.

That's why i don't like your idea. That and the fact i'm conscious the queue is a thing and decided to do nothing against it so far. Moreover, for now, i had a crash but couldn't identify what happened. I'll check what's that about after easter.

I also want to stick to vanilla behavior as much as possible. So indeed we should check if rockets wait if there is a queue or not.

And i also believe that being stuck for several minutes because of a mistake can be lame, if you don't have any means to unstuck yourself. A couple minutes is fine, but the player should have at least have an idea about how much time the lock will last , or how many pods are waiting, or, even, that it's stuck because he didn't build enough hatches.
Your idea also adds the needs for a new storage variable (which adds complexity and has to be maintained). It doesn't look like much but that's stuff coming on top of other stuff.

But i'm all for testing things and see how it plays and feels. It can become an option (limit pods) or something that is not available in HARD MODE, or a feature (research a tech to have the mod take care of it for you). It could also be just a spaceblock feature. The balance of it and the maintainability are now what interest me, now that the performance subject seem alright.