QoL for ghost mode, copy-paste and blueprint placement

[taleden]

TL;DR

Building in ghost-mode and placing blueprints should be able to upgrade or convert similar existing entities to more closely match the ease of use of direct building.

What ?

When ghost-building, cut/copy-pasting or placing a blueprint on top of an existing ghost:

• Always allow upgrading similar entities (i.e. eastbound yellow belt ghost to eastbound red belt ghost);
• Hold SHIFT to also convert compatible entities (i.e. overwrite a belt ghost direction, or put a splitter ghost onto an existing belt ghost, just like is allowed when direct building);
• Hold CTRL+SHIFT to also replace conflicting entities (i.e. delete any other non-upgradable, non-convertible ghosts that are in the way of the new ghosts).

When ghost-building, cut/copy-pasting or placing a blueprint on top of an existing built entity:

• Leave the default behavior unchanged (allow only when all overlaps are exact matches or entirely new entities);
• Hold SHIFT to upgrade similar entities (i.e. flag assembler 1s for in-place upgrade to assembler 2s, just like the upgrade planner);
• Hold CTRL+SHIFT to force-build by converting compatible entities (i.e. flag a belt for deconstruction and put a splitter ghost there) and replacing conflicts (i.e. flag a pair of underground belts for deconstruction and put a machine ghost there, perhaps because the blueprint also upgraded the belts and they reach further underground now).

Specifics on terms used above

• direct build - Placing a buildable item from the inventory directly onto the ground; as opposed to placing a ghost, whether that be by ghost-mode building a single entity, or pasting from the clipboard, or placing an entire blueprint.
• configuration - The non-physical options set on an entity such as assembler recipe, splitter priority, inserter stack limit, combinator operations, circuit network settings, etc.
• exact match - Nothing to do because the old and new entities have exactly the same type, position, orientation, configuration and modules. If the new entity is a ghost-mode placement (not copy-paste or blueprint), then only the type and orientation are considered since ghost-mode never has a configuration. An eastbound red belt is an exact match for an eastbound red belt, but not an eastbound yellow belt (different type) or a southbound red belt (different orientation). Previews of this case should always be tinted blue to indicate that they would cause no change to the existing entity or ghost.
• upgrade similar - Place a new entity over one with a functionally matching type (as allowed by the upgrade planner) and the same position, orientation and configuration (again, excepting ghost-mode placement). An eastbound red underground is similar enough to up(down)grade to an eastbound blue underground, but not an eastbound red belt (dissimilar function) or a southbound red underground (different orientation), or (as a bit of an edge case) an eastbound yellow underground (they can be safely upgraded, but not downgraded since they may not reach far enough). An assembling machine 1 making gears with speed module 1s is upgradeable to an assembling machine 2 making gears with productivity module 2s, but not an assembling machine 1 making pipes (different configuration). When this placement is allowed, its preview should be tinted green to indicate that it's not identical, but similar enough to be flagged for in-place upgrade just like the upgrade planner does.
• convert compatible - Place a new entity over one with a different but functionally compatible type (as allowed by direct-build rules) and the same position. An eastbound red underground is compatible enough to convert to a southbound yellow belt, but not an inserter (incompatible function); it could, however, be converted to an eastbound yellow underground, even though it's possible that the result would not connect. An arithmetic combinator sending "A+1" is convertible to an arithmetic combinator sending "A+2" (replacing its configuration), but not a decider combinator (incompatible configuration). When this placement is allowed, its preview should be tinted yellow to indicate that it would require existing ghosts to be deleted or built entities to be flagged for deconstruction rather than just for upgrade.
• replace conflicting - Place a new entity over one with a totally different type, or the same type but different (but overlapping) positions. Previews of this case are usually tinted red to indicate that placement is not allowed, but may be tinted yellow if the placement is allowed but would cause removal of existing entities (deletion of ghosts, flag for deconstruction of built entities).

Why ?

Direct entity placement is currently very smooth and intuitive: you can build different variations of inserters, belts, pipes, poles, assemblers, etc directly on top of existing ones (i.e. red belt on existing yellow belt, blue inserter on existing yellow inserter, etc), even loosely out-of-type in some cases (i.e. red belt on existing yellow underground, red splitter on existing yellow belt but only in the same orientation).

