Factorio Forums

TL;DR

It's very easy to accidentally remove an entity, so let's make it a bit harder by adding explicit user intent. This has probably been suggested in the past, but I haven't found it.

What ?

Right-clicking removes placed entities and ground tiles like stone brick and concrete. I propose adding a per-entity user-toggleable property to placed entities to "lock in place," visible when you click them like their other properties and off by default to retain the existing removal behavior. This property if "on" would outright prevent right-clicking to remove and, depending on the feasibility of the idea, prevent being queueable for deconstruction as well. In the event of right-clicking it the standard "cannot X" notifications (e.g. "can't reach" with error buzz sound and flyout text) can be used to alert the player, otherwise some more obvious visual and audio feedback. In the event of deconstruction probably do whatever is already done when you try to highlight an entity that can't be queued for deconstruction, like display an appropriate warning icon or something.

Additionally, maybe add the ability to drag a box to highlight a region of multiple placed entities to mass toggle locking in place. Optionally, such a locking property may also be exposed to blueprints as "include existing locking in place" or something similar to other blueprint toggles, or have blueprinting default all lock-in-place to "off" but let the player know that current values won't get saved. If an entity is on the ground waiting to be picked up for whatever reason or otherwise unplaced, the property should be "off" similar to how unplaced assemblers don't retain what recipe they last made and how unplaced filter inserters don't retain whitelist/blacklist.

This wouldn't apply to ground tiles nor should it change entity behavior when taking damage. I'm not yet sure if such a toggle should be added to belts and pipes, but if they're treated as entities rather than tiles (being able to click on them and see properties would seem to support the former, and belts and pipes can certainly be removed just as easily as other entities) then probably yes.

Why ?

To remove placed ground tiles you must first have a tile in your hand, either landfill or any of the ground tiles, and then right-click will successfully remove them. This adds user intent and entities have no such limitation, therefore it is much easier to accidentally remove them if you simply rest your hand on the mouse or if you have twitchy fingers or something, and when this happens you're likely unaware of where the mouse is while you're distracted or thinking about your next move. It's less prevalent with laptop trackpads rather than external mice, but that is almost entirely due to the physical construction and placement of a trackpad in a laptop shell, and may actually be a worse problem than with regular mice if touch-tap is enabled. Yes there already is a minimum button hold time for removing entities already in place, but simply increasing it would slow most players down and the timer bar that displays isn't enough feedback (and currently is the only feedback the game offers) to let a more distracted player know that right-click removal is happening.

For most use cases, the addition of this toggle wouldn't affect normal player action; being off by default retains the existing removal behaviors. Computationally, checking an entity for "is locked in place" should only be done at the beginning of a right-click removal action (probably immediately at the start of on-mouse-down) or when a deconstruction rectangle is highlighting it (basically however often the game already checks for "can-be-deconstructed," probably roll that entity property into the list of things the game already checks for entities). Adding this toggle adds "user intent," specifically the ability for the user to choose if they actively want an entity in place or not and later if they actively want to remove the entity or not, and the immediate benefit is preventing accidental removals. The most significant drawback is if a player tries to remove a locked-in-place entity and has forgotten (most likely due to time passing) or is otherwise unaware that it is locked-in-place (maybe on a multiplayer server and someone else locked it in place or something), therefore has to know about being able to click on the entity and toggle that property off before attempting to remove it again. I'm not sure if there should be some time throttling in place to prevent rapid toggling, but whatever other toggleable entity properties already have in place to prevent such obvious trolling should be good enough if there already exists such a measure.

For general "can-be-deconstructed" checking, being within player reach probably takes priority for the flyout notifications and any "locked-in-place" checking should probably only be done if the entity is otherwise normally within "can-be-deconstructed" conditions.

NB

This is not a call for "git gud" or "pay attention" nonsense to pollute this suggestion thread, and I don't expect a majority or even a vocal minority of Factorio players are "pro Korean Starcraft player" levels of micromanaging so if after reading your response is that then there's the door. I consider this suggestion related to accessibility and if someone has an alternative HID input used for the game the likelihood of buttons or keys being easier to press and therefore more likely to be pressed accidentally may go up significantly. I don't personally have such a device, but I am currently using this trackball mouse and I've found that resting my fingers on the side it is extremely easy to accidentally right-click.

Well what you describe happens to me regularly, especially when I play after a long day of work and I'm half falling asleep before my factory, which is almost every day. However, I disagree with you with the solution. Unfortunately, you have banned from the discussion what I have always considered the real answer to that :

