Page 1 of 1
[2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Sun Mar 23, 2025 5:46 pm
by valneq
When dropping multiple different types of items from a platform that fill the drop pod queue, eventually the drop pod slots show a countdown for when the next pod is available. I like this new feature.
However, when adding additional items, those don't get the same visualization yet are dropped with the same pod. This feels inconsistent. Maybe an oversight. Here is a screenshot of what I see:

- grafik.png (278.05 KiB) Viewed 396 times
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Mon Mar 24, 2025 11:25 am
by Genhis
Thanks for the report, this is not a bug. The cooldown is specific to the item type and the visualisation means "this item won't be dropped for some time unless bundled with an item which doesn't have cooldown".
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Mon Mar 24, 2025 12:04 pm
by BraveCaperCat
Genhis wrote: Mon Mar 24, 2025 11:25 am
Thanks for the report, this is not a bug. The cooldown is specific to the item type and the visualisation means "this item won't be dropped for some time unless bundled with an item which doesn't have cooldown".
That doesn't appear to be made clear anywhere though...
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Tue Mar 25, 2025 3:01 pm
by avenger
I second this behaves very strangely (well, or counter-intuitively). I need to double check it, but I feel even when only items with the "cooldown" are on the list, the cooldown far from finished, then everything gets dropped, as if the cooldown animation was out of sync. Really felt "broken" somehow.
Only now that you stated "this item won't be dropped unless bundled with an item without cooldown", but perhaps I must pay closer attention around the GUI to see if that's explained somewhere. Is it? If not, I guess the feature could really get a revisit to clarify its mechanics.
To me it would make sense if the game just had a delay, like "moving items to pod/rocket", to simulate a mechanism that moved items in the rocket inventory to the inventory itself, thus applying a "natural cooldown" that would be easier to understand. This would also make sense with, when you take the rocket/pod yourself, you don't take along all the items currently in rocket inventory (silo) or drop slots (space plat). Quality could affect that cooldown (so it would make sense to make quality starter packs).
EDIT: double-checked, dropping a pack full of the same thing over and over (uncommon Tungsten Plate in this case, full batches of 10 stacks), every item getting the cooldown overlay (so I didn't release anything else that would "break" the cooldown"), and the cooldown is simply non-functional. Maybe signal with something else if the wait time is unknown and unpredictable?
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Wed Mar 26, 2025 1:34 pm
by xargo-sama
The cooldown feature has been added as a fix for people's planets being spammed by pods with tiny amounts of ore in them when they turned on auto-trashing for something that was being produced on the platform and inserted into the hub (space science, iron ore, ice, etc.)
The rules for the trash slots are as follows:
- If the trash slots are full, the pod will be sent immediately.
- If there is an item that doesn't have a cooldown, we send the pod immediately. (with everything in the trash)
- If everything in trash is on cooldown, wait for it to run down first.
The trash pod can be delayed a little bit if all the hatches are already busy sending pods.
I am not 100% happy with how it jams manual drops of items, but the endless stream of almost empty pods was an extremely important issue to fix over that.
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Wed Mar 26, 2025 5:06 pm
by xargo-sama
After some consideration I've tested some special settings for manual dropping of items and I think it feels way better. Might ship with the build after the next one.
Re: [2.0.42] Orbital drop pod countdown visualization inconsistent
Posted: Fri Mar 28, 2025 6:24 am
by avenger
xargo-sama wrote: Wed Mar 26, 2025 5:06 pm
After some consideration I've tested some special settings for manual dropping of items and I think it feels way better. Might ship with the build after the next one.
Thanks! Yes, I've been testing whis for manual drops. Maybe I failed to communicate this. I believe people would hardly be checking at the platform while this goes auto-dropping.
Maybe move this to resolved issues then? I'm looking forward to testing this and providing feedback next steam release.
xargo-sama wrote: Wed Mar 26, 2025 1:34 pm
The cooldown feature has been added as a fix for people's planets being spammed by pods with tiny amounts of ore in them when they turned on auto-trashing for something that was being produced on the platform and inserted into the hub (space science, iron ore, ice, etc.)
I don't, and won't argue with how useful it is. It makes complete sense to me. The issue is just that the cooldown suggests it's going to be delayed until the cooldown is over, but it always sends earlier, in different scenarios. I actually couldn't reproduce (with manual dropping) even once a situation where the cooldown is fully processed.
xargo-sama wrote: Wed Mar 26, 2025 1:34 pm
The trash pod can be delayed a little bit if all the hatches are already busy sending pods.
Yes, that's what I felt the delay actually works for. In the ground I have only one landing pad so max 3 modules should be landing at a time.
xargo-sama wrote: Wed Mar 26, 2025 1:34 pm
I am not 100% happy with how it jams manual drops of items, but the endless stream of almost empty pods was an extremely important issue to fix over that.
I really noticed how it's difficult to fill up a first pod when I arrive to a planet (ctrl+click when less than 10 stacks of same item). I tend to quickly click items to try to fill a pod, lol. The "cooldown countdown" is just a visual glitch.
It really sounds reasonable a 2 second delay before sending dropped items would be alright (would it affect balance at all?).
If this still becomes errant, couldn't just a "gray out effect" (just the cooldown always filled) to tell the items there are "busy being sent"? Without knowing implementation details, this sounds simpler and avoids confusion. It could show a message "waiting for free drop landing pads space" similar to assemblies say "output full" or "ingredients missing", to be consistent with the rest of the game.