UWMF questions

[david_a00]

I'm interested in creating a random map generator for fun and I figured good old Wolf 3D was the easiest option (don't get your hopes up for a Wolf Oblige or anything...)

Generating UWMF seems a lot easier than figuring out some ancient crusty binary format, but I have some questions about the spec:
- Where is the origin? Things can have a X and Y coordinate, but what are they relative to? Top left (North-West corner) or bottom left (South-West corner)? This seems to be an omission from the UDMF spec as well
- Is there no way to specify the light level in UWMF?
- Is there an example map somewhere?
- If I manage to create this generator, will it be the second program in the world that supports UWMF?

EDIT: After thinking about it more I don't think UDMF has an issue with the origin. From what I remember Doom maps can have negative x/y coordinates for stuff so it doesn't really matter. For UWMF, however, I assume it does matter because each map has a defined, finite width/height.

[david_a00]

The UWMF spec hosted on Google Docs does specify that the origin is at the North-West corner. It's just kind of mentioned in the Planemaps section; I would recommend putting that in one of the opening general sections since it applies to other sections as well.

I've been trying to create a valid UWMF map to see if I understand it. I've gotten ECWolf to load it without complaining about any syntax errors, but now it just bombs immediately after the level loading screen is done.

[Blzut3]

Sorry, been chasing a deadline at work so I haven't been making my rounds on the forums. Can you upload the map you made and I can see what's going on?

I'll quickly go over those points:

• All coordinates are indeed from the north west.
• There is, however since editor interest has been low I never really bothered spec it out. They're in an experimental namespace.
• I uploaded a hand generated map a long time ago (I think it was even prior to ECWolf 1.0). At this point it's probably easier for me to just look at your output and determine what went wrong.
• Strictly speaking no. There are two or three editors on someone's computer that has UWMF support working to some degree. None of them are released though so you would have the honor of being the second released program with UWMF support.

[david_a00]

I can understand the deadlines

My company has a Startup Weekend this coming weekend (employees voluntarily come in and try to complete a project by Sunday evening). I like to do something completely different from what I do for work (mainly regulated medical applications), hence the level generator. I was trying to get a good grasp of the mechanics before the weekend so I could focus on more fun things then.

The UWMF I'm generating isn't very big so I've attached it inline. I think I'm packaging it correctly when I try to run it; I used Slade to create a WAD with the following entries:
- MAP01 (empty)
- TEXTMAP (contains the UWMF)
- ENDMAP (empty)

The map is supposed to be a 2x2 room surrounded with walls with a player start.

Code: Select all

namespace = "Wolf3D";
tilesize = 64;
name = "Test Output";
width = 4;
height = 4;
tile
{
	texturenorth = "-";
	texturesouth = "-";
	texturewest = "-";
	textureeast = "-";
	offsetvertical = false;
	offsethorizontal = false;
	blockingnorth = false;
	blockingsouth = false;
	blockingwest = false;
	blockingeast = false;
}
tile
{
	texturenorth = "GSTONEA1";
	texturesouth = "GSTONEA1";
	texturewest = "GSTONEA1";
	textureeast = "GSTONEA1";
	offsetvertical = false;
	offsethorizontal = false;
	blockingnorth = true;
	blockingsouth = true;
	blockingwest = true;
	blockingeast = true;
}
sector
{
	texturefloor = "#FFFFFF";
	textureceiling = "#000000";
}
zone
{
}
plane
{
	depth = 64;
}
planemap
{
	{1,0,-1},
	{1,0,-1},
	{1,0,-1},
	{1,0,-1},
	{1,0,-1},
	{0,0,0},
	{0,0,0},
	{1,0,-1},
	{1,0,-1},
	{0,0,0},
	{0,0,0},
	{1,0,-1},
	{1,0,-1},
	{1,0,-1},
	{1,0,-1},
	{1,0,-1}
}
thing
{
	x = 96;
	y = 96;
	z = 0;
	angle = 0;
	type = 1;
	ambush = false;
	patrol = false;
	skill1 = true;
	skill2 = true;
	skill3 = true;
	skill4 = true;
}

I made Doom maps aeons ago but I'm totally unfamiliar with Wolf 3D maps so some of the concepts are a bit fuzzy. Am I correct in assuming that in UWMF you manually have to texture a tile with the light/dark versions?

By the way, the lack of a trailing comma on the last entry in planemap is a bit annoying. Is there a reason for it? I mean, it looks a bit nicer, but it seems a bit needless.

