[2.0.30] Cargo pods optimization issue when "unfulfillable" requests > 1
Posted: Mon Jan 13, 2025 6:51 pm
This is a follow-up from a twitch stream where Raiguard was made aware of the issue, but I think I've explored it further to find out exactly what the issue is.
Basically when you have a cargo landing pad on a planet and a number of space platforms in orbit, you can separate the requests the cargo landing pad has in 3 categories:
(a) fulfilled requests
(b) unfulfilled requests but the spaceships in orbit can provide the requested items
(c) unfulfilled requests and the spaceships in orbit can NOT provide the requested items
Under normal circumstances, the current code tries to do something along the lines of 1 cargo pod per tick per request. This is the theoretical max throughput without further optimization of the code.
However when you have 2 or more requests under category (c), this reduces the theoretical max throughput for category (b) requests, and very quickly.
More specifically:
When there are 0 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 1 tick, or k cargo pods per tick
When there are 1 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 1 tick, or k cargo pods per tick, same as above
When there are 2 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 2 ticks, or k/2 cargo pods per tick
When there are 3 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 3 ticks, or k/3 cargo pods per tick
...
When there are 10 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 10 ticks, or k/10 cargo pods per tick
Fulfilled requests (a) do not affect throughput.
You can see how this can easily reduce throughput significantly when the cargo landing pad is missing a few items, especially on Nauvis, and this reduction can be a big issue in the end-game.
Moreover it doesn't make sense from a programming perspective that the number of (b) requests which should require more computing time than (c) requests (I'm assuming), scale linearly positively, while the (c) requests scale inversely/negatively 1/x (and also that this only starts after 2+ (c) requests)
I have a youtube video showing the issue and also have attached the savefile used in the video:
https://www.youtube.com/watch?v=0hs8vxxE2_M
No mods, besides space age + quality + elevated rail
Basically when you have a cargo landing pad on a planet and a number of space platforms in orbit, you can separate the requests the cargo landing pad has in 3 categories:
(a) fulfilled requests
(b) unfulfilled requests but the spaceships in orbit can provide the requested items
(c) unfulfilled requests and the spaceships in orbit can NOT provide the requested items
Under normal circumstances, the current code tries to do something along the lines of 1 cargo pod per tick per request. This is the theoretical max throughput without further optimization of the code.
However when you have 2 or more requests under category (c), this reduces the theoretical max throughput for category (b) requests, and very quickly.
More specifically:
When there are 0 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 1 tick, or k cargo pods per tick
When there are 1 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 1 tick, or k cargo pods per tick, same as above
When there are 2 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 2 ticks, or k/2 cargo pods per tick
When there are 3 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 3 ticks, or k/3 cargo pods per tick
...
When there are 10 (c) requests and k (b) requests, you get 1 cargo pod per (b) request per 10 ticks, or k/10 cargo pods per tick
Fulfilled requests (a) do not affect throughput.
You can see how this can easily reduce throughput significantly when the cargo landing pad is missing a few items, especially on Nauvis, and this reduction can be a big issue in the end-game.
Moreover it doesn't make sense from a programming perspective that the number of (b) requests which should require more computing time than (c) requests (I'm assuming), scale linearly positively, while the (c) requests scale inversely/negatively 1/x (and also that this only starts after 2+ (c) requests)
I have a youtube video showing the issue and also have attached the savefile used in the video:
https://www.youtube.com/watch?v=0hs8vxxE2_M
No mods, besides space age + quality + elevated rail