Get BurntResult on Vehicle and BurnerGenerator while mined interrupting a consumption process

[Linver]

Hi, I noticed from many mod user reports, that Vehicle and BurnerGenerator prototypes, have a glitch about the burnt result.
When a vehicle or a burner generator consume an item, and they use as a fuel an item that should return a burnt result item, if they are mined before they complete the consumption of the fuel item the burnt result item will be lost.
An option to solve this problem will be; introduce a check that when a vehicle or a burner generator (but this can be extended to other entities) are mined, if is expected that from the current consumption process would have been produced a burnt result item, give it with the entity item (vehicle or burner generator).

[Deadlock989]

There are (admittedly obscure) situations where that could be abused. Essentially you could get instant burnt results just by repeatedly mining a car, instead of the seconds/minutes/hours it would normally take to exhaust the fuel item. The fuel hasn't been consumed yet so there is no completed result yet. I had plans for a process (now abandoned however) that would have been ruined by such a change, where the burnt result was the only way of obtaining a particular item but you had to burn and consume energy to get it.

I would be fine if it was in the game but controllable with a flag that defaulted to off - a bit like the return_ingredients_on_change property on crafting machines.

[Linver]

I agree too that a flag like return_ingredients_on_change/return_ingredients_on_mining (maybe default true? I dunno if this is equal to ingredients better leave this decision to devs) will be the best solution, in any case both problems that we are discussing are glitches, specially in the actual state where items are mandatory voided.

[PFQNiet]

I definitely feel like this is something that should be "opted in" to, if added. As it is, you should be able to add a relatively cheap control script for mined events, check if a burner exists, check if the burning fuel has a burnt_result, and add it to the event buffer if so.

A similar idea can be done to refund the currently burning fuel if it hasn't been used much. You could even combine both and have it return the un-burnt fuel if it's 50% remaining or higher, or the burnt result if less than 50% remains. Might have interesting applications. It depends on how you want your mod's energy economy to work, and how much it matters that a determined player could "cheat" extra stuff if they really want to.

[Linver]

Cheap?

Code: Select all

-Each time an entity is mined ->
--Check if have a get_burnt_result_inventory() valid, if true->
---Check if the current energy is greater than 0->
----Give the burnt result of the last consumed item 

Excluding that "give the burnt result of the last consumed item" I'm not sure how can be impelemented but, do this on each entity that is subclass of crafting machine or vehicle, is not cheap

This or become something from the main code or from the modding point is something of very not UPS friendly.

[Rseding91]

Cheap?

Code: Select all

-Each time an entity is mined ->
--Check if have a get_burnt_result_inventory() valid, if true->
---Check if the current energy is greater than 0->
----Give the burnt result of the last consumed item 

Excluding that "give the burnt result of the last consumed item" I'm not sure how can be impelemented but, do this on each entity that is subclass of crafting machine or vehicle, is not cheap

This or become something from the main code or from the modding point is something of very not UPS friendly.

That is cheap. You're only running code on-mined-event and the code is all O(1) cost.

[PFQNiet]

Code: Select all

if event.buffer then
  local burner = entity.burner
  if burner then
    local burning = burner.currently_burning
    if burning then
      local burnt = burning.burnt_result
      if burnt then
        event.buffer.insert{name=burnt.name,count=1}
      end
    end
  end
end

Seems fine to me.

[Linver]

Cheap?

Code: Select all

-Each time an entity is mined ->
--Check if have a get_burnt_result_inventory() valid, if true->
---Check if the current energy is greater than 0->
----Give the burnt result of the last consumed item 

Excluding that "give the burnt result of the last consumed item" I'm not sure how can be impelemented but, do this on each entity that is subclass of crafting machine or vehicle, is not cheap

This or become something from the main code or from the modding point is something of very not UPS friendly.

That is cheap. You're only running code on-mined-event and the code is all O(1) cost.

No LuaPlayerMinedEntityEventFilters can filter the exact entity wanted, but if we analize cost of all callbacks, if n is the number of callback triggered by the on_player_mined_entity event, that will exit instatly because no entity match the wanted class (a special case to this example), and that if-block cost 1 operation, the cost is O(n), and this cost cannot be reduced, what can be reduced is the cost of the whole callback, if was implemented in C/C++ instead of Lua.

And this must be checked on on_player_mined_entity and on_robot_mined.

[SWeini]

To me it looks like under certain circumstances the burnt_result is lost.

Repro steps:
Create an entity (building, car, train, probably more) with burner energy source
Add a matching item with burnt_result
Start using energy, but do not fully use it
Deconstruct the entity

Actual result: You don't get back anything, neither the original item nor the burnt_result
Expected: You get back the burnt_result

Why? There are mods with items that can be recharged (batteries, fuel cells, air filters, stuff like that). These may be either expensive, or you only need very few in a closed loop system. Losing that burnt_result is a real loss in some cases. Maybe you could make this behavior configurable, but I believe for most items with burnt_result it makes sense to always get back the burnt_result, even if only partially used.

[Loewchen]

This is not a bug, moved to API requests.

[robot256]

For reference, the only effect this has in Vanilla is losing a depleted uranium fuel cell when you mine a nuclear reactor. That's not an unreasonable cost for moving an operational nuclear power plant. It's also trivial to avoid simply by letting the fuel time expire. And it is consistent with the behavior of assemblers, where mining or changing recipes loses the in-process ingredients.