Ghost-mode and blueprint placement, however, is significantly more clumsy and counter intuitive. You can't ghost-build (or place a blueprint of) a red belt on top of an existing yellow underground, or on top of an existing yellow belt, or even on top of the ghost of a yellow belt; in fact, you can't even ghost-build a yellow belt on top of the *ghost* of a yellow belt in order to change its orientation. This restrictiveness is supremely irritating and a common pain point for many players as they gain mastery of the game and move into using ghosts and blueprints, as evidenced by the many times these same features have been requested in the past going back over three years.

The goal of this thread is to refine the comments from those earlier threads into a comprehensive proposal that would vastly improve quality of life for ghost mode, copy-paste and blueprint usage, without introducing unexpected behavior that might disrupt existing workflows.

Further thoughts below, hidden to avoid scaring folks with too many words

About placing new ghosts (by hand, or by paste, or by blueprint) over existing ghosts:

Since the new and old ghosts have the same level of (im)permanence, the most common mode of interaction should closely match what is allowed when directly building, such as placing a splitter onto an existing belt or upgrading an assembler while retaining its recipe and modules. Note however that for ghost-mode building, the most common mode of interaction is when holding the SHIFT key, since getting a ghost in hand without SHIFT is only possible when enabling the "ghost in hand for missing item" game option and also not having any of the item; this implies that we can make the SHIFT mode of building over ghosts more permissive (convert compatible) to match direct building, while leaving the no-modifier-key behavior (more commonly used when placing blueprints) slightly more conservative (only upgrade similar). Note that the current behavior is really unnecessarily strict: even exact matches (i.e. eastbound yellow belt ghost over eastbound yellow belt ghost) are tinted red and disallowed, even though they'd be a total no-op.

The CTRL+SHIFT modifier is added as a more extreme force-build option, similar to direct building over a ghost (which will delete the ghost no matter what it is); when placing blueprints, this mode would be especially useful in cases such as when an earlier tier of the blueprint had extra yellow undergrounds to cross a 6-wide space, but a later tier has upgraded to red and now has room to place a new building in the space where those intermediate yellow undergrounds used to be.

In all cases, exact matches should be tinted blue in the preview to indicate no change, similar upgrades should be tinted green, and any entity overlaps that are not currently allowed (splitter vs belt when not holding SHIFT; machine vs belt when not holding CTRL+SHIFT) should be tinted red to indicate that they are preventing placement. With modifier keys, some red tints would turn yellow: convert compatible (i.e. belt to splitter) when holding SHIFT, and any other conflict replacement when holding CTRL+SHIFT.

About placing new ghosts (by hand, or by paste, or by blueprint) over existing built entities:

These interactions should be more conservative, since (unlike building over ghosts) they may potentially cause functional changes or disruptions to a running factory. The default (no modifier key) behavior is therefore left unchanged: only add new entities and only allow overlaps with exact matches.

Holding SHIFT already allows for removal of conflicting trees and cliffs, but is expanded to also upgrade similar entities in exactly the way the upgrade planner does. This is still quite a safe behavior since these types of upgrades cannot change the function or behavior of the factory except to make it run faster or slower or use more or less power or resources, and this reasoning is also the motivation for the exception to what is considered a similar upgrade vs a compatible conversion in the case of underground belts: upgrading from yellow to red to blue undergrounds is an upgrade because the result is guaranteed to still connect, but downgrading is a conversion because it might not.

But even when building over an existing part of the factory, there are times when you really want your new blueprint to be able to change what's already there rather than only add to it, without having to note the conflicts, clear the cursor, go manually remove the offending entities, grab the blueprint again, discover you missed one, and so on. For this we again have the CTRL+SHIFT override, which will apply "flag for upgrade" wherever possible, but will resort to "flag for deconstruction" (exactly like the deconstruction planner) wherever necessary to make room for putting down the new ghosts. It's a bold move, but that's why it's behind an extra modifier key, and why even then the overlaps in question don't turn green in the preview, but turn yellow (from red) to catch the eye and make clear that this placement will result in some things being flagged for removal.

And... that's all I guess. Discuss!

[NotRexButCaesar]

Sounds nice, but it probably won't be added: very similar things have been suggested in the past(I'm sure ssilk will add some links in a little while)

[ssilk]

Pffffffff. I respect the details and completeness in this suggestion, but as moderator I would like to help.
First I recommend reading the sticky threads; how to write good suggestions. Because this one is too long and too detailed. I try to explain, taleden: you are not implementing this. If this would be a chair you want to have built from a carpenter, you describe how to hold him the saw.
Another thing: you try to solve a very complex subject by mixing three different suggestions. Try to separate the problems into small and simple suggestions.