Apollolux wrote: Sun Jan 24, 2021 8:26 pm This is not a call for "git gud" or "pay attention" nonsense to pollute this suggestion thread

So I'll try to suggest something that wouldn't require what I consider a cure worse than the disease. How about changing the "Mine" keybind into something less easy to misclick ? Like Ctrl-Right-click for example.

As long as it is able to be turned off somehow.

Note: I had a longer response, but a browser crash ate it

Koub wrote: Sun Jan 24, 2021 9:01 pm How about changing the "Mine" keybind into something less easy to misclick ? Like Ctrl-Right-click for example.

Before this post I didn't even realize the keybinding could be changed, so thanks! This to me presents a problem of discoverability, however. "Mine" and "Build" are two of the most important controls after movement, but there's nothing in the controls menu to indicate their importance, and even within "Basic Interactions" they're not even first in the section. During normal gameplay, there's no active indication that these can be changed this easily, so I would probably also suggest making it more obvious to the player that these controls can indeed be changed.

While changing the control can certainly solve the initial problem I reported of accidental right-clicks, there's a scenario that I didn't originally document in the first post that still exists that could be solved by locking in place. For me this was more common early on when I was starting to position my factory, but it can certainly still occur whenever a player manually places stuff and later wants to reposition. I had interwoven underground belts with power lines (in my case, big electric poles surrounded by four solar panels and four accumulators) and I wanted to just run straight down alongside and remove the underground belts to reroute the coal line it had. Running straight down and holding Mine removes everything along that vertical line - belts, poles, accumulators - when all I wanted to do was remove just belts. To remove just belts I had to hold Mine, run down, let go, run down past the power, make sure I'm targeting the belt rather than a pole or accumulator, then hold Mine, rinse and repeat. This was quite annoying, it was not the first time I was doing that, and I expect it's not the last. Being able to set lock-in-place for the non-belts would allow running straight down and mining only the belts.

I understand that this particular scenario is probably avoided by using deconstruction planning that's only set to belts or whatever, but creating the plan ahead of time is not a thing I think about when making an on-the-fly decision like repositioning belts or pipes while I run somewhere.

Apollolux wrote: Mon Jan 25, 2021 12:14 am Note: I had a longer response, but a browser crash ate it

Koub wrote: Sun Jan 24, 2021 9:01 pm How about changing the "Mine" keybind into something less easy to misclick ? Like Ctrl-Right-click for example.

Before this post I didn't even realize the keybinding could be changed, so thanks! This to me presents a problem of discoverability, however. "Mine" and "Build" are two of the most important controls after movement, but there's nothing in the controls menu to indicate their importance, and even within "Basic Interactions" they're not even first in the section. During normal gameplay, there's no active indication that these can be changed this easily, so I would probably also suggest making it more obvious to the player that these controls can indeed be changed.

or just acknowledge your problem is solved and be happy

unless you want to jam everything in the player's face all the time. that sounds bad. and it sounds like a different game.

I wouldn’t use this. The case you describe happens to me only, if I’m not focuse anymore. A clear sign of being tired. As with Koub. And I can imagine that it also happens, depending on the input-device (trackpad). But the suggested solution is good enough. I just press ctrl-z to undo, then save and go to bed.

I won’t change much with the keyboard-settings: with a laptop you need, no, you are forced to look deep into that settings, I changed some things to make it easier on laptop. Explicitly highlighting some keys will only make players overlock other keys (like g and v ). There is no reason why one key should be more important than others.

ptx0 wrote: Mon Jan 25, 2021 5:05 am unless you want to jam everything in the player's face all the time. that sounds bad. and it sounds like a different game.

No, not all the time of course. Being literally the first tutorial and/or tip when starting a new game should be enough active indication if a player doesn't ignore it.

ssilk wrote: Mon Jan 25, 2021 7:37 am Explicitly highlighting some keys will only make players overlock other keys (like g and v ). There is no reason why one key should be more important than others.

Looking at the controls list, the G and V you mention seem to be the default for connect and disconnect trains (I haven't reassigned them myself). If that's what you mean, then I would argue Mine and Build are objectively more important (also useful) to the game from start to finish than Connect/Disconnect Train/Rolling Stock are, regardless of how important connect/disconnect is situationally, and IMO should indeed be highlighted as such in the controls list. AFAICT manual mining and building only ever loses importance and utility if a player is really adept at having robots do most/all the work.

I go with you saying, that the key mapping should be part of tutorial.

For the highlighting of keys in the settings: then Q, W, E, R, A, S, D, F, C and space should also be highlighted . And as modder I would highlight all, because it is easier to find my mod.