In vehicles, it's more awkward because you have to drive into a wall for long enough to deplete the fuel cell/battery. And for things like battery packs, it doesn't necessarily make sense to be destroyed when you pick up a car and move it. A mod could refund the depleted pack via script in most cases, but it would be nice to have it happen automatically. Possibly as a flag on the fuel item or burner prototype.

[SoShootMe]

And it is consistent with the behavior of assemblers, where mining or changing recipes loses the in-process ingredients.

IIRC the behaviour when mining/changing recipe on an assembling machine has changed, but right now item ingredients are returned (which seems sensible to me). So I would say "refunding" the appropriate burnt_result would be consistent with that (and the current behaviour is not), given that - as with the used uranium fuel cell in vanilla - burnt_result items often represent a "container".

[FuryoftheStars]

And it is consistent with the behavior of assemblers, where mining or changing recipes loses the in-process ingredients.

IIRC the behaviour when mining/changing recipe on an assembling machine has changed, but right now item ingredients are returned (which seems sensible to me). So I would say "refunding" the appropriate burnt_result would be consistent with that (and the current behaviour is not), given that - as with the used uranium fuel cell in vanilla - burnt_result items often represent a "container".

The ingredients to a recipe are refunded, yes, but the in progress burnt fuel is not.

While I agree that yes, it may be appropriate for some mod added items to get returned, it doesn’t currently make sense for all items (burn 90% of a piece of coal or wood, then mine the building and get 100% back??). Unless fuel can be made to remember its burnt state like ammo or research bottles remember their consumed state, but then I think this adds complexity elsewhere. A simple flag for mod added items may be best.

[curiosity]

This is not a bug

Source?

[SoShootMe]

The ingredients to a recipe are refunded, yes, but the in progress burnt fuel is not.

The suggestion isn't to return the "in progress" item, but to create a burnt_result if there is one. I think this makes sense but has limited value in the base game: the only such item is the uranium fuel cell, for which the burnt_result has relatively low value, is not directly reusable, and burns continuously (so you could just wait if you really don't want to "lose" the used uranium fuel cell). But, to pick a popular example, the opposite applies to Krastorio 2's charged antimatter fuel cell.

The possibility you described for items that may be used as fuel to store how consumed they are also makes sense to me, especially if they don't have a burnt_result. This might be appropriate for items with a high fuel lifetime (value/power), but the importance is related to the item cost. Again, I think this has limited value in the base game: the only item with a high fuel lifetime is nuclear fuel, which is not that expensive. It may be beneficial for some mod items but I can't think of an example.

This is not a bug

Source?

FWIW the original post seems more a suggestion to me. The related point FuryoftheStars subsequently made is a modding interface request, but one that also needs new functionality rather than just exposing an interface to allow existing functionality to be customised by mods.

[Bilka]

Merged into topic with same suggestion and workaround.

[SWeini]

I finally found the time to do this as a mod. It works perfectly for on_player_mined_entity and on_robot_mined_entity. However for script_raised_destroy it's not so clear what to do. I have decided to spill the item on the ground. I've added a related modding request at viewtopic.php?f=28&t=105289 to be able to improve that behavior.

[Xorimuth]

I finally found the time to do this as a mod. It works perfectly for on_player_mined_entity and on_robot_mined_entity. However for script_raised_destroy it's not so clear what to do. I have decided to spill the item on the ground. I've added a related modding request at viewtopic.php?f=28&t=105289 to be able to improve that behavior.

Destroying a machine in lua destroys all the items in it. I don’t see why the burnt result would be any different?

[robot256]

I finally found the time to do this as a mod. It works perfectly for on_player_mined_entity and on_robot_mined_entity. However for script_raised_destroy it's not so clear what to do. I have decided to spill the item on the ground. I've added a related modding request at viewtopic.php?f=28&t=105289 to be able to improve that behavior.

Destroying a machine in lua destroys all the items in it. I don’t see why the burnt result would be any different?

I agree. Script_raised_destroy generally happens after the destroying mod has saved everything it wants from the entity in question. For example, Space Exploration, Vehicle Wagon, Multiple Unit Train Control all use script_raised_destroy to maintain mod compatibility when teleporting/storing/replacing entities. They already make sure the burner fuel items are correctly preserved, so any additional dropped items will cause a great many item duplication bugs.

[SWeini]

I need to bring this topic up again, because it seems impossible to get the burning fuel when removing equipment from the equipment grid. (viewtopic.php?f=221&t=105300 was moved to "Won't implement" because of technical reasons)

Currently I can't see any way in my Py Alternative Energy game not to lose containers when I try to refuel the equipment grid and accidentally use the wrong mouse button (removing the equipment instead of opening it) - or when a mining drill runs out of resources and I need to move it a few tiles.

If there is no way to make this work by using events, this needs to be implemented in the game engine itself.

This is very likely not a performance issue, extra stuff only needs to happen when equipment or entities are deconstructed/destroyed/removed.

My suggestion is to add a property to the item prototype that defines what happens to destroyed burners when it is currently burning that item. It can be one of these behaviors:
- status quo, it is lost, can be the default
- get back the fuel itself
- get back the burnt_result
- get back the fuel or the burnt_result randomly, chances determined by the percentage of fuel that is left
- get back the fuel if percentage of fuel used is below a fixed or configurable threshold, the burnt_result otherwise

This gives mod authors enough control so that the mechanic can always be helpful without being abused in certain situations.