And AmericanPatriot said it already: lots of other suggestions.

viewtopic.php?f=6&t=59554 Hotkey to replace existing structures with blueprint
viewtopic.php?f=6&t=88691 Better Blueprint Placement
viewtopic.php?f=6&t=84697 Better UX for placing, removing, and configuring ghost structures
viewtopic.php?f=6&t=80563 mark-for-upgrading when blueprinting over fast-replaceable entities
viewtopic.php?f=6&t=47993 Allow Fast Replace using blueprints

Similar discussions:
viewtopic.php?f=6&t=83149 [UPD] Rail planner is practically broken around your base

And my current opinion about that is this: all the suggestions show that there is an issue. They describe different solutions. The implementation is not in our hands and in this case I would like wube to choose one or the ones they like to implement.

[taleden]

I realize that my attempt at a thorough explanation of the suggestion got a little wordy, but I don't think it's that complicated when you break it down into its component pieces -- all it comes down to is recognizing the four levels of similarity/difference between what the player is trying to place vs what's already there, and offering a few reasonable options (using modifier keys like SHIFT, which are already used this way) for which levels to allow/handle (just like is already done for trees). That's all.

I also disagree that it's mixing different suggestions; the unifying principle is that right now, ghost placement behaves differently than direct building in ways that are awkward and counter intuitive, and there doesn't seem to be any good reason for that other than nobody's ever bothered to go back and make ghost building as slick and easy as direct building now is. But this seems like a good time to bring it up again, since 1.1 seems to be all about QoL improvements, many of which relate to (in my view) much smaller and less noticeable edge cases than ghost/blueprint placement, which is something almost every player deals with quite frequently.

There are even a few aspects of the current behavior that verge on being bugs, or at least very surprising. For example, if you copy a factory and go to paste it over another existing factory, the preview will be blue as if it's an exact match and so pasting will have no effect. And yet if you click to paste anyway, it will cause the existing factory to change its recipe to match what you copied. This can get even more troublesome with things like combinators; if you pull up a big blueprint to check it against what you have built, it may look like a match (all blue) even if some combinator logic differs, and pasting will overwrite all that combinator logic without warning.

I have also read all of the prior threads you linked -- in fact if you notice, I also linked them in my post -- and I cite them as evidence that these issues have been bugging a number of folks for quite some time (over three years since the oldest of them). But one thing I noticed in those threads is that they tended to devolve either into folks objecting to the deconstruct behavior as a default (because of course you don't always want that), or else folks getting into complicated changes to blueprints themselves (extra layers, extra settings, etc), or folks just misunderstanding what was being suggested

So my goal with this thread was to sketch out a logically consistent and straightforward way to smooth out all the interactions related to ghost placement without significantly changing default behaviors and without requiring any changes to blueprints themselves. In fact, all of the functionality to implement this scheme already exists: the deconstruction planner can already flag things for removal, and new ghosts can be placed over flagged entities before they're even removed; the upgrade planner can already flag things for replacement, and the new entity will inherit any configuration from the old; the blueprint placement process already scans tile-by-tile for conflicts to tint them red and block the placement; and blueprint placement can already check for SHIFT, turn certain conflicts (i.e. trees) from red to green and flag them for deconstruction before placing. So all that's required is to perform those conflict tests with a little more granularity (four possibilities -- matching, upgradable, convertible, conflicting -- rather than only matching and conflicting) and, if SHIFT and/or CTRL are pressed, invoke the flags for upgrade or deconstruction as needed.

[ssilk]

Well, let me say it so: as moderator, which wants to bring up as many suggestions into the game I love, I like the completeness of this suggestion. I don’t like the length, because the devs tend to ignore those wall-of-text-posts. It could be expressed much with less words. That’s my concerns with this suggestion.

[taleden]

I've edited to more closely conform to your preferred template, and to hide the clarifying discussions from folks who are afraid of words. As is hopefully clearer at a glance now, the meat of the proposal is really not long or complicated; all the clarifying definitions and examples were only intended to avoid some of the confusion and misunderstandings that I saw derail earlier threads on this subject.

[ssilk]

Looks much better now.

[swindle]

I wish there was a Kickstarter campaign to finance this feature - either as a native feature or to develop a mod. I'd be willing to chip in.

[Hares]

I hope these changes will be implemented in 2.0 since it already has a bunch of QoL changes, some related to the ghosts.