Factorio Forums

Hey,

is there a way to let a recipe increase the energy consumption of the corresponding assembling machine, similar to the 'emissions_multiplier' field?

If I increase the field 'energy_required' the assembling machine won't consume more energy, but will take longer to complete the recipe - which isn't really what I want.

koun wrote: Mon Jul 01, 2019 3:19 pm Hey,

is there a way to let a recipe increase the energy consumption of the corresponding assembling machine, similar to the 'emissions_multiplier' field?

If I increase the field 'energy_required' the assembling machine won't consume more energy, but will take longer to complete the recipe - which isn't really what I want.

Short answer - no.

Longer answer - well, it does consume more energy if the recipe takes longer. Because the machine runs longer per cycle. But you want different recipes to consume energy at a different rates. No such property for recipes currently exists. You're stuck with (a) asking for it in the modding interface forum, (b) using a different crafting machine for that class of recipes, with a different energy consumption rate.

Hm, maybe a hacky (and imho dirty) way to implement this behaviour could work like minno's mod More Mining Productivity, that creates invisible beacons with invisible modules with the desired effect.

So... I will kindly ask prague. :x

The property "energy_usage" determines how much energy needed to operate the machine and is the property that needs to be focused on. That can be set at the time the entity is defined.

Another way to look at this challenge might be to create a second set of assembly machines for your module. The base set is what the the low energy usage. The second set is is the high energy usage. Then if the recipe is the expensive energy recipe programmatically change the machine to the right type of machine.

This check might have to be triggered off some sort of on recipe change in machine event.

A second way to accomplish this might be to do a binary edit of the table once it has been built.

Hiladdar wrote: Mon Jul 01, 2019 7:50 pm This check might have to be triggered off some sort of on recipe change in machine event.

Unluckily the API doesn't have a convenient 'on_recipe_change' (or something like that) event. What would be a suitable way to implement that?

koun wrote: Wed Jul 10, 2019 1:31 am

Hiladdar wrote: Mon Jul 01, 2019 7:50 pm This check might have to be triggered off some sort of on recipe change in machine event.

Unluckily the API doesn't have a convenient 'on_recipe_change' (or something like that) event. What would be a suitable way to implement that?

New assembling machine with new recipe category. For example the chemical plant and centrifuge are also assembling machines, but with special recipe categories.

That's not what I meant.

I need to have a script executed when the recipe in a machine is changed or set. So that I can make changes according to the active recipe.
Something like this: Except that there is no 'on_recipe_change' event and I need to use another one. So on what kind of event from the api could I use to have such a functionality?

(Sorry, somehow my brain has issues with the words today.)

on_gui_closed
on_entity_settings_pasted

And add all assembly machines to that global.assembly_machines

Oh nice, that would allow me to create my own events. Thanks a lot. :)

How serious are the performance implications of such a solution?
And would it make sense to let such a script run only every.. 6 or 10 ticks via script.on_nth_tick?

koun wrote: Wed Jul 10, 2019 12:23 pmHow serious are the performance implications of such a solution?
And would it make sense to let such a script run only every.. 6 or 10 ticks via script.on_nth_tick?

Potentially very serious. IMO onTick is an absolutely terrible event to simulate game mechanics with. And scanning every assembler in the world, every single tick, just to see if any of them has just changed a recipe, is completely ludicrous. I wouldn't touch this with a bargepole. If you don't do it every tick but every Nth tick, then you're going to have all kinds of unwanted crap like lost ingredients etc.

Much better to go with what DaveMcW suggests, although there are other problems to solve. Or ask for a dedicated onRecipeChanged event. Or accept that both the game engine and the Lua interface to it have limitations.

koun wrote: Wed Jul 10, 2019 12:23 pm How serious are the performance implications of such a solution?

Of asking every single fucking assembling machine on the planet if it has a recipe every tick? What's the most serious word you know for "serious"? Because that's your answer. Unless you want it only for a really small subset of custom assembling machines.

General rule of thumb:
If you want performance -> Hook into all events that might change it.
If you don't care about performance -> Iterate the stuff in on_tick.

Deadlock989 wrote: Wed Jul 10, 2019 12:40 pm Or ask for a dedicated onRecipeChanged event.

Has already been denied: viewtopic.php?f=28&t=61339

Or just accept that you'll have to use a different machine for "fast bust energy expensive recipes".

