.dwd support

[Superluigieth1]

I was wondering, can anyone make a level editor which can support .dwd? I was wondering, like a modern editor. Thoughts?

[scifista42]

I don't see any advantage of a potential .dwd editor over a .wad editor, considering that each .dwd file needs to be eventually converted to .wad file to be playable anyway, and there are already more than decent .wad editors, it should be OK to start editing a .dwd file by converting it to .wad file instead and then use an existing .wad editor to edit it.

[Gez]

Superluigieth1 said:

I was wondering, can anyone make a level editor which can support .dwd? I was wondering, like a modern editor. Thoughts?

You mean the text format used by DoomEd?

[Graf Zahl]

The approach the original editor uses is incompatible with how modern editors work.
.dwd has no concept of sectors, all the sector properties have to be defined on the linedef and the node builder then creates the actual sectors. This alone is responsible for the majority of mapping errors in the original IWAD maps.

This also means that it'd have to be created from scratch, because no current editor works like that.

Conclusion: Waste of time.

[scifista42]

Graf Zahl said:

This alone is responsible for the majority of mapping errors in the original IWAD maps.

?

I doubt it. Citation needed.

[Gez]

There's no real obstacle, it's just pointless.

Vertices and sectors are still there, it's just that they're written as line properties. You will automatically merge every sector that have identical properties, though -- no way to keep them separate, which is why the Id Software mappers used dummy tags for stairbuilder sectors. Merged sectors can have unwanted effects related to sound propagation as well as rather obscure collision issues.

[boris]

scifista42 said:

?

I doubt it. Citation needed.

Imagine a square room. Since there is no concept of sectors you had to set the desired sector properties on the sidedefs. Sectors were created later when compiling the map file into a WAD. Now if one of your sidedefs in the square room had different sector properties than the other lines you have broken sectors.

Look at sector 1 in Doom 2 MAP01. It has a line in the middle that's set to block sounds. It's completely useless because the sector on both sides is the same. That's probably not what Petersen had in mind, but I guess since all the sides had the same propetries they just got merged into one sector when compiling.

[scifista42]

@boris:

The former has nothing to do with the format, but with basic correct functionality of the editor and basic competence of its user, similarly as not deleting linedefs between different sectors should be the basic competence of a Doom Builder user.

The latter is a good example how the format can be problematique to use (along with the other potential problems mentioned by Gez), but it's just one example, not "the majority of mapping errors in the original IWAD maps".

[Graf Zahl]

scifista42 said:

@boris:

The former has nothing to do with the format, but with basic correct functionality of the editor and basic competence of its user, similarly as not deleting linedefs between different sectors should be the basic competence of a Doom Builder user.

Completely wrong. The actual sector creation is out of the mapper's control. The NODE BUILDER (which acts as a converter between .DWD and the final .WAD) is doing this and it's mercilessly merging adjoining sectors with identical properties.

I still remember back in 1994 when I tried to rebuild nodes for a few maps with broken ones that IDBSP completely trashed the map because it had its own ideas what belonged to one sector.

To make this error proof you need a lot more sanity checks. The original editor did not have such checks. And now just look for known mapping errors in the IWAD maps. Most of the problems in there come from the fact that there was no concept of 'sector' during editing. The most obvious one is in E3M8 but there's others, too, where without knowing how the original editor worked, you'd scratch your head how this could have gone wrong.

[scifista42]

Graf Zahl said:

The actual sector creation is out of the mapper's control. The NODE BUILDER (which acts as a converter between .DWD and the final .WAD) is doing this and it's mercilessly merging adjoining sectors with identical properties.

I know, but what I questioned was the means of this situation (one of 4 lines in a square formation somehow getting different sector properties than the others) happening in the first place. Either the editor would have to be glitched or the user incompetent.

Graf Zahl said:

And now just look for known mapping errors in the IWAD maps. Most of the problems in there come from the fact that there was no concept of 'sector' during editing.

