I was playing with the idea of giving the player back steel/a fuel tank item when they consume a full canister of flamethrower ammo and I think that adding an extra optional property for a spent_result to the AmmoItemPrototype would be a cleaner and simpler solution than anything I can come up with scripting-wise.
Apologies if this isn't the right format for an API request, it's my first one.
API request: add a spent_result to AmmoItemPrototype
-
- Manual Inserter
- Posts: 3
- Joined: Sun May 11, 2025 11:39 am
- Contact:
-
- Long Handed Inserter
- Posts: 83
- Joined: Sat Aug 05, 2023 1:20 am
- Contact:
Re: API request: add a spent_result to AmmoItemPrototype
+1, although im not sure how it'd be handled - i guess it'd get automatically put in your inventory? although if the player has no space, i guess it'd have to be dropped on the floor?
coder? i hardly know her!
-
- Manual Inserter
- Posts: 3
- Joined: Sun May 11, 2025 11:39 am
- Contact:
Re: API request: add a spent_result to AmmoItemPrototype
Yeah, I was imagining it being put in the player's (or the tank's) inventory and if full, drop it on the floor.
Re: API request: add a spent_result to AmmoItemPrototype
Absolutely no, there are absolutely no chances of this being implemented because it would be just a buggy mess that everyone would quickly start complaining about as being unreliable.
Take a look at this:
1/ Craft 1 magazine (it has 10 bullets).
2/ Shoot 7 times
3/ Put that magazine into a chest.
4/ Craft 1 magazine (it has 10 bullets).
5/ Shoot 7 times
6/ Put that magazine into the same chest from step 3
7/ Observe that those magazines will now merge leaving you with only 1 magazine that has 6 bullets inside of it.
Problem here is that if you would deplet those magazines in step 2 and step 5 you would expect to get 2 items of the spent_result type. However due to items merging, now you are left with only 1 magazine that has 6 bullets in it and so you would be given only 1 item of spent_result type. Either players would start complaining that they produced X magazines and in return they got Y (where Y < X) items back, or the magazines through the process of merges and splits would have to keep track of how many spent items they represent. Imagine having a magazine with 1 bullet that when depleted gives you 500 spent items just because every time you were getting close the magazines merged and so all the spent items are now in that one merged magazine. What if you cannot fit those spent items into the inventory at the same time, does it mean you cannot shoot that last bullet? or would that mean the inventory must be able to grow arbitrarily just to be able to hold all of the items that are given at the same time when last bullet is shot.
We already got into similar problems with loaders and science packs where players were complaining that item production/consumption statistics did not match just because loaders were trying to top up a science packs inside of a lab, effectively causing items from belt to never be seen as consumed since they were transferred, and items in the lab were never seen as consumed since they were always almost full (as a result of partial transfer done by the loader).
Only case where this would be reliable is when a magazine has exactly 1 shot in it so you cannot get into the merging of stacks behavior because it would be aways either full or empty, but that is clearly not the proposed use case as it mentions specifically ammo for flamethrower.
Take a look at this:
1/ Craft 1 magazine (it has 10 bullets).
2/ Shoot 7 times
3/ Put that magazine into a chest.
4/ Craft 1 magazine (it has 10 bullets).
5/ Shoot 7 times
6/ Put that magazine into the same chest from step 3
7/ Observe that those magazines will now merge leaving you with only 1 magazine that has 6 bullets inside of it.
Problem here is that if you would deplet those magazines in step 2 and step 5 you would expect to get 2 items of the spent_result type. However due to items merging, now you are left with only 1 magazine that has 6 bullets in it and so you would be given only 1 item of spent_result type. Either players would start complaining that they produced X magazines and in return they got Y (where Y < X) items back, or the magazines through the process of merges and splits would have to keep track of how many spent items they represent. Imagine having a magazine with 1 bullet that when depleted gives you 500 spent items just because every time you were getting close the magazines merged and so all the spent items are now in that one merged magazine. What if you cannot fit those spent items into the inventory at the same time, does it mean you cannot shoot that last bullet? or would that mean the inventory must be able to grow arbitrarily just to be able to hold all of the items that are given at the same time when last bullet is shot.
We already got into similar problems with loaders and science packs where players were complaining that item production/consumption statistics did not match just because loaders were trying to top up a science packs inside of a lab, effectively causing items from belt to never be seen as consumed since they were transferred, and items in the lab were never seen as consumed since they were always almost full (as a result of partial transfer done by the loader).
Only case where this would be reliable is when a magazine has exactly 1 shot in it so you cannot get into the merging of stacks behavior because it would be aways either full or empty, but that is clearly not the proposed use case as it mentions specifically ammo for flamethrower.
-
- Long Handed Inserter
- Posts: 83
- Joined: Sat Aug 05, 2023 1:20 am
- Contact:
Re: API request: add a spent_result to AmmoItemPrototype
thats fair, i thought it'd take some 'overhead' but didnt expect that much 

coder? i hardly know her!
-
- Manual Inserter
- Posts: 3
- Joined: Sun May 11, 2025 11:39 am
- Contact:
Re: API request: add a spent_result to AmmoItemPrototype
Alright, that's a pretty clear answer. Unfortunate but entirely understandable. Thanks for explaining.