Can't you just reduce the amount of ingredients required? Basically, what's the difference between: and

This is a cool idea! A little tricky to implement though because the way electricity works is not very moddable through the API.

I did write this article a while ago that includes some older mods that did similar things. Some info is a little outdated due to 2.0 release, but most of it is still ...

Ah, wait, if you press escape then it goes to character controller, and then you put it back in remote view, so have to press escape again... I see

What

Add a field to ghost build events to gives a mapping between parameters and the signals they need to replaced with. Something like


parameters : dictionary[SignalID → SignalID] : mapping from parameter signal to signal it was replaced with


Will probably be needed for the events: on ...

I could set the controller back to the remote view in an event handler, but I'm sure the player would not be able to access the game menu.


What do you mean with this? I'm quite sure if you listen to on_player_controller_changed and set it back to remote view if the player left it that it will ...

For anyone looking for this in Factorio 2.0+, it's now done using https://lua-api.factorio.com/latest/cla ... ntity.html

Ah I see. In that case I would strongly prefer it being a required field, and not have a default value. For the same reason of keeping it simple. It's an very easy migration for old mods, and very easy for new modders to learn. If they don't add the property the game will error and tell them exactly ...

Option B for sure. I think keeping it simple is easier to understand than a gotcha moment where modders didn't know `additionional_categories` existed.

Sure, new modders might miss that property the first time. But it will be one of the many other properties that new modders will miss while ...

Have you tried ValvePrototype::flow_rate?

Edit: scratch that, that's something else

+1

TL;DR

Add a way to register an a specific entity (or it's control behaviour) to raise an event when the signal input changes (and optionally passes some conditions ). Similar to how register_on_object_destroyed works. Something like:


---Lua psuodo declaration of function to register a specific ...

Alternative approach which would also be great: 116359

What

If you have a turret with turret_base_has_direction=false then the turret assumes that it doesn't support direction. This means the direction is (sometimes?) not saved in blueprints which causes weird behaviour where (sometimes) the turret looses direction.

Reproduction

This came up with ...

Related
116056
128297

+1 This would be useful for space exploration too. Even if its similar rto ProductivityBonus Tech Effect.

+1 This has happened to me too many times

Thanks for responding Lou!


Most likely yes, but it has lower priority than bugfixes - so please create a feature request post so it is not forgotten.


Created a request: https://forums.factorio.com/viewtopic.php?p=674301#p674301


That's a bit more problematic both technically and design-wise ...

Created as suggested by Lou: https://forums.factorio.com/viewtopic.php?p=674092#p674092

Currently force building will fail on non-buildable tiles if you haven't placed a cover tile before on that specific non-buildable tile. This means that you need to first manually place a cover tile on every ...

Created as suggested by Lou: https://forums.factorio.com/viewtopic.php?p=674091#p674091

Currently the default cover tile that's used for force building is stored per force, and not per player. This can create very annoying situations in multiplayer where while you're purpousfully using a specific ...

The non-default covers are saved per-tile. In the "not-works" save, you paved over (some) natural ice, but not over ice-platfrom, that's why the autofill failed


In this case, could it not take a guess and take the first coverable tile instead of failing? Just like when you pipette some ores it ...