I wouldn't mind checking a list/summary of them or something as easily-checkable as that, so that I would judge myself if the word "most" in your statement is valid.

[Gez]

scifista42 said:

I know, but what I questioned was the means of this situation (one of 4 lines in a square formation somehow getting different sector properties than the others) happening in the first place.

Okay, here goes: You have a sector. You want to raise its floor height by 16 units.

In a normal editor, you edit the sector properties and the sector's floor is now raised by 16 units. Done.

In DoomEd, you have to edit one line to edit its side's floor height by 16 units, and then update the other lines as well. There's a flood-fill algorithm that is there to help you automatically update all concerned lines, but obviously this algorithm either was flawed, or it was not always used and sometimes the human editors forgot some lines, regardless of the explanation there are maps in the IWADs where sectors aren't rightly closed because some sidedefs are attached to the wrong sector.

[Graf Zahl]

Note that I didn't say "Most mapping errors in IWAD maps are badly assigned linedefs"

I explicitly said: "Most errors were caused because the editor lacked the CONCEPT of a sector. And that includes any kind of sanity check that's normally implied by lacking this concept.

Even stuff like one of Hexen's maps where a pillar is missing one side can easily be attributed to the fact that the editor the maps were made with was 100% line based.

[scifista42]

@Gez: I would put that very situation under category "editor bug" rather than "conceptual flaw of the format", and I thought that merely the latter option was the point of discussion. If not, all OK.

[Gez]

Oh, definitely. As I said, implementing reading and saving of maps in that format in a normal editor wouldn't be hard; it just would be pointless and it would have the side-effect of automatically merging sectors. with identical properties.

[Graf Zahl]

Gez said:

Oh, definitely. As I said, implementing reading and saving of maps in that format in a normal editor wouldn't be hard;

Not hard, but as you said, definitely destructive and therefore not just pointless but completely useless:

it just would be pointless and it would have the side-effect of automatically merging sectors. with identical properties.

[scifista42]

Graf Zahl said:

Not hard, but as you said, definitely destructive and therefore not just pointless but completely useless:

Unless, of course, the editor automatically assigns a new unique tag to each newly drawn sector, or otherwise changes properties of newly drawn sectors so that this "automatic merging" wouldn't happen, until the mapper decides to actually join specific sectors.

[Graf Zahl]

No, even that wouldn't really work, unless you want to let the pseudo-tags end up in the resulting WAD.

There's also no way to distinguish between a real tag and a pseudo-tag that's just there to prevent sector merging.

No, sorry, even that would end up a pretty much messed up product.

Remember: It's the node builder which generates the final sectors, so you'd have to feed that some redundant data to avoid destructive actions.

[scifista42]

Graf Zahl said:

There's also no way to distinguish between a real tag and a pseudo-tag that's just there to prevent sector merging.

There is: Each "real" tag is present at least once as a linedef tag (at least on one linedef in the map) in addition to being a sector tag, which doesn't apply for any of the "pseudo" tags.

So, the nodebuilder would distinguish sectors with different tags as different non-joined sectors and write them into the wad as such, but change all "pseudo tags" to zero during this very process!

[Graf Zahl]

Wrong!

Behold your broken stairs!

[scifista42]

I don't think it would break stairs. Also read my edit of my previous post.

[Graf Zahl]

