david_a00 wrote:I was assuming that Z coordinates already were in tile units. I agree that making everything tile units would be logical - why would someone want to make a plane that is something weird like 76 pixels high?

In Shadowcaster, plane heights are dictated by texture heights. This allows stuff like dynamically changing plane height during the game, an effect which is used to simulate a basin being drained.

david_a00 wrote:I have an object model for UWMF and the problem was that I couldn't come up with a good name for what each thing inside a planemap is called. I ended up with the ungainly PlanemapEntry. I suppose MapTile or TileSpace might be better.

Internally ECWolf uses MapTile to refer to the tile palette entries. I use MapSpot for the physical location.

david_a00 wrote:I was assuming that Z coordinates already were in tile units. I agree that making everything tile units would be logical - why would someone want to make a plane that is something weird like 76 pixels high? I have a raycaster engine that I was playing around with, and at one point I got really bogged-down implementing every possible thing that you could customize even if it wasn't useful. I think even having a plane depth limited to an integer number of tile units seems like an appropriate limitation for the type of engine ECWolf is. There's always Quake if somebody really wants true 3D.

Some 3D is the goal. As far as performance goes odd plane heights shouldn't have a significant impact. The performance of POT comes at the texture mapper and not at the scaler. That is to say if you support vertical tiling anyway cutting it short shouldn't impact performance much if at all.

Now doing stacked planes does have a cost, but I believe it can be minimized to only show when stacks are in view. As for why not just use Quake? Combination of editing simplicity and because it's fun.

david_a00 wrote:I haven't looked into how the translators work; aren't they run-time transformations?

Yes. They are driven by scripts/tables and some of the parser code is shared between UWMF and map translators. Custom map translators allow a lot of the functionality that would be exposed by UWMF to be used in binary maps created by existing editors. The keyword change seems far to minor.

david_a00 wrote:Not sure if you have specific plans for when this will be switched over so I'll document them as-is I guess.

I'll do it for 1.4 since it's best to get it out of the way. That said I don't know when the release date for it will be (well sometime this year hopefully) since I'm still getting into the groove of the full time job thing.

david_a00 wrote:Do you care about having UWMF as an actual document that can be passed around like UDMF or should it all be in the wiki?

While a formal document is nice. The wiki is easiest to keep up to date, so it might be best to just stick with that.

I'll use MapSpot for consistency. I've used those terms a little bit on the wiki changes I started on last night, so I'll have to make another pass to get them consistent.

I saw that screenshot on your Twitter last week

I have a lot of ideas for things that I could do with my framework and one of them is some sort of GUI editor. I don't want to go promising anything because, as you you've probably come to realize, coming home from work and doing basically a second job for free is extremely difficult. Motivation is by far the most precious resource for a hobby project and I've really come to respect anybody who is able to stick with something for years on end.

I meant optional properties for UWMF blocks. Maybe I'm looking at the wrong branch or something, but in gamemap_uwmf.cpp in the ECWolf source I see a lot of "MustGetToken" calls. But then again, I didn't specify things like "dontoverlay" and the map still worked fine...

Anything that can have a logical default is optional (the old spec specifies which values have a default). What you're seeing is that once the parser finds a key, it must be followed by an equals sign, a value, and finally a semicolon. If you look at gamemap.h you can see the values being initialized in the constructors. I think it's just coordinates and textures that don't have a default. I do initialize them for sanity, but I wouldn't consider it good practice to rely on that (I could be convinced that defining the default Z as 0 is good idea though).

I've been working on my UWMF parser when I have the time and a couple of more things occurred to me:

Tiles - Let's imagine how a hypothetical UWMF editor would work. A user would define a palette of tile definitions and select one to draw some walls with. It seems like it would be extremely useful for there to be a textual description of what the tile is. In other words, an optional string "name" or "description" field on the UWMF Tile definition. I realize that ECWolf technically doesn't need to care since it's supposed to ignore unknown properties, but at the same time it would be beneficial to include this in the standard now when it's still wide-open.

Tags - If actor names / action functions are defined by strings, it seems fitting that tags should be too. Asking to user to define arbitrary integers when creating a map seems a bit user hostile. This is clearly a legacy from Doom that seems silly to port over to ECWolf. However, obviously tags are substantially different from something like an actor name, and it would probably be a complete pain to define them as strings in UWMF. Taken to a logical extreme, you could have a unique signature for every single action function. Doable, but significantly more complicated in terms of parsing and implementation. So, as a more pragmatic solution, how about a Tag block in UWMF that could optionally describe a tag?

