Annoying things about Doom editing

[scifista42]

If you think that random selection of the prevailing sector upon deleting a linedef between 2 sectors is so much of a problem (even though random selection of the prevailing linedef upon deleting a vertice between 2 linedefs isn't), what about a deterministic selection, for example always choose the bigger sector, or the sector on the linedef's front side? If the mapper wanted the other sector to prevail, he'd still have just-a-tiny-bit-more-complicated ways to achieve it. Or what about making the Delete button have no effect at all when used on linedefs between different sectors? The main purpose would be fulfilled - mappers wouldn't accidentally create unclosed sectors anymore - so the sentence "remember merging sectors before deleting linedefs" wouldn't be needed in tutorials either - linedefs between different sectors would be impossible to delete.

[Graf Zahl]

It is a problem because the other sector's properties will get nuked. If you think that trashing some data without asking the user is a good idea, please rethink.

[esselfortium]

scifista42 said:

linedefs between different sectors would be impossible to delete.

But WHY?!

[scifista42]

Graf Zahl said:

It is a problem because the other sector's properties will get nuked. If you think that trashing some data without asking the user is a good idea, please rethink.

The user has already voluntarily pressed the Delete button. He can expect one of the sector's properties to get trashed. What's the problem?

esselfortium said:

But WHY?!

Because deleting linedefs between different sectors by using the Delete button creates unclosed sectors and those are pretty much always bad. My suggestion is that the sectors would have to be joined before the Delete button would even have any effect on the linedefs at all - therefore not doing any accidental harm by either creating unclosed sectors or trashing one sector's properties if the Delete button was pressed on a linedef between different sectors for any reason.

[baja blast rd.]

Sometimes when designing an area, I'll delete a bunch of linedefs between two sectors and then redraw them, if I want to improve on the original shapes. (For example with 'rocks'.) When the linedefs are redrawn, the two sectors will retain their individual properties, just as they would have if I had shifted vertices around. For convenient things like these, the current behavior is very helpful.

[Graf Zahl]

esselfortium said:

But WHY?!

Because the mapping Nazi demands so, it seems.

Be it as it may, rdwpa precisely describes a scenario where auto-merging would create problems.

In the end it's simple - if you want to join some sectors, use a proper tool for that - and do not implicit additional functionality to other tools that go beyond their description. Such design attempts to target the dummies, and that's always a bad decision. Most software designed that way is inflexible and in general a pain to use, because it tries to second-guess its user's habits. Good software won't do that.

[scifista42]

rdwpa said:

Sometimes when designing an area, I'll delete a bunch of linedefs between two sectors and then redraw them, if I want to improve on the original shapes. (For example with 'rocks'.) When the linedefs are redrawn, the two sectors will retain their individual properties, just as they would have if I had shifted vertices around. For convenient things like these, the current behavior is very helpful.

Now this sounds like a good usage of (temporarily) creating unclosed sectors. Still, it's somewhat unintuitive that it could even work, and only useful under very specific circumstances. If you forget that you've created those unclosed sectors, you'll run into problems later - let alone if you aren't even aware that you've created them in the first place. A typical user definitely won't do this often enough that it would hurt to pop up a dialogue window every time he attempts to delete linedefs between different sectors, asking him if he really wants to create unclosed sectors or something with that meaning, making it clear that it's not recommended unless he knows what he's doing.

Graf Zahl said:

Such design attempts to target the dummies, and that's always a bad decision. Most software designed that way is inflexible and in general a pain to use, because it tries to second-guess its user's habits. Good software won't do that.

Good software would be easy to use for dummies as well as for pros, and flexible to accustome to anyone's habits. Either way, the software's default behavior would prevent the user from making typical easy-to-make mistakes. Deleting linedefs in expectation that the sectors on their opposite sides will get merged is an easy-to-make mistake in current DB2 and GZDB.

[Graf Zahl]

Wrong. The default behavior should be not to destroy any data. What you propose does.

[MaxED]

There is the "Dissolve Item" (Ctrl-Del) action in GZDB. Guess what it does.

[scifista42]

Graf Zahl said:

Wrong. The default behavior should be not to destroy any data. What you propose does.

When you delete a vertice between 2 linedefs, the linedefs merge, and the properties of one of them are destroyed in favor of the other linedef. Same thing, no problem. Besides, we're talking about Delete function. Its very purpose is to destroy some data. That's what the user wants to do when he uses it.

MaxED said:

There is the "Dissolve Item" (Ctrl-Del) action in GZDB. Guess what it does.

Mentioned earlier in this thread. It exists, but isn't convenient. The problem is that the primary deletion function (the Delete button) causes issues that the mapper didn't want or expect.

[Linguica]

So "dissolve" deletes a linedef + merges the sectors on either side? That's a pretty unintuitive name, but I'm not sure what would be better. "Delete & merge"?

[Graf Zahl]

scifista42 said:

When you delete a vertice between 2 linedefs, the linedefs merge, and the properties of one of them are destroyed in favor of the other linedef. Same thing, no problem.

Not the same thing.

First, with a vertex gone, both lines will miss one end point so there's precisely two options:

1. Delete both lines.
2. Join both lines.

2 is the less destructive one.

But with sectors things are different. First, there's more than one linedef referencing a sector so just joining them would alter all those other linedefs, too, and second, it'd only be acceptable if the deleted linedef was the only one between those two sectors, but as things are, there are far more situations where a linedef just needs to be deleted.
Again, what's being done is the least destructive option.

[scifista42]

It may be the least destructive option technically, but also the least intuitive one, is what I'm saying. You and I have the technical knowledge to know that sector references are mere properties of linedefs, but most mappers think of sectors as of the actual areas of polygonal shapes that have to be fully enclosed by linedefs, because that's what sectors are actually supposed to represent. In that context, it makes more sense to merge sectors if a linedef between them disappears, than to leave both of them in a half-broken state.

[MaxED]

scifista42 said:

It exists, but isn't convenient. The problem is that the primary deletion function (the Delete button) causes issues that the mapper didn't want or expect.

Initially I've replaced "Delete item" behaviour with this one. Guess what feedback I've started getting from the users after that change.

Linguica said:

That's a pretty unintuitive name.

Both name and behaviour were copied from Modo action. In the current version of Modo it's called "Remove". Not sure if that name is more descriptive though...

[scifista42]

MaxED said:

Initially I've replaced "Delete item" behaviour with this one. Guess what feedback I've started getting from the users after that change.

Please explain the reasoning that somebody used to argue how it's bad that way, respectively link to their post if it's publicly available.

[MaxED]

Try lurking around this post, I suppose...

[Graf Zahl]

@scifista:

Why don't you just admit that you didn't think it through?

Altering map data without the user's input is always bad, and that post MaxEd linked to is ample proof for that.

[scifista42]

@MaxEd: The person's issue would have best been solved if the editor automatically called the "Make Sector" action onto the respective parts of the sectors separated by the linedef immediately before deleting the linedef and joining the sectors. Instead, the post remained unaddressed, and in your next comment in the thread, you've introduced the Ctrl+Del action and simply announced that the Delete behavior was reverted to the one that DB2 had and that GZDB still has nowadays. So, I suggest you to reconsider that move, for the sake of making it hard to accidentally create unclosed sectors by mappers who imagine sectors as filled shapes and think that deleting a linedef between them would merge their fillings as if the fillings were liquid - as that's what seems intuitive.

[Graf Zahl]

scifista42 said:

@MaxEd: The person's issue would have best been solved if the editor automatically called the "Make Sector" action onto the respective parts of the sectors separated by the linedef immediately before deleting the linedef and joining the sectors. Instead, the post remained unaddressed, and in your next comment in the thread, you've introduced the Ctrl+Del action and simply announced that the Delete behavior was reverted to the one that DB2 had and that GZDB still has nowadays. So, I suggest you to reconsider that move, for the sake of making it hard to accidentally create unclosed sectors by mappers who imagine sectors as filled shapes and think that deleting a linedef between them would merge their fillings as if the fillings were liquid - as that's what seems intuitive.

No, no, no!

You fail at editing maps, I'd say. It's clear that your 'sane' behavior is considered 'insane' by most other users, so majority wins (and you lose.) The risk of accidentally creating an unclosed sector is disproportionately offset by accidentally screwing up the entire map. Some people here presented legitimate scenarios where auto-joining is not wanted.

[Byeblothingal 1024]

Graf Zahl said:

No, no, no!

You fail at editing maps, I'd say. It's clear that your 'sane' behavior is considered 'insane' by most other users, so majority wins (and you lose.) The risk of accidentally creating an unclosed sector is disproportionately offset by accidentally screwing up the entire map. Some people here presented legitimate scenarios where auto-joining is not wanted.

RIGHT! when you try to run the map with un closed sectors it gives you the "you need to fix these lines to play this map" error. NEVER good to do what R2D2 is talking about.

[scifista42]

Graf Zahl said:

It's clear that your 'sane' behavior is considered 'insane' by most other users, so majority wins (and you lose.)

Who and where is this majority? What are you even talking about?

Graf Zahl said:

Some people here presented legitimate scenarios where auto-joining is not wanted.

But these scenarios are not the typical case of what mappers do. In the typical case, auto-joining is wanted. The Delete button is the primary (easiest) way to delete stuff, so it should be accustomed to do what's desired in the typical case, shouldn't it?

Byeblothingal 1024 said:

RIGHT! when you try to run the map with un closed sectors it gives you the "you need to fix these lines to play this map" error.

For your info, I'm for preventing unclosed sectors from happening, while Graf Zahl is for letting unclosed sectors happen, when the mapper presses Delete on linedefs between different sectors.

[Graf Zahl]

scifista42 said:

For your info, I'm for preventing unclosed sectors from happening, while Graf Zahl is for letting unclosed sectors happen, when the mapper presses Delete on linedefs between different sectors.

As I said, that's a minor issue compared to clobbering entire sectors just because it's n00b-friendly.

[Fonze]

scifista42 said:

Mentioned earlier in this thread. It exists, but isn't convenient. The problem is that the primary deletion function (the Delete button) causes issues that the mapper didn't want or expect.

And it's somehow more convenient to change the code of DB just for this? Personally, I'm used to the current behavior and fully support it, but when the funtion you want is already present, I just have to ask: (controls are remappable here, so) how inconvenient for you is it to remap the controls for your own editor?

One thing about the current behavior I like, when you use the create new sector tool, the place you click determines what sector properties the new sector inherits. This alone makes the deleting of both sectors make sense to me.

[scifista42]

@Graf Zahl: Do you realize that the sectors which the mapper wants to join would almost always have similar or even the exact same properties to each other? And even if they didn't, the mapper would expect one of them to get discarded before even deleting the linedefs, and he would know exactly which one got discarded at least after deleting the linedefs (or even before, depending on implementation) - so if the unintended one got discarded, he'd know instantly and he'd correct it easily. I don't see this as anything comparable to the undoubtly negative effect of unintented unclosed sectors.

EDIT:

Fonze said:

when the funtion you want is already present, I just have to ask: (controls are remappable here, so) how inconvenient for you is it to remap the controls for your own editor?

Bearable, but I'm trying to argue for the benefit of more people than just myself - particularly those whom I've seen making the mistake of uncarefully deleting linedefs unknowingly of the negative consequences.

[MaxED]

"Merge sectors" action does what you are describing. When deleting a linedef there is no way of determining which sector the user wants to stay and which should be consumed.

scifista42 said:

Do you realize that the sectors which the mapper wants to join would almost always have similar or even the exact same properties to each other?

And of course you have queried all GZDB users and have the statistics at hand.

scifista42 said:

I'm trying to argue for the benefit of more people than just myself.

There's a thing I've learned while developing GZDB: when a user asks for a feature/change he personally won't use, but the other mappers will benefit from, there's a 99% chance that nobody ever would use such feature.

Back in the day I was considered to be worse than Hitler, because I didn't immediately jump on the idea of adding VOXELDEF/voxel support to GZDB. Which was, of course, the single reason nobody created or used them in (G)ZDoom mods. So, any mods with custom-crafted voxels in the past 3 years, anyone?

[scifista42]

MaxED said:

When deleting a linedef there is no way of determining which sector the user wants to stay and which should be consumed.

There are lots of possible ways to determine it, here are just a few ideas: Keep the sector with bigger area. Keep the sector on the linedef's front side. Keep the sector on the same side of the linedef where is the mouse cursor at the moment of deletion. Pop up a dialogue window or whatever to let the user choose the sector to keep. Or just choose randomly, and make sure that if the user Undo-es the action and does it again, the other sector will be kept than the one that was kept previously.

MaxED said:

And of course you have queried all GZDB users and have the statistics at hand.

Admittedly, no. It just sounds probable.

[MaxED]

scifista42 said:

There are lots of possible ways to determine it...

1. None of these are guaranteed to do what the user expects.
2. "Dissolve item" action already does that. It uses "keep sector with bigger bounding box" approach, if I remember correctly.

scifista42 said:

Admittedly, no. It just sounds probable.

Taken out of your arse, then.

[scifista42]

MaxED said:

There's a thing I've learned while developing GZDB: when a user asks for a feature/change he personally won't use, but the other mappers will benefit from, there's a 99% chance that nobody ever would use such feature.

In this case, it's certain that people will use it, just without realizing it. You will find it out by observing a 100% decreased rate of newbie mappers posting on the forum to complain about strange issues in their maps that turn out being unclosed sectors caused by uncareful deletion of linedefs.

MaxED said:

1. None of these are guaranteed to do what the user expects.

The pop-up sector-selecting window is.

[Graf Zahl]

scifista42 said:

@Graf Zahl: Do you realize that the sectors which the mapper wants to join would almost always have similar or even the exact same properties to each other? And even if they didn't, the mapper would expect one of them to get discarded before even deleting the linedefs, and he would know exactly which one got discarded at least after deleting the linedefs (or even before, depending on implementation) - so if the unintended one got discarded, he'd know instantly and he'd correct it easily. I don't see this as anything comparable to the undoubtly negative effect of unintented unclosed sectors.

IN other words: You'd take the gamble that the editor does what you want instead of having full control?

You know, it's people like you who are responsible for all that horrible hardware and software out there that has been dumbed down to the point where experts lose their sanity because nothing works like they'd like.

[scifista42]

Graf Zahl said:

IN other words: You'd take the gamble that the editor does what you want instead of having full control?

In something as easily understandable, noticeable and fixable as choosing one sector of two, I wouldn't see it as a big issue at all, with default controls (and provided those may be changed). But if this is the real main part of my point that you disagree with, it can be done in other ways that also comply with my view and that I've suggested in my other posts. I only want to avoid making accidental unclosed sectors.

Graf Zahl said:

You know, it's people like you who are responsible for all that horrible hardware and software out there that has been dumbed down to the point where experts lose their sanity because nothing works like they'd like.

I certainly hope I'd not be one of such. I just don't see making newbie-friendly software and making pro-friendly software as mutually exclusive goals for a single project.