The sound feedback is a good idea. Otherwise this mod does the same thing as the Pushbutton mod - which also uses F by default.

I would certainly be happy for the sound cues to be added to pushbutton as well if justarandomgeek happens to like the idea. I've certainly learned a lot from how they and other mod devs that have written similar mods have implemented them.

Pushbutton is a bigger mod though, and it has some on_tick control scripting to handle the functionality of the pushbutton entity. Since I didn't actually need pushbuttons in my playthrough, I wanted to make something leaner and more limited in scope, without any on_tick scripting.

Pushbutton has an on_tick handler, but it just runs two if statements (that will be false except for 1 tick when player uses hotkey on pushbutton entity) and doesn't have anything that runs for every pushbutton each tick. The performance impact should be absolutely negligible (0.002 ms per tick), you have never seen that mod use any amount more CPU time than that due to on_tick when not doing anything. If the goal is to go from negligible to 0 and that's why you really don't want a on_tick running even when it does nothing to your UPS already, you could un-register the on_tick handler dynamically and register it whenever something needs to run the next tick.

Sure. I neither profiled the pushbutton on_tick code nor did I actually download it to use in game. But I also didn't make any performance claims about that code. I simply said that it's there.

As a matter of principle, I prefer to use mods that do no more than what I'm looking for, whether it has to do with adding/modifying entities or control stage scripting. From my perspective, the main draw of the Pushbutton mod is the actual pushbutton entity and its ability to emit a single-tick pulse on demand. I had no need for that extra entity, but fancied having the hotkey-toggle feature that it implements, almost as an afterthought.

I happened to think that minor feature is worth having on its own, so I wrote this up. If you happen to have a use for pushbuttons, then by all means use the Pushbutton mod instead of this one.

If you aren't saying that Pushbutton has performance issues then I have nothing to correct :)

Making a mod that only does exactly what you need and no more is valid, I have nothing against that.

Respects player reach.

That seems pretty bad though. Why would a mod that implements a hotkey to more easily toggle constant combinators throw in an artificial limitation to its usefulness like that? You can toggle combinators from the other side of the map by using map view and 2 copy-paste operations, in vanilla. Some players mostly toggle their constant combinators that way because doing it remotely is basically the only real time you really need to toggle them. If you are close that probably means you are building the circuit and you don't really need to toggle them. Do you really want that slow and awkward interaction to be the way that people actually toggle their combinators? Why wouldn't you want to improve that interaction to something easier? You can probably even do that without radar coverage (since you can now place blueprints without needing radar coverage), while your method would still require radar coverage even if the reach check was removed. So the vanilla way would still be more powerful even if you removed that limitation, so if your reasoning is that you think it would be too cheaty then you are misinformed.

Player reach required for interacting with placed entities is a big design flaw in vanilla Factorio and mods shouldn't work to enforce this limitation even harder than vanilla. That's like the opposite of QoL...

Thank you for your feedback.

I think you're reading too much into my choice to "respect player reach". Respecting player reach for me means using whatever player reach value the player has chosen to have, whether it's the vanilla value, or a higher value configured via mod or command. I specifically don't want to impose my views on player reach on all players, and removing the player reach check would implicitly do that.

One tangible benefit of having some limit to player reach is that it limits accidental toggles, which I already happen to occasionally encounter with inserter rotation. Such accidental toggles would occur more frequently if player reach was unlimited.

Parenthetically, I only got the idea to even check for player reach from the pushbutton mod code—I figured that if a far more experienced modder thought fit to add that check to their toggle code, that I should give it serious consideration as well.

Respecting player reach for me means using whatever player reach value the player has chosen to have, whether it's the vanilla value, or a higher value configured via mod or command. I specifically don't want to impose my views on player reach on all players, and removing the player reach check would implicitly do that.

No, you are imposing your view with your choice, you don't get to say that you don't. The player reach check doesn't exist for blueprinting to toggle, you are deviating from what I consider expected behavior. I stopped using far reach mods for my regular non-creative worlds, I find it a bit cheesy for building things and I want to let my robots do things if it's far away. But for all things that alters already built structures that updates instantly with a blueprint overlap without bots being sent out I want those interactions to be easier. I should be able to open a constant combinator and just toggle or change it in any way I want and I want QoL mods to remove the awkward pointless interactions of copy pasting twice to change things.

If a bot is required for the modification (like changing direction of a belt or doing an upgrade) when I do an overlapping paste for the change to actually apply, then I expect mods to respect reach for those kinds of interactions and would consider that fair.

One tangible benefit of having some limit to player reach is that it limits accidental toggles, which I already happen to occasionally encounter with inserter rotation. Such accidental toggles would occur more frequently if player reach was unlimited.

This is such a bad argument I can't even take you seriously. I'm stunned and speechless.

Parenthetically, I only got the idea to even check for player reach from the pushbutton mod code—I figured that if a far more experienced modder thought fit to add that check to their toggle code, that I should give it serious consideration as well.

I'm using Pushbutton, I love that mod. Didn't know it had that limitation though since I've been using it with editor mode for designing my circuits so far. It's going to be painful to use that then when I'm importing my circuits back to non-creative worlds. A bit confused why a great modder like justarandomgeek would make such an obviously bad choice. But no-one is perfect, maybe he just didn't think it through? Well regardless just because he did a mistake doesn't mean you need to copy his mistakes too, strive to improve.

Can we sum this up with "a map setting to disabled reach checking would be nice"? ;-)

Qon—if your intent was to dissuade me from ever wanting to post another mod again, then you've done a fantastic job.

How dare I choose to use a game mechanic that you personally dislike! You could have easily removed the player reach check from your own copy of the mod (you're clearly capable of it), but instead you chose to berate me for for not designing the mod to meet your specific expectations.

Please feel free not to use my mod as it clearly doesn't meet your standards. I'm not even sure why you would be using it if you have Pushbutton already installed. I shall be sure to consult with your personal ruleset first in the event that I ever want to make another mod. Or not. Perhaps I'll just be disabling discussion for anything I post. I think I'd be quite content not to receive feedback like yours again.

harag—I'm grateful for your feedback. Sorry you got caught up in this.