[Blzut3]

So the thing you were missing is that the thing's coordinates are floating point constants, so you want 1.5 not 96. Secondly for the open spaces you want to use tile -1 instead of creating a tile 0 with "-" as the textures (which produces HOMs).

Yes you currently have to manually apply the darker textures. Eventually ECWolf will have automatic fake contrast like Mac Wolf3D/Doom, but it doesn't right now.

[david_a00]

If empty tiles use -1, is it not possible to put transparent textures between tiles? (vines, grates, etc) Is there a difference between "-" and not specifying a texture?

Do you mind if I submit a draft of the UWMF spec that clarifies some of these things? Neither the wiki or Google Docs version seems very complete. Having the spec in a format like Markdown would be more convenient too. It won't be this week, but maybe next.

UWMF is a pretty open space right now compared to the Doom editing world so it would be fun to help out. I'm thinking of expanding my library to support reading as well; it would be useful for me to create a map visualizer independent of ECWolf for debugging purposes. Having a different implementation would probably be helpful for anybody creating a full-blown editor as well.

[Blzut3]

If empty tiles use -1, is it not possible to put transparent textures between tiles? (vines, grates, etc) Is there a difference between "-" and not specifying a texture?

There is no difference between "-" and no texture. With that said, I did observe a difference between a tile with empty textures and -1. Probably a bug (will investigate at a later point in time) and probably a regression since IIRC I had it working such that you could leave out textures to make thin walls.

That said, ECWolf does not current support masked textures so there's not a lot of point.

Do you mind if I submit a draft of the UWMF spec that clarifies some of these things? Neither the wiki or Google Docs version seems very complete. Having the spec in a format like Markdown would be more convenient too. It won't be this week, but maybe next.

Sure. Would you like a wiki account? That seems like the best place to put things like this to me.

UWMF is a pretty open space right now compared to the Doom editing world so it would be fun to help out. I'm thinking of expanding my library to support reading as well; it would be useful for me to create a map visualizer independent of ECWolf for debugging purposes. Having a different implementation would probably be helpful for anybody creating a full-blown editor as well.

Indeed. As I've told other people working on UWMF tools, if you think there's a better way things can be done here I do appreciate input. Nothing there is really set in stone since there are no tools.

[david_a00]

Sure, I'll take a wiki account!

