Weird visual anomaly in GZDoom when testing maps

Does anyone know what causes this visual anomaly (that's the sky box below)? It's not a missing texture and the shape does not correspond to a sector, it's a piece of a sector (it does not cross sectors). It's not visible in the visual mode of GZDoombuilder and I can get rid of them if I shift the sector slightly or draw a line through it. This often "moves" the anomaly to pop up somewhere else close. They only seem to appear in rooms with lots of linesdefs/sectors. I have had them happen at some point on every level I've worked on so far. My guess is that it has something to do with the nodebuilder (ZDBSP) or is a rendering issue with GZDoom itself. Any help is much appreciated.

Yeah, blame the node builder but there's a solution. You said that you use GZDB, so....

Press F4 to popup the map analysis window and search for off-grid vertices. If you find one or many, fix them right away...

These triangular sectors that shouldn't really be there can also occur when you drag a sector around in ways you shouldn't, in which case it can also help to spam some "make sector" actions in, basically, any builder you use. That might get rid of this "artifact" as well, provided it is what I think it might be. Also worth pointing out that, when this really happens in every map you made up to this point, and your vertices are set to "snap to grid" to begin with (which honestly it should be anyway as far as I'm concerned), you're probably doing something "wrong", or much rather in ways the nodebuilder isn't able/meant to handle.

For example: If you draw "sector X" within "sector A", and then move "sector X" into "sector B" (instead of copy+paste), you are likely to get similar issues than the one that shows up on your screenshot. It's not a nodebuilder "bug" in this case, it's just that the way maps are "written" and "read" in Doom aren't meant to handle "abuse" like that.

EDIT: That stuff can also happen when you drag geometry around in such a way that linedefs, which aren't supposed to cross one another suddenly do so without being connected by a vertice. So, yeah, basically be more careful when dragging geometry around, I'd say.

Its most definitely a node building issue. Also ive noted that opengl ports tend to show little errors like these more than software. Open the node builder view plugin in gzdb and you'll see that triangle as a section of the map that is outside of the sectors covered by the notes. Basically it'll just look like a black triangle against the rainbow assortment of other sectors all around. Much like slime trails, as this is a node-builder issue simply moving a vertex can fix it (or move it as you've noticed). If you want to be rid of them, delete and rebuild the area. And as nih said, try to build stuff more carefully; remember that the newer map editors actually do a lot of actions behind the scenes whenever we even do something basic such as draw one line or one sector, so also not going hog wild with your drawings and giving the node builder a tangled mess will also help to not encounter them as much.

OK I'll search for off grid vertices when I get home from. Cheers @leodoom85

@Dragonflymake sector spam coming up. This is in that area that I've posted elsewhere with 3700 sectors with the mad lighting over laps. So if there is a vertex issue or is likely to be here.

@Fonzethat node builder plugin sound useful if it shows up the glitches like you describe. 

The weird thing is that these anomalies will already in previously completed sectors. I'll be laying down lines in another area and then one of these voids will pop up. 

I try to avoid just dragging scouts into other sectors, I tend to copy paste and then delete the old one but I'll pay more attention to what I am doing. I've had these appear in quite big sectors where there is unlikely to be unconnected vertices. I'll have a look at some of my other maps and check the affected sectors. 

I worked with deepsea for 10 years (even paid for the full version) so I'm fully aware of what 0 length lines and unconnected vertices can do. That was one sensitive programme. At least gzdoombuilder doesn't have a grande mal seizure when it finds something unexpected. An impressive piece of software given that it is free and relatively bug free. 

Thanks for the help guys 🤘

55 minutes ago, Bridgeburner56 said:

The weird thing is that these anomalies will already in previously completed sectors. I'll be laying down lines in another area and then one of these voids will pop up. 

When you add lines it can change the node builder's path elsewhere in the map, which can make them pop up in previously completed areas. This is one reason to just save these types of fixes til the end of map building. But definitely do look into that plugin, as it will show these and likely many more areas that the node builder botches on the regular.

Just now, Fonze said:

 

When you add lines it can change the node builder's path elsewhere in the map, which can make them pop up in previously completed areas. This is one reason to just save these types of fixes til the end of map building. But definitely do look into that plugin, as it will show these and likely many more areas that the node builder botches on the regular.

Good to know. I've allocated a week per map next month to go through and 'proof read' the first 4 levels before I release for play testing. I'll schedule it in then. 

10 hours ago, Fonze said:

...remember that the newer map editors actually do a lot of actions behind the scenes whenever we even do something basic such as draw one line or one sector, so also not going hog wild with your drawings and giving the node builder a tangled mess will also help to not encounter them as much.

Yep. When you draw a line, the editor makes vertices and sidedefs, of course, but it also makes sectors. The way this is done always manages to confuse me at times, because how the editor creates sectors out of lines is not always 100% clearly defined. For example, if a new line splits up a sector, or even multiple sectors, you may expect the editor to split the sectors in two. But, what if you then delete such a line? Will the editor re-join those previously split sectors properly? Or, what if you move the line so that, now, it only splits one of the sectors?

It's when lines intersect, or join at vertices that weird things can occur - situations where the editor cannot possibly know what you are trying to accomplish. It's one of those downsides to having all that automation: It's great when you follow the rules. But when you do something unexpected, anomalies can happen, and yet the map still looks ok in the editor.

I imagine one of the worst scenarios occurs when dragging some geometry on top of other geometry, even if it's just temporary. If the editor tries to be "too smart", it may try to join/split sectors up while the dragging is occurring, which can make a real mess. Deleting lines that are connected to other lines can create these anomalies too.

This is one of the reasons I haven't yet gotten into mapping. I want to understand what and when these anomalies occur, and what needs to be done to fix them. A long time ago, I started modifying a map editor derived from DoomBuilder 1. I quickly realized that these issues can occur. I wanted to get the editor to be able to identify and recognize these issues, and hopefully be able to correct them. But, I'm not sure it's possible. I think it requires the editor to be able to guess the intentions of the map author, for all but the simplest constructs.

Does my description make sense to map authors? Does anyone have any suggestions?

42 minutes ago, kb1 said:

Yep. When you draw a line, the editor makes vertices and sidedefs, of course, but it also makes sectors. The way this is done always manages to confuse me at times, because how the editor creates sectors out of lines is not always 100% clearly defined. For example, if a new line splits up a sector, or even multiple sectors, you may expect the editor to split the sectors in two. But, what if you then delete such a line? Will the editor re-join those previously split sectors properly? Or, what if you move the line so that, now, it only splits one of the sectors?

 

It's when lines intersect, or join at vertices that weird things can occur - situations where the editor cannot possibly know what you are trying to accomplish. It's one of those downsides to having all that automation: It's great when you follow the rules. But when you do something unexpected, anomalies can happen, and yet the map still looks ok in the editor.

 

I imagine one of the worst scenarios occurs when dragging some geometry on top of other geometry, even if it's just temporary. If the editor tries to be "too smart", it may try to join/split sectors up while the dragging is occurring, which can make a real mess. Deleting lines that are connected to other lines can create these anomalies too.

 

This is one of the reasons I haven't yet gotten into mapping. I want to understand what and when these anomalies occur, and what needs to be done to fix them. A long time ago, I started modifying a map editor derived from DoomBuilder 1. I quickly realized that these issues can occur. I wanted to get the editor to be able to identify and recognize these issues, and hopefully be able to correct them. But, I'm not sure it's possible. I think it requires the editor to be able to guess the intentions of the map author, for all but the simplest constructs.

 

Does my description make sense to map authors? Does anyone have any suggestions?

TL:DR...make sector, sometimes the editor fucks you up silently and say "ha-ha look at that", then you say "fuck no, I'm fixing this shit"

40 minutes ago, leodoom85 said:

TL:DR...make sector, sometimes the editor fucks you up silently and say "ha-ha look at that", then you say "fuck no, I'm fixing this shit"

Please take the time to read it (again), because you missed my conclusion and my question. I am thinking that, no, it's not the editor's fault, because, in some situations, the Right Thing to Do is ambiguous, I think. And I wanted to know if experienced mappers agree. And if they have any suggestions on how to improve the editors.

7 minutes ago, kb1 said:

Please take the time to read it (again), because you missed my conclusion and my question. I am thinking that, no, it's not the editor's fault, because, in some situations, the Right Thing to Do is ambiguous, I think. And I wanted to know if experienced mappers agree. And if they have any suggestions on how to improve the editors.

Nope. That's how it is. Editors can behave in weird and unexpected ways and that thing happens often. Yes, mappers can offer suggestions for the editors but that decision falls to the maintainer. And also, there are forks for Doom Builder too for alternatives instead of relying on GZDB...idk if, for example, Doom Builder X does happen that issue or Slade.
And I think that suggestions are done in the right topic, not in here. Personally, I don't have much problem with GZDoom Builder-Bugfix since I'm so used to it that it seems normal to me. Other things can be nitpicky to other people but that's for another discussion.

Every editor has its quirks, you've just got to learn them

1 hour ago, leodoom85 said:

Nope. That's how it is. Editors can behave in weird and unexpected ways and that thing happens often. Yes, mappers can offer suggestions for the editors but that decision falls to the maintainer. And also, there are forks for Doom Builder too for alternatives instead of relying on GZDB...idk if, for example, Doom Builder X does happen that issue or Slade.
And I think that suggestions are done in the right topic, not in here. Personally, I don't have much problem with GZDoom Builder-Bugfix since I'm so used to it that it seems normal to me. Other things can be nitpicky to other people but that's for another discussion.

That's not how it is. Editors only do what they are programmed to do - there's nothing weird about it. Unexpected, maybe, but not weird.

Brainstorming about what may have caused Bridgeburner56's anomaly is certainly on-topic, and may be immediately beneficial. But, I agree that discussing possible fixes should be done in a dedicated thread.

I just really wanted to know if anyone is knowledgeable of the phenomena, especially what may cause it. Because that can go a long way towards preventing it from happening, when all you want to do is finish your map.

When and if I get in a position where I can do something about it, I will create such a thread. But, for now, knowing when the popular editors cause this issue might be helpful to the OP.

4 minutes ago, Bridgeburner56 said:

Every editor has its quirks, you've just got to learn them

Sounds right to me.

I wouldn't consider the editor to be at fault. Imo it does exactly as it should. Keep in mind that modern editors do stuff for mappers automatically like flip 1-sided linedefs to face the inside of a sector created in the void, create new sectors automatically when they are finished forming, as well as split linedefs that cross, etc. There are a lot of functions that the editor does automatically for us, and in all honesty changing any of them would likely create more work for mappers than "bugs" it would solve. Especially since most of the behavior is predictable and consistent.

The best way to prevent it from happening is to know more about what the editor is doing, even if not in programmy terms just know what it has to do when you do this thing x. Basic troubleshooting: do something mindfully and carefully observe the result. On that same thought, wrt stuff like node building, understand that the issue is no longer in the editor's hands. Some editors can display what the node builder is doing, but they cannot change the directions or paths it takes. Only line positioning can change that. 

Something I've noticed when building lots of non-orthogonal stuff is that the node builder will get super confused and leave slivers of nothing a fraction of a pixel wide all over the place, which for the most part causes no issues, possibly just too hard to see from their small size, but which occasionally can be big enough to see in opengl. It's weird to see the node builder just cop out on a line it is basically parallel to and to be so close to it in at the same time, but we have to keep in mind that this is a program that was designed to follow a line to its end, then pick left or right and continue until all lines were accounted for. Adding in crazy angles, detail, and etc should understandably cause some issues and honestly I don't see how that will ever be fixed, but maybe in another 23+ years somebody will figure it out ;D

6 hours ago, Fonze said:

I wouldn't consider the editor to be at fault. Imo it does exactly as it should. Keep in mind that modern editors do stuff for mappers automatically like flip 1-sided linedefs to face the inside of a sector created in the void, create new sectors automatically when they are finished forming, as well as split linedefs that cross, etc. There are a lot of functions that the editor does automatically for us, and in all honesty changing any of them would likely create more work for mappers than "bugs" it would solve. Especially since most of the behavior is predictable and consistent.

 

The best way to prevent it from happening is to know more about what the editor is doing, even if not in programmy terms just know what it has to do when you do this thing x. Basic troubleshooting: do something mindfully and carefully observe the result. On that same thought, wrt stuff like node building, understand that the issue is no longer in the editor's hands. Some editors can display what the node builder is doing, but they cannot change the directions or paths it takes. Only line positioning can change that. 

Interesting. I guess you get to know what the editor is doing, behind the scenes, from experience. I would never suggest reducing that assistance - I am just wondering if it can be made to also handle some of the more unusual situations with grace.

6 hours ago, Fonze said:

Something I've noticed when building lots of non-orthogonal stuff is that the node builder will get super confused and leave slivers of nothing a fraction of a pixel wide all over the place, which for the most part causes no issues, possibly just too hard to see from their small size, but which occasionally can be big enough to see in opengl. It's weird to see the node builder just cop out on a line it is basically parallel to and to be so close to it in at the same time, but we have to keep in mind that this is a program that was designed to follow a line to its end, then pick left or right and continue until all lines were accounted for. Adding in crazy angles, detail, and etc should understandably cause some issues and honestly I don't see how that will ever be fixed, but maybe in another 23+ years somebody will figure it out ;D

You hit the nail on the head when you describe the "fraction of a pixel." When the nodebuilder has to split an orthogonal line, the intersection point is always on integer coordinates. But, for a diagonal line, both the X and the Y intersection can be off as much as 1/2 unit. And, if the rounding code is not rounding to nearest, it can be off just below a whole unit, in both X and Y. This causes slime-trails, and other inaccuracies.

I think ZDoom's advanced node format stores fractional coordinates, which nearly eliminates this issue. But only ZDoom ports can currently handle these nodes, I think.

31 minutes ago, kb1 said:

I think ZDoom's advanced node format stores fractional coordinates, which nearly eliminates this issue. But only ZDoom ports can currently handle these nodes, I think.

As well as PrBoom+, Eternity, Crispy, Retro, and probably 3DGE. Perhaps also Risen3D but I'm not sure about that one.

2 hours ago, Gez said:

As well as PrBoom+, Eternity, Crispy, Retro, and probably 3DGE. Perhaps also Risen3D but I'm not sure about that one.

These ports can load nodes containing non-integer coordinates? Damn, I've been living under a rock...

Sweet. I got to gets me some of that.

8 hours ago, kb1 said:

Interesting. I guess you get to know what the editor is doing, behind the scenes, from experience. I would never suggest reducing that assistance - I am just wondering if it can be made to also handle some of the more unusual situations with grace.

Creating maps is quite a technical process, and IMO it's OK that it's expected that the user has some understanding on the inner workings of the map format/engine. You can't really make editors foo proof, because the user might want to intentionally "fuck up" to achieve certain mapping tricks, like self-referencing sectors.

What "unusual situations" are you thinking of? Yes, dragging existing geometry over each other doesn't end well, but the question is if doing that better is worth the effort. It's basically "don't try stupid shit and you'll be fine". Obviously the definition of "stupid shit" can differ vastly, I consider trying to drag geometry over each other as "stupid shit", others might want to expect it to work flawlessly.

On 5/26/2018 at 3:45 AM, boris said:

Creating maps is quite a technical process, and IMO it's OK that it's expected that the user has some understanding on the inner workings of the map format/engine. You can't really make editors foo proof, because the user might want to intentionally "fuck up" to achieve certain mapping tricks, like self-referencing sectors.

 

What "unusual situations" are you thinking of? Yes, dragging existing geometry over each other doesn't end well, but the question is if doing that better is worth the effort. It's basically "don't try stupid shit and you'll be fine". Obviously the definition of "stupid shit" can differ vastly, I consider trying to drag geometry over each other as "stupid shit", others might want to expect it to work flawlessly.

It breaks my law of user interfaces, where, if something is allowed, it should either work, or warn you, or look different, or something. Instead, the interface looks and works exactly the same, whether or not things are ok, or your map's being mauled. The editor knows when it's messing up a map, or, at least, it easily could be made to know.

It could do a lot of things: Pop-up an annoying message: "You're doing some stupid shit. Is this ok? [Ok] [Cancel]". Or, the lines could change a different color, indicating that their attached sector is no longer trusted/accurate. Or, it could disallow the move. Something, anything, other than "everything's cool.". In other words, you should know something's wrong, before testing the map in a port. The map edit view should be trustable, in all situations. There should be a 1-to-1 relationship between what's in the editor, and what shows in the game. At least, that's how I build my GUIs - which can be quite difficult, but worth it in the long run.

You ask: "What unusual situations?" I don't know. Apparently, it's not easy to know, which is the problem. But, really, I haven't made enough maps to begin to know what might cause these types of errors. But, I keep hearing about them. I was hoping some others might know.

I'm sure theres a cause and/or reason that little glitch is there. The editor might not be able to tell you what that is, but I'm sure its there.

I think you're asking for the editor to be able to capture every error you could possibly put into a map. This is just not going to happen. GZDB is fairly new to me, and I have noticed already some quirks about dragging and merging lines and verts...things a mapper should just avoid. This is a sweet editor, and compared to the old crap I was used to years ago ( wad author ) GZDB is AWESOME. I remember having backups of backups while editing, because one wrong mouse click in the editor and POOF the whole map is ruined, un-fixable. I'm yet to see anything close to that happen in GZDB. The worst I did ( yes me, not the editor ) was a line merge that made two sectors change reference numbers. Easy fix, but if a new-ish mapper had that happen, they might not know how to fix it.

GL rendering opens a whole new can of worms in Doom maps. This method of rendering was not intended ( didn't exist ) when this format was made. We have to expect some oddities once in a while.

Idk that I can agree with that kb1; what then constitutes a stupid move? In older editors, drawing (I may be misremembering the direction, but specific direction isn't important) counterclockwise sectors in the void created lines with no front sidedef, facing outside the drawn sector, while clockwise would properly create lines facing inside the sector. Older editors also didnt make those drawn shapes into "sectors" automatically just by closing them. It would be a ton of extra work for the maintainer to make warning/info messages on every little thing it does to help us stupid humans along, plus determining the cut-off point or line in the sand to draw on what gets a message and what doesn't will prove equally fruitless as most people will just turn them off the moment they display a message that the mapper already knows. Also error messages will likely make the typical, stupid user blame the program being used for their own mistakes in this case (mapping in general).

Personally, I think that some things are just the mapper's responsibility; it has been that way since the first editors and newer ones have mostly only streamlined tedious processes and added QoL features. 

It is also worth noting that certain actions, such as changing map formats, already have warning messages that basically say "think about what you're doing; don't be an idiot," heh. 

I also think you're assuming a bit too many errors and such are occurring; as a mapper I would say that the current editors are extremely reliable at displaying what is going on; the most unreliable things to check in-editor are related to node-building, which given the node-builder plugin is also mostly covered. I guess it would be cool if the editor did show stuff like slime trails or other visual bugs in 3d mode, but idk how that would work and in a way it's good that it just displays the map exactly as it is built with no port or node-builder attached, as those can change over time anyway.

Honestly it would probably work out better for the maintainers of editors to just gather all the info on stuff and write a book for nobody to read because well, nobody reads stuff that isn't a forum post.

Next time we chat we can talk about this more; text takes forever, heh. :)

1 hour ago, kdoom said:

I'm sure theres a cause and/or reason that little glitch is there. The editor might not be able to tell you what that is, but I'm sure its there.

 

I think you're asking for the editor to be able to capture every error you could possibly put into a map. This is just not going to happen. GZDB is fairly new to me, and I have noticed already some quirks about dragging and merging lines and verts...things a mapper should just avoid. This is a sweet editor, and compared to the old crap I was used to years ago ( wad author ) GZDB is AWESOME...

I fully agree - GZDB, and the other flavors of DB2 are very awesome, capable map editors. The issue I see is that these errors are neither the mapper's, nor the editor's fault, per se. Instead, they are arbitrary situations. These are ambiguous situations, where the Right Thing To Do is unclear. For example, it's possible to drag a few sectors partially over other sectors. Some would call this a "stupid move", and, maybe it is. You see, it's possible for the editor to "fix up" all those overlayed lines, and automatically split them across line intersections, and reform new sectors out of the new spaces created by this move.

So, lets say the editor did, in fact do this. Now, what if you had only moved those sectors and lines on top of the other sectors temporarily, and you were really meaning to move them to a new space. But, now, the editor has broken it up, and auto-joined the moving block, into the sectors under it. Should the editor then unbreak those lines, and put the underneath sectors back the way they were? Can it? Also, can it "un-join" the section being moved, until it arrives at the final destination? (Sorry, I know this is a confusing scenario - it's difficult to type up, anyway.)

That's what I mean by "arbitrary, ambiguous moves", where it is unclear what the editor does. I think, now, it doesn't do much of anything, so you can end up with overlapping sectors unintentionally - sectors that were completely fine before the move, and the human has no idea that the editor is not fixing everything like it normally does.

The editor could totally detect these situations, but, again, what to do about it is ambiguous. If I had to guess, I think these are most of the "stupid moves":

• Dragging and dropping sectors partially over other sectors.
• Pulling lines off of, or deleting lines that make up part of a sector.

Now, the editor could disallow such things, and could do this visually...like render the pulled lines with a superimposed wavy red line, and a tooltip saying you're not allowed to dump these lines on top of existing stuff. The editor would render the moved lines this way, until you moved the cursor to a place that won't break sectors. And, maybe it'll let you do it anyway, but, at least, you'd know what was happening.

Another option: (don't know if GZDB or others implement this or not) A "tear-away" tool would let you cut away a bunch of selected sectors cleanly, by only selecting whole sectors, and automatically patching up the holes with 1S lines. The torn selection could then be dropped to a safe place, and moved around with the mouse or keyboard, until deselected.

Anyway, I'm not trying to criticize these editors - they are fascinating, massively powerful tools. I've just read about and heard about some anomalies that happen every now and then, and I was curious to know if someone knew about them, and knew what exactly caused them. I didn't mean to derail the thread.

1 hour ago, Fonze said:

Idk that I can agree with that kb1; what then constitutes a stupid move? In older editors, drawing (I may be misremembering the direction, but specific direction isn't important) counterclockwise sectors in the void created lines with no front sidedef, facing outside the drawn sector, while clockwise would properly create lines facing inside the sector. Older editors also didnt make those drawn shapes into "sectors" automatically just by closing them. It would be a ton of extra work for the maintainer to make warning/info messages on every little thing it does to help us stupid humans along, plus determining the cut-off point or line in the sand to draw on what gets a message and what doesn't will prove equally fruitless as most people will just turn them off the moment they display a message that the mapper already knows. Also error messages will likely make the typical, stupid user blame the program being used for their own mistakes in this case (mapping in general)...

Agree. Message boxes suck, and are annoying and typically ignored.

1 hour ago, Fonze said:

...(good advice)...

1 hour ago, Fonze said:

Next time we chat we can talk about this more; text takes forever, heh. :)

Text does take forever. Sounds good.

2 hours ago, Fonze said:

 In older editors, drawing (I may be misremembering the direction, but specific direction isn't important) counterclockwise sectors in the void created lines with no front sidedef, facing outside the drawn sector, while clockwise would properly create lines facing inside the sector. Older editors also didnt make those drawn shapes into "sectors" automatically just by closing them.

DeePsea. I made an entire map without realising that the direction you drew in mattered. Yeesh

22 minutes ago, Bridgeburner56 said:

DeePsea. I made an entire map without realising that the direction you drew in mattered. Yeesh

Wow! Yeah, I think DoomBuilder 1 worked that way too. Looks like it didn't stop you - you've come a long way!

1 hour ago, kb1 said:

I fully agree - GZDB, and the other flavors of DB2 are very awesome, capable map editors. The issue I see is that these errors are neither the mapper's, nor the editor's fault, per se. Instead, they are arbitrary situations. These are ambiguous situations, where the Right Thing To Do is unclear. For example, it's possible to drag a few sectors partially over other sectors. Some would call this a "stupid move", and, maybe it is. You see, it's possible for the editor to "fix up" all those overlayed lines, and automatically split them across line intersections, and reform new sectors out of the new spaces created by this move.

 

So, lets say the editor did, in fact do this. Now, what if you had only moved those sectors and lines on top of the other sectors temporarily, and you were really meaning to move them to a new space. But, now, the editor has broken it up, and auto-joined the moving block, into the sectors under it. Should the editor then unbreak those lines, and put the underneath sectors back the way they were? Can it? Also, can it "un-join" the section being moved, until it arrives at the final destination? (Sorry, I know this is a confusing scenario - it's difficult to type up, anyway.)

Ok I will actually type up a bit more, starting with addressing this. Part of this issue can be solved already by turning off the "merge geometry" button. This will allow you to drag stuff anywhere without the editor merging stuff, but obviously doing so will create many more problems, likely also worse than arbitrarily doing so with merge geometry on. You can also "cut" selections out which can then be pasted anywhere else later easily. 

If these sectors have lines attached to anything else though, mappers get a pretty big visual clue that stuff is going badly as they drag selections around and connected lines stretch, move, and overlap.

The editors cannot disjoin a sector in the scenario you describe though, truthfully there is no sane way to do so, apart from the undo button. However there is also a tab that displays all actions taken, working effectively as a giant undo list; you can do all that stuff, copy what you want, then undo everything in one click, and finally paste your new piece back into existence wherever you want. For pasting rules, there are a few users can choose from, and users can also choose whether lines only or lines and sectors get pasted based on what they selected. Vertices can also be cut/copy/paste'd and will have less issues than sectors and lines in certain situations.

You can also manually use the "create new sectors" mode to disjoin previously joined sectors, then go from there.

1 hour ago, kb1 said:

That's what I mean by "arbitrary, ambiguous moves", where it is unclear what the editor does. I think, now, it doesn't do much of anything, so you can end up with overlapping sectors unintentionally - sectors that were completely fine before the move, and the human has no idea that the editor is not fixing everything like it normally does.

Your wording makes it sound as if you believe that the editor does random stuff that is not replicable. Aside from node-building issues, which even they are probably replicable, every behavior can be repeated and tested under controlled (the same) conditions. What it normally does is what it always does; modern editors don't even have the nasty crashes db2 had, and even those were mostly if not totally replicable.

1 hour ago, kb1 said:

 The editor could totally detect these situations, but, again, what to do about it is ambiguous. If I had to guess, I think these are most of the "stupid moves":

• Dragging and dropping sectors partially over other sectors.
• Pulling lines off of, or deleting lines that make up part of a sector.

Now, the editor could disallow such things, and could do this visually...like render the pulled lines with a superimposed wavy red line, and a tooltip saying you're not allowed to dump these lines on top of existing stuff. The editor would render the moved lines this way, until you moved the cursor to a place that won't break sectors. And, maybe it'll let you do it anyway, but, at least, you'd know what was happening.

For the second bullet, that is already animated as the mapper drags stuff around and deleting a line makes the sector's flat turn black. I suppose there are no words saying "hey, this can mess stuff up," but one time of doing so is enough for most people to see what they just did, which will be extremely evident not only in the normal view, but especially in 3d mode. This, of course, is easily undone and no harm no foul. We're lucky the editor even fixes sector references in this case and far luckier that this doesn't crash the editor in all honesty. Neither of these bullets need any ui explanation as the mapper drags stuff because it's all visualized already and seeing the results are instantaneous and clear.

1 hour ago, kb1 said:

Another option: (don't know if GZDB or others implement this or not) A "tear-away" tool would let you cut away a bunch of selected sectors cleanly, by only selecting whole sectors, and automatically patching up the holes with 1S lines. The torn selection could then be dropped to a safe place, and moved around with the mouse or keyboard, until deselected.

This is the "cut" feature. 

Don't get me wrong though, there are still some weird tid bits here and there, (like copy+paste'ing certain things under the right[wrong] circumstances, and creating sectors inside->outside through the curve linedef feature) but modern map editors have come extremely far and as you said, are fascinating, massively powerful tools. I think the fact that new mappers can just pick up the editors and go without too much more than learning how to make a basic door and a switch, (since making rooms/areas is impossible to not do under the stock settings) ending with a real, working, finished map, as well as the fact that zdoom-isms are a real thing, most typically for newer mappers to boot, is enough of a testament to how far editors have come. 

Hopefully I've been helpful :)

19 hours ago, Fonze said:

(merge geometry, "cut" function, undo, and paste)

Ok, so basically all the tools are there to avoid causing issues - it comes with experience.

19 hours ago, Fonze said:

 

Your wording makes it sound as if you believe that the editor does random stuff that is not replicable. Aside from node-building issues, which even they are probably replicable, every behavior can be repeated and tested under controlled (the same) conditions. What it normally does is what it always does; modern editors don't even have the nasty crashes db2 had, and even those were mostly if not totally replicable.

No, you misunderstand me. I am sure that everything the editor does is as built, and can be repeated. (I knew this would be difficult for me to explain.) I was describing those few situations where it is unclear what the editor should do with the human's actions (because the human did a "stupid move"), and I believe it is these times when the map ends up in a slightly broken state. The editor cannot fix every situation in a way that makes sense towards the goal of having a playable Doom map.

19 hours ago, Fonze said:

For the second bullet, that is already animated as the mapper drags stuff around and deleting a line makes the sector's flat turn black. I suppose there are no words saying "hey, this can mess stuff up," but one time of doing so is enough for most people to see what they just did, which will be extremely evident not only in the normal view, but especially in 3d mode. This, of course, is easily undone and no harm no foul. We're lucky the editor even fixes sector references in this case and far luckier that this doesn't crash the editor in all honesty. Neither of these bullets need any ui explanation as the mapper drags stuff because it's all visualized already and seeing the results are instantaneous and clear.

If the UI makes it obvious when something goes wrong, like a broken sector, that's all I was looking for. But it does make me wonder how maps sometimes play funky, even when they look ok in the editor.

19 hours ago, Fonze said:

This is the "cut" feature. 

 

Don't get me wrong though, there are still some weird tid bits here and there, (like copy+paste'ing certain things under the right[wrong] circumstances, and creating sectors inside->outside through the curve linedef feature) but modern map editors have come extremely far and as you said, are fascinating, massively powerful tools. I think the fact that new mappers can just pick up the editors and go without too much more than learning how to make a basic door and a switch, (since making rooms/areas is impossible to not do under the stock settings) ending with a real, working, finished map, as well as the fact that zdoom-isms are a real thing, most typically for newer mappers to boot, is enough of a testament to how far editors have come. 

 

Hopefully I've been helpful :)

Yes, you were helpful. I'm going to have to get more mapping experience, and see if I can answer my own questions. I'm sure that experienced mappers can use the tools to avoid anomalous situations. Every now and then, I read a post that makes me question if these situations exist, and what causes them, but, apparently they are much less prevalent than I first thought.