Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Moderator: ickputzdirwech
Don't add undergrounds when click-dragging belts across structures marked for deconstruction
As I'm sure many of us do, I am enjoying the click-drag automatic placement of undergrounds tremendously. This is a great feature!
However...
I have observed that when click-dragging a belt across deconstruction marked entities, undergrounds are placed. This is not ideal, and can be annoying when adjusting belt placement. Thanks!
However...
I have observed that when click-dragging a belt across deconstruction marked entities, undergrounds are placed. This is not ideal, and can be annoying when adjusting belt placement. Thanks!
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Hm. I can think of many ways, how to solve this problem. What is the right behavior in your opinion?
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
How? Those entities are just marked to deconstruction, you can't place belts there yet.
Ghost belts work, though. Try to
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
The simplest solution that is clearly better than the status quo is: do everything the same except don't place the undergrounds. As it is, I have to remove undergrounds and fill some gaps in the belts to get the outcome I originally wanted. This way, I only fill some gaps in the belts.
If I drag a belt north to south over this deconstruction marked belt: This is what I get: This is what I want:
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Sorry, this is in my eyes not a good behavior and would end as bug-report.
(Btw: I thought at first making this suggestion to a bug-report, but it isn’t clearly a bug.)
When I can add my opinion: it would await, that in any case the belt is drawn as going through the destructed parts.
If player is in reach and enough space left: remove the items in the way automatically.
Not near enough/no space: drawn as ghost over the destructed parts.
(Btw: I thought at first making this suggestion to a bug-report, but it isn’t clearly a bug.)
When I can add my opinion: it would await, that in any case the belt is drawn as going through the destructed parts.
If player is in reach and enough space left: remove the items in the way automatically.
Not near enough/no space: drawn as ghost over the destructed parts.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Hard to wrap my head around why what I get is not a bug, while what I want is a bug. If it had been that way originally, you think it would get bug reports, while this doesn't?
Another option would be to place ghosts over the deconstruction marked structures.
Another option would be to place ghosts over the deconstruction marked structures.
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
A bug is, when a program does things, that it shouldn’t, or doesn’t things, that it should.
Current behavior: not a bug. It operates, as it was planned by the devs. You draw a line of belts and it connects it. It’s not perfect, yes, but it works.
Your suggestion: player draws a line, but it leaves a gap. Not doing, what it should, unexpected behavior. Bug.
Or see it from that perspective: If I draw a line of belts and not everything is connected and you don’t see it, because of trees in the way for example, it would create very big frustration.
Yes. See my last sentence. You can do that in any case, but I found it more practical, to remove the destructed items, if you are near enough and have space left in your inventory.Another option would be to place ghosts over the deconstruction marked structures.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
The simplest solution is (as others have noted) to shift-drag instead of click-drag, and you get what you're aiming for. Presumably you already have bots if you're marking items for deconstruction.causa-sui wrote: ↑Sat Feb 13, 2021 11:49 pm The simplest solution that is clearly better than the status quo is: do everything the same except don't place the undergrounds. As it is, I have to remove undergrounds and fill some gaps in the belts to get the outcome I originally wanted. This way, I only fill some gaps in the belts.
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
This swings on what one "expects" and it's why I don't like this definition of a bug. I expect the other behavior vs what you seem to expect. Anyway, I never suggested that this was a bug, so that is an academic discussion.
I would not recommend that unless the trees are marked for deconstruction.Or see it from that perspective: If I draw a line of belts and not everything is connected and you don’t see it, because of trees in the way for example, it would create very big frustration.
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Undergrounds may look ugly after deconstruction, but they are functional. Gaps aren't functional, they don't work unless you fix them later. That's why I think that current behavior is better than suggested one.
And you have a workaround: just hold shift while routing belts through the area marked for deconstruction. No gaps, no undergrounds.
Auto-switch to ghost mode while placing entities over entities marked for deconstruction looks more promising. But the placement logic is already insanely complex, I doubt that devs want to change it again and open a new can of bugs and corner cases...
And you have a workaround: just hold shift while routing belts through the area marked for deconstruction. No gaps, no undergrounds.
Auto-switch to ghost mode while placing entities over entities marked for deconstruction looks more promising. But the placement logic is already insanely complex, I doubt that devs want to change it again and open a new can of bugs and corner cases...
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
Ok, let me say it so: It has nothing to do, how I define a bug, if a player thinks, that something is unexpected.
No, I mean you are routing a belt through a forest, but you have removed a path of trees already; small path, but clear. And you have overseen a small rock or piece of lake, because it was hidden by a tree.I would not recommend that unless the trees are marked for deconstruction.Or see it from that perspective: If I draw a line of belts and not everything is connected and you don’t see it, because of trees in the way for example, it would create very big frustration.
Cool suggestion: Eatable MOUSE-pointers.
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Have you used the Advanced Search today?
Need help, question? FAQ - Wiki - Forum help
I still like small signatures...
Re: Don't add undergrounds when click-dragging belts across structures marked for deconstruction
You should get undergrounds then, because the obstruction is not marked for deconstruction already.