eradicator wrote: Wed Jul 10, 2019 12:44 pm Of asking every single fucking assembling machine on the planet if it has a recipe every tick? What's the most serious word you know for "serious"? Because that's your answer. Unless you want it only for a really small subset of custom assembling machines.

The most serious word for 'serious' I know is probably 'todernst' or 'gravallvarlig'.
Well, I want it for a small subset of custom assembling machines (fawogae-plantations in pyanodons mods), but it's hard to estimate how much of them a player is likely to place. Maybe in the range 100 to 500 for a really big factory.

Deadlock989 wrote: Wed Jul 10, 2019 12:40 pm If you don't do it every tick but every Nth tick, then you're going to have all kinds of unwanted crap like lost ingredients etc.

This shouldn't be a problem if I'm not mistaken. I want to manipulate the module effects that affect the assembling machine. So I guess a delayed update would only make the player loose 1/6 seconds worth of speed/productivity/consumption.

koun wrote: Wed Jul 10, 2019 1:03 pmThis shouldn't be a problem if I'm not mistaken. I want to manipulate the module effects that affect the assembling machine. So I guess a delayed update would only make the player loose 1/6 seconds worth of speed/productivity/consumption.

No, because unless I've lost the plot on this strange thread (which is likely/possible), you're proposing replacing an assembler entity with another (more energy-hungry) assembler entity, for certain recipes only. If that isn't done immediately on switching to one of the target recipes, and the old assembler is allowed to start processing ingredients, those ingredients will be lost when the entity is fast-replaced with the new entity, the same as if you'd cancelled the crafting. "In progress" ingredients are always lost, see any of the gnashing-of-teeth centrifuge threads for evidence. And you can't disallow the old entities from using the recipes and beginning the processing, because then you'd never be able to select the recipe in the first place.

This plan has more holes in it than a lace doily that has been attacked by incontinent moths in fishnet stockings.

Deadlock989 wrote: Wed Jul 10, 2019 1:18 pm ... those ingredients will be lost when the entity is fast-replaced with the new entity, the same as if you'd cancelled the crafting. "In progress" ingredients are always lost, see any of the gnashing-of-teeth centrifuge threads for evidence. And you can't disallow the old entities from using the recipes and beginning the processing, because then you'd never be able to select the recipe in the first place.

You can disable that behaviour on the assemblers: https://wiki.factorio.com/Prototype/Cra ... _on_change. This is the same property that https://mods.factorio.com/mod/Dont_lose ... ngredients uses.

eradicator wrote: Wed Jul 10, 2019 12:50 pm Or just accept that you'll have to use a different machine for "fast bust energy expensive recipes".

Oh, actually it's not about that idea anymore. I just posted here because here is where Hiladdar spoke about some sort of on recipe change... and I was afraid to spam the forum.

Deadlock989 wrote: Wed Jul 10, 2019 1:18 pm No, because unless I've lost the plot on this strange thread (which is likely/possible), you're proposing replacing an assembler entity with another (more energy-hungry) assembler entity, for certain recipes only. If that isn't done immediately on switching to one of the target recipes, and the old assembler is allowed to start processing ingredients, those ingredients will be lost when the entity is fast-replaced with the new entity, the same as if you'd cancelled the crafting. "In progress" ingredients are always lost, see any of the gnashing-of-teeth centrifuge threads for evidence. And you can't disallow the old entities from using the recipes and beginning the processing, because then you'd never be able to select the recipe in the first place.

This plan has more holes in it than a lace doily that has been attacked by incontinent moths in fishnet stockings.

Yes, sorry, I really should have created a new thread.

I'm following the idea of creating invisible beacons with invisible modules with the desired effects (as I remarked in my second post, here is the code if you want to see it), rather than replacing the entity. So far it's working when I don't care about the recipe.

(I like your comparisons, very poetic)

Well, if it's only for a subset of machines, and you don't care about the player losing (or gaining) a bit of energy/stuff, then updating beacons in a fixed-time manner should be ok. Fixed-time means that you process only i.e. 50 beacons once per second. That way the scale of the factory only influences the update delay, and not the processing cost, keeping your mod viable for large factories. This is what for example mods like "Bottleneck" do.

Edit: If you hook into some events like gui_closed to detect the recipe change and only use the on_tick as a backup in case you missed some recipe change (because perfect detection would be difficult), then you could use a much larger delay in on_tick.

Yes, the principle "do stuff for only one entity per tick" is very fast for all factory sizes.