I got my generator updated and was playing around with defining all the stuff for Wolf3D (I don't own SoD). I made a texture gallery level, got the thing id list trimmed down, and played around with patrol routes. Remaining tasks I want to figure out before the weekend are doors, directly generating WADs, and pushwalls.

Do the thing IDs match what Wolfenstein used internally? I was curious why 23-28 were SoD bosses.

Will ECWolf become more fault tolerant when it gets a console, or is that independent? It gives you a nice error on syntax issues with UWMF, but if you screw up a logical property like the number of planemap entries it rather ungracefully exits without a trace.

[Blzut3]

Sure, I'll take a wiki account!

Sent account details to your email.

Do the thing IDs match what Wolfenstein used internally? I was curious why 23-28 were SoD bosses.

Yes and no. IIRC some of the ordering comes from going down the internal list (you'll notice most of the decorations follow the sprite order), but it doesn't use the same numbers as the binary map format. The reason for that is because the binary map format used a different number for each starting angle, what skill levels the thing appeared in, as well as if they were patrolling or not. Additionally there's some overlap between the Wolf3D and Spear things. The ordering used here is arbitrary partly because some things got omitted (hence why most of the decorations) and then added to the list later. I do kind of regret not sorting the list, but on the other hand one arbitrary number scheme is just as good as another. These numbers are the "doomednums" that are assigned via DECORATE.

The binary map loader uses a table to translate old thing numbers to the DECORATE thing number. I've been thinking about removing the dependency here since much of the reason "doomednums" exist in the Doom world is because of interoperability between ports and because they don't need to do thing number translation. So the more I think about it the sillier it seems vs just using the class names. (Then everyone will need to put up with the names I assigned to things I couldn't tell what I was looking at! )

Will ECWolf become more fault tolerant when it gets a console, or is that independent? It gives you a nice error on syntax issues with UWMF, but if you screw up a logical property like the number of planemap entries it rather ungracefully exits without a trace.

This is independent of the console. Honestly just my programmer brain not accounting for bad input.

[david_a00]

Sure, I'll take a wiki account!

Sent account details to your email.

I couldn't log in; the email said my username was "David a" which doesn't seem valid. I would prefer david_a or if that doesn't work DavidAramant.

The reason for that is because the binary map format used a different number for each starting angle, what skill levels the thing appeared in, as well as if they were patrolling or not.

The more I read about old-school Wolf modding the happier I am with UWMF. Not having to deal with junk like "elevators must be east/west because of how the tiles are defined" makes things so much easier.

I can see pros/cons to using class name strings instead of numbers for things; it would certainly be more descriptive (assuming the names aren't too ambiguous ) but it would bloat the format a bit. Given how wordy the rest of the format is I honestly don't have an issue with switching over. It would be worth going over the class names again to make sure they are descriptive enough; things like "PacmanGhostBlinky" instead of just "Blinky", making the boss names more descriptive, etc.

When I get around to implementing reading UWMF I'll probably end up creating tons of invalid input files. I'm accustomed to writing tons of automated tests for work so that won't be a big deal. I can pass those along if you want to add some robustness to ECWolf's parser

[Blzut3]

I couldn't log in; the email said my username was "David a" which doesn't seem valid. I would prefer david_a or if that doesn't work DavidAramant.

Try now with DavidAramant. MediaWiki butchered your username since I did enter it as "david_a".

[david_a00]

Nope; "Incorrect password entered. Please try again."

[david_a00]

Our (a couple of colleagues that I roped into helping me plus myself) weekend project went about as well as you would expect a random level generator written in 2 days to go. It makes levels but they are hideous. I don't think the world needs more terrible Wolf 3D levels so I'm not going to release any binaries in its current state. We had fun though, and I do plan on making a more serious attempt at a generator. We didn't run into any ECWolf bugs with UWMF during the weekend

Back to the UWMF spec, I had some thoughts/questions before I start:
* Since UWMF is supposed to be case-insensitive, I plan on making everything camelCase for clarity unless there are any objections.
* The word tile seems to refer to both an abstract concept of a particular set of textures/flags and the concrete contents of a map. Perhaps the existing tile should be renamed to tileTheme and tile should refer to an entry in a planeMap?
* It seems that almost every position/size in UWMF is in tile coordinates except for a few outliers. I would like to make those exceptions stand out more - tileSizeInPixels and plane.depthInPixels. 'Pixels' probably isn't the best term but I can't think of a more appropriate name.
* Is there a reason to use zone instead of soundZone? I don't know if you have plans for more attributes in a zone that would justify the more generic name.
* thing.type - I would be in favor of replacing this with className or actorName instead; it seems to fit with using the texture names directly.
* Similarly, it seems better for a trigger.action to be a string instead of a number.
* I thought it would be nice to have appendices for the Wolf 3D texture names, actor names, and trigger actions rather than including them directly in the spec. You could argue they don't belong in the spec at all, but for pragmatic reasons it's pretty nice to have a reference for everything included out of the box.

[Blzut3]

Our (a couple of colleagues that I roped into helping me plus myself) weekend project went about as well as you would expect a random level generator written in 2 days to go. It makes levels but they are hideous. I don't think the world needs more terrible Wolf 3D levels so I'm not going to release any binaries in its current state. We had fun though, and I do plan on making a more serious attempt at a generator. We didn't run into any ECWolf bugs with UWMF during the weekend

Good to hear!

Since UWMF is supposed to be case-insensitive, I plan on making everything camelCase for clarity unless there are any objections.

That's fine.

The word tile seems to refer to both an abstract concept of a particular set of textures/flags and the concrete contents of a map. Perhaps the existing tile should be renamed to tileTheme and tile should refer to an entry in a planeMap?

Tile theme seems overly specific to me. The Wolf engine is a tile based engine (the map format among other things actually comes from Commander Keen and other early id games) and as far as I know the overload of the term to refer to both the space and the thing that goes into the space is common across these kinds of engines.

It seems that almost every position/size in UWMF is in tile coordinates except for a few outliers. I would like to make those exceptions stand out more - tileSizeInPixels and plane.depthInPixels. 'Pixels' probably isn't the best term but I can't think of a more appropriate name.

The term for a "pixel" from the Doom mapping world is called a "unit." The Z axis is specified in units since varying plane depths makes a lot of sense. However now that you're making me think about the inconsistency I wonder if it might make sense to scale according to the tile size as well. In that case units would only be exposed for the initial scale if I recall everything correctly. This is something that I could easily change now since the Z-axis is unimplemented at the moment.

The ROTT hacker's guide even handles height in "tiles" for what it's worth.

Is there a reason to use zone instead of soundZone? I don't know if you have plans for more attributes in a zone that would justify the more generic name.

I think it's mostly "designed to be written by machine not humans" and less data in means less data out after compression. Off hand can't think of anything not sound related that a zone would contain as tying any non-sound effect to sound propagation would probably place drastic limits on the effect's usefulness.

Given that the parser for the binary map translators and UWMF are shared I'm hesitant to change the keyword for the slight extra clarity (I don't guarantee mod compatibility at this point, but there's still a cost/benefit analysis to do against the few mods that are out there). At least I didn't keep the original Wolf3D terminology of "floors" for them though!

thing.type - I would be in favor of replacing this with className or actorName instead; it seems to fit with using the texture names directly.

I'm definitely going to consider removing doomednums across the board.

Similarly, it seems better for a trigger.action to be a string instead of a number.

You're right. This is a case of me blindly copying how things were decided for Doom and there was recently talks about doing this in UDMF as well (probably won't amount to anything there though).

I thought it would be nice to have appendices for the Wolf 3D texture names, actor names, and trigger actions rather than including them directly in the spec. You could argue they don't belong in the spec at all, but for pragmatic reasons it's pretty nice to have a reference for everything included out of the box.

They don't really belong in the spec, but it would make a good set of wiki pages to have tables from resource indexes to assigned names.

[david_a00]

The word tile seems to refer to both an abstract concept of a particular set of textures/flags and the concrete contents of a map. Perhaps the existing tile should be renamed to tileTheme and tile should refer to an entry in a planeMap?

Tile theme seems overly specific to me. The Wolf engine is a tile based engine (the map format among other things actually comes from Commander Keen and other early id games) and as far as I know the overload of the term to refer to both the space and the thing that goes into the space is common across these kinds of engines.

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.

It seems that almost every position/size in UWMF is in tile coordinates except for a few outliers. I would like to make those exceptions stand out more - tileSizeInPixels and plane.depthInPixels. 'Pixels' probably isn't the best term but I can't think of a more appropriate name.

The term for a "pixel" from the Doom mapping world is called a "unit." The Z axis is specified in units since varying plane depths makes a lot of sense. However now that you're making me think about the inconsistency I wonder if it might make sense to scale according to the tile size as well. In that case units would only be exposed for the initial scale if I recall everything correctly. This is something that I could easily change now since the Z-axis is unimplemented at the moment.

The ROTT hacker's guide even handles height in "tiles" for what it's worth.

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.

That would leave the initial definition of how big a tile is as the only outlier. "Pixels" seems ambiguous since ECWolf supports high-resolution textures. On the other hand, if you name it something involving "units" you'll probably have to describe a unit in terms of pixels anyway. Maybe that's still better, I dunno.

Is there a reason to use zone instead of soundZone? I don't know if you have plans for more attributes in a zone that would justify the more generic name.

I think it's mostly "designed to be written by machine not humans" and less data in means less data out after compression. Off hand can't think of anything not sound related that a zone would contain as tying any non-sound effect to sound propagation would probably place drastic limits on the effect's usefulness.

Given that the parser for the binary map translators and UWMF are shared I'm hesitant to change the keyword for the slight extra clarity (I don't guarantee mod compatibility at this point, but there's still a cost/benefit analysis to do against the few mods that are out there). At least I didn't keep the original Wolf3D terminology of "floors" for them though!

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

If you ever want to change it, now would be the time...

thing.type - I would be in favor of replacing this with className or actorName instead; it seems to fit with using the texture names directly.

I'm definitely going to consider removing doomednums across the board.

Similarly, it seems better for a trigger.action to be a string instead of a number.

You're right. This is a case of me blindly copying how things were decided for Doom and there was recently talks about doing this in UDMF as well (probably won't amount to anything there though).

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

I thought it would be nice to have appendices for the Wolf 3D texture names, actor names, and trigger actions rather than including them directly in the spec. You could argue they don't belong in the spec at all, but for pragmatic reasons it's pretty nice to have a reference for everything included out of the box.

They don't really belong in the spec, but it would make a good set of wiki pages to have tables from resource indexes to assigned names.

Actually, yes, wiki pages would be far more appropriate. I was still thinking of the UWMF spec as an external document.

I might be able to start on all of this on Monday.

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?