Again, ECWolf technically doesn't need to care since it will (should?) just ignore it, but it seems beneficial for editor interoperability to define something now.

WAD files - I can understand why they show up in ECWolf because of its ZDoom heritage, but is there a benefit to using them? I don't know if you have a particular vision of how ECWolf project editing will work once everything is nailed down. It seems like things could be simplified by dictating that all ECWolf maps/mods are always in PK7 format. Instead of having a bunch of WAD files inside of a PK7, the package would just contain directories for each map with the lumps directly in them (TEXTMAP or a legacy binary format, MAPINFO, etc). I don't know if I'm missing something here, but adding the complexities of WAD management to UWMF editors seems like it should be avoided unless it's required for something.

david_a00 wrote:Tiles - Let's imagine how a hypothetical UWMF editor would work. A user would define a palette of tile definitions and select one to draw some walls with. It seems like it would be extremely useful for there to be a textual description of what the tile is. In other words, an optional string "name" or "description" field on the UWMF Tile definition. I realize that ECWolf technically doesn't need to care since it's supposed to ignore unknown properties, but at the same time it would be beneficial to include this in the standard now when it's still wide-open.

Similar was added to UDMF after some time. For the sake of consistency with UDMF, use "comment" as the key and consider it valid for all blocks.

david_a00 wrote:Tags - If actor names / action functions are defined by strings, it seems fitting that tags should be too. Asking to user to define arbitrary integers when creating a map seems a bit user hostile. This is clearly a legacy from Doom that seems silly to port over to ECWolf. However, obviously tags are substantially different from something like an actor name, and it would probably be a complete pain to define them as strings in UWMF. Taken to a logical extreme, you could have a unique signature for every single action function. Doable, but significantly more complicated in terms of parsing and implementation. So, as a more pragmatic solution, how about a Tag block in UWMF that could optionally describe a tag?

As someone who used to be heavily involved in Doom editing, I can say that numbered tags aren't as user unfriendly as they seem on the surface. In general my work flow was to do everything related to a specific tag at once. That is to say referring back to tags usually didn't happen, and at the rate it did inspecting one of the other elements wasn't any more time consuming than finding a name in a list would be. Once editors got the ability to automatically find the next free tag pretty much all memorization needed was removed. These days editors have even more tricks up their sleeves to make it even easier including drawing arrows to everything affected by a tag.

Tags aren't completely foreign to the binary format either as ROTT has something that can be described as a reverse tagging system (works in reverse to how Doom does it, but basically functionally equivalent). In ROTT an action is linked to an activation point by giving the X,Y coordinates in an extra plane of data. IIRC Blake Stone also has some tagging system, but I forget how it works off head. But the point I'm getting at is I don't really think names here would be helpful engine side (not exactly a trivial amount of work to support them either) and would provide fairly marginal benefit editor side.

That said your suggestion on a block to attach meta data to tags is an interesting one. I'm thinking about it and will probably suggest using a user_ prefix for things that the engine can ignore. UDMF defined such prefix for keys in a block, don't think they defined actual user blocks. But I will come back to this hopefully over the weekend.

david_a00 wrote:WAD files - I can understand why they show up in ECWolf because of its ZDoom heritage, but is there a benefit to using them? I don't know if you have a particular vision of how ECWolf project editing will work once everything is nailed down. It seems like things could be simplified by dictating that all ECWolf maps/mods are always in PK7 format. Instead of having a bunch of WAD files inside of a PK7, the package would just contain directories for each map with the lumps directly in them (TEXTMAP or a legacy binary format, MAPINFO, etc). I don't know if I'm missing something here, but adding the complexities of WAD management to UWMF editors seems like it should be avoided unless it's required for something.

Both here and with UDMF the WAD wrapper is actually to simply editor development. The WAD format is trivial compared to the ZIP file format (ZDoom/ECWolf implement far more of the zip standard than most zip libraries and tools) or 7Z file format. I can definitely support dropping the text data directly into a directory if you find that's what you want to support.

As for supporting WAD mods in general, it's something I get for free from using ZDoom's code. There's not a feature difference between using either format just an organizational one so in the end it doesn't bother me to support them.

Blzut3 wrote:
Similar was added to UDMF after some time. For the sake of consistency with UDMF, use "comment" as the key and consider it valid for all blocks.