Of course it will break stairs. As things stand, the only way to preserve them (and that's what was done in the IWAD maps) was to tag each second sector - id used #999 for that.

If those get removed, the map won't work.

[scifista42]

Let's consider tags 666, 667 and 999 to be "special" and never evaluated as "pseudo tags", then.

EDIT: Wait, your statement might be wrong anyway. I made vanilla compatible maps with stairs in the past, and I didn't need to tag each second sector for it to work.

[boris]

scifista42 said:

EDIT: Wait, your statement might be wrong anyway. I made vanilla compatible maps with stairs in the past, and I didn't need to tag each second sector for it to work.

Because you have direct control over the sectors. Look at E2M1 of doom.wad: sectors 55-57 and 61-65 form a raising stair. But they have all the same properties, and would have been merged into a single sector (except for sector 61) when compiling from .dwd to .wad.

[scifista42]

Oh, OK. But then my suggestion of automatically tagging each new sector as unique to prevent merging should work alright as I said, even for stairs.

[Gez]

So stairbuilding:

7: E1M8, E2M1, E2M4x3, E2M5, E2M8x4, E3M3, MAP13, MAP18, MAP19, MAP24x2, MAP27
8: E1M3, E2M2, MAP08
100: MAP09
127: E4M8, MAP15x2, MAP21x4

Tag 99: E1M8, E2M8, MAP19
Tag 999: E1M3, E2M1, E2M2, E2M4, E2M5, E3M3, E4M8, MAP08, MAP09, MAP13, MAP15x2, MAP18, MAP21, MAP24, MAP27
Repeated first tag: E2M4x2

MAP21 and MAP24 have the oddity of having several different stairbuilding linedef target the same sector(s).

Based on that, the sector merging only happens to neighboring areas, so the effect is less destructive than I thought. After all, the sectors tagged 0 or 99/999 are not merged with each others.

[boris]

Yes, for some reason the compiler apparently tries to create as few sectors as possible. The whole dummy tag thing wouldn't have been needed if identical sector properties on both sidedefs of a 2-sided line would not result in a single sector.

To quote myself from earlier in this thread:

Look at sector 1 in Doom 2 MAP01. It has a line in the middle that's set to block sounds. It's completely useless because the sector on both sides is the same. That's probably not what Petersen had in mind, but I guess since all the sides had the same [sector] propetries they just got merged into one sector when compiling.

scifista42 said:

Oh, OK. But then my suggestion of automatically tagging each new sector as unique to prevent merging should work alright as I said, even for stairs.

No... when you already have the sector it's too late. You just have to create "smaller" sectors. I.e sectors that have no 2-sided lines inside of them.

The release of their editor also made it apparent why they used a "weird" method to wake up remote monsters, using a tiny sector that connects two sectors (like sector 39 in MAP01 of doom2.wad): while in a editor that can edit sectors diretly you could simply have a sector with two distinguished (not connected) areas, that was simply not possible in id's editor.

[scifista42]

Gez said:

Based on that, the sector merging only happens to neighboring areas, so the effect is less destructive than I thought.

It would make sense to me if Romero's design rule of always changing floor height between sectors with different floor textures existed precisely to avoid getting sectors merged in DoomEd.

boris said:

No... when you already have the sector it's too late.

I suggested that the editor would automatically assign a new tag to every new sector immediately upon its creation. That's not too late yet.

[Graf Zahl]

It'd still make no sense these days. Possible or not, the fact that the auto-merging even exists is a problem in itself that may break some maps unless some extreme care is taken.

The format is broken by design.

And I still don't get why you can't stop this pointless argument. Nobody today would be stupid enough to use a crippled intermediate format when the actual one perfectly does the job of properly preserving the info.

[scifista42]

As I said in my first post in this thread, I also believe that making or using a .dwd editor would be a pointless waste of time nowadays. I only argued against particular reasons why so which I disagreed with, or other statements which I've seen in this thread and considered them incorrect, merely for truth. :)

Spoiler

My reasoning is that potentially anyone who, for whatever reason, will ever search for related information and stumble upon this thread in the future, might get misinformed by potentially any incorrect statement in here, and that's why I don't like seeing incorrect statements without trying to correct them, even if our momentary problem has already been solved and it would be pointless to continue for us.

I also particularly dislike when somebody says "it's impossible" when the truth is merely "it's not an ideal solution" or "it's very improbable".

[Gez]

scifista42 said:

It would make sense to me if Romero's design rule of always changing floor height between sectors with different floor textures existed precisely to avoid getting sectors merged in DoomEd.

No, because the different floor texture already makes them nonmergeable.

It's just that it usually looks bad when you have two different floor textures next to each other on the same level.