That'll work! I'll add it to the Wiki soon. I've been mainly looking at Quasar's 1.1 spec, not any of the ZDoom additions.

That said your suggestion on a block to attach meta data to tags is an interesting one. I'm thinking about it and will probably suggest using a user_ prefix for things that the engine can ignore. UDMF defined such prefix for keys in a block, don't think they defined actual user blocks. But I will come back to this hopefully over the weekend.

From reading the UDMF spec more carefully, it does appear that identifiers have to be defined ahead of time, other than 'user_' fields (keywords can be unknown, somehow). My parser skips over unknown identifiers but that appears to be more lenient than strictly necessary. I did realize that currently it would choke on an unknown block, ironically enough.

Both here and with UDMF the WAD wrapper is actually to simply editor development. The WAD format is trivial compared to the ZIP file format (ZDoom/ECWolf implement far more of the zip standard than most zip libraries and tools) or 7Z file format. I can definitely support dropping the text data directly into a directory if you find that's what you want to support.

As for supporting WAD mods in general, it's something I get for free from using ZDoom's code. There's not a feature difference between using either format just an organizational one so in the end it doesn't bother me to support them.

I haven't made a Doom map in maybe 10 years; does GZDoom Builder support PK3/PK7 files natively or is it up the mod author to package everything? I was assuming it could open a project as a whole (an IDE versus a text editor, basically).

I might be getting ahead of myself here, but I have no idea how far along any other editors are or what they were planning on doing. Maybe I was coming up with a straw man of a hypothetical map editor coder who would balk at yet another format to worry about.

By the way, is there a decent description anywhere of the native Wolf 3D level format? Writing a converter to UWMF would be useful for a lot of things.

Is it true that every modern Wolfenstein level editor has their own binary format???

david_a00 wrote:From reading the UDMF spec more carefully, it does appear that identifiers have to be defined ahead of time, other than 'user_' fields (keywords can be unknown, somehow). My parser skips over unknown identifiers but that appears to be more lenient than strictly necessary. I did realize that currently it would choke on an unknown block, ironically enough.

Not sure where you're seeing that. The grammar section is pretty clear:

Compliant parsers will ignore all unknown keywords in global assignments,
block-level assignments, and block headers. Compliant parsers should attempt
to preserve as much of such information as is possible by using a flexible
mapping such as hashing.

Which also states that as an editor you should try preserve unknown information. As a parsing library you should probably be treating the documents as a key value store of sorts.

david_a00 wrote:I haven't made a Doom map in maybe 10 years; does GZDoom Builder support PK3/PK7 files natively or is it up the mod author to package everything? I was assuming it could open a project as a whole (an IDE versus a text editor, basically).

GZDoom Builder and Slade both do PK3 files natively. Don't think any PK7 tools exist, but a lot of people (including myself) just use standard compression tools. ZDoom and ECWolf can actually load a directory and treat it as a mod.

david_a00 wrote:I might be getting ahead of myself here, but I have no idea how far along any other editors are or what they were planning on doing. Maybe I was coming up with a straw man of a hypothetical map editor coder who would balk at yet another format to worry about.

I know the other editors got far enough along to load and save maps and have some incomplete interface for painting tiles. I don't think any of them load non-map resources.

david_a00 wrote:By the way, is there a decent description anywhere of the native Wolf 3D level format? Writing a converter to UWMF would be useful for a lot of things.

Blzut3 wrote:That said your suggestion on a block to attach meta data to tags is an interesting one. I'm thinking about it and will probably suggest using a user_ prefix for things that the engine can ignore. UDMF defined such prefix for keys in a block, don't think they defined actual user blocks. But I will come back to this hopefully over the weekend.

So thinking about this more this seems like the way I want to go. Named tags as a first class construct would complicate things more than I would like engine side.

In my defense about the keyword thing earlier, the earlier part of the spec only refers to keywords in the context of something assigned to a field. It's only later that the concept is implicitly expanded to include the actual field names. Reading is fun-damental!!

Blzut3 wrote:

Blzut3 wrote:That said your suggestion on a block to attach meta data to tags is an interesting one. I'm thinking about it and will probably suggest using a user_ prefix for things that the engine can ignore. UDMF defined such prefix for keys in a block, don't think they defined actual user blocks. But I will come back to this hopefully over the weekend.

So thinking about this more this seems like the way I want to go. Named tags as a first class construct would complicate things more than I would like engine side.