UWMF questions

Advanced Wolfenstein 3D source port based upon Wolf4SDL and ZDoom.
[Home] [Download] [HG builds (Win)] [HG builds (Mac)] [Wiki] [Repo]

Moderator: Blzut3

david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

5 months, heh.

Anyway, I'm looking over the map translator documentation and I have some questions:
* Can 'include' statements only occur as the first line in the file?
* What exactly is the default translator?
* tile.modzone - " If the fillzone keyword is used, one adjacent zone code is then filled into the spot" - Which sound zone is used if there are multiple adjacent ones?
* What does "adjacent" mean in the above context? NSEW or diagonals as well?
* holowall and pathing - so the combination of these two flags will make the tile the thing is in non-solid, and the next tile in the direction that the thing is facing? What is this actually used for in the game?
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:* Can 'include' statements only occur as the first line in the file?
They can be used anywhere in the global scope.
david_a00 wrote:* What exactly is the default translator?
Based on the game being played the default translator is the one that ecwolf.pk3 specifies in iwadinfo.txt.
david_a00 wrote:* tile.modzone - " If the fillzone keyword is used, one adjacent zone code is then filled into the spot" - Which sound zone is used if there are multiple adjacent ones?
Counterclockwise search (starting at east). First one wins.
david_a00 wrote:* What does "adjacent" mean in the above context? NSEW or diagonals as well?
NSEW.
david_a00 wrote:* holowall and pathing - so the combination of these two flags will make the tile the thing is in non-solid, and the next tile in the direction that the thing is facing? What is this actually used for in the game?
This is to support a vanilla hack that some map authors used to make walls that you can walk through.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

I assume more than one other translator can be included?
How are the included contents handled - are they interpreted as if they were in the same file or is the entire linked file loaded first?

Given two files A and B, where the structure of B is:
B.Things
B.include A
B.Tiles

Does this get loaded as:
1)
B.Things
A.Things
A.Tiles
B.Tiles

or
2)
A.Things
A.Tiles
B.Things
B.Tiles
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:I assume more than one other translator can be included?
Yes.
david_a00 wrote: B.Things
A.Things
A.Tiles
B.Tiles
Like this.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

I updated the wiki page with these clarifications. I also changed both this page and the UWMF page to use strings for actor names / action specials which, uh, maybe was premature because I forgot that the released version doesn't do that yet.

While I was looking the xlat's in the dev version, I noticed some two odd things:
* The "modzone changetrigger" lines still use a number for the action. Does that number actually correspond to the action number special? Is it also supposed to be a string?
* In the "things" section, the big mapping table doesn't actually use quoted strings; it uses the actor names directly. Is there a reason for that? It makes parsing the format inconsistent with UWMF.
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:which, uh, maybe was premature because I forgot that the released version doesn't do that yet.
No worries. Would probably care more about features being marked {{dev}} but in this particular case I've kind of been recommending people learning to just go for the 1.4 style.
david_a00 wrote:* The "modzone changetrigger" lines still use a number for the action. Does that number actually correspond to the action number special? Is it also supposed to be a string?
This was an oversight and is now fixed. Thanks!
david_a00 wrote:* In the "things" section, the big mapping table doesn't actually use quoted strings; it uses the actor names directly. Is there a reason for that? It makes parsing the format inconsistent with UWMF.
I see your point, but in my opinion too late to change (already dealt with transitioning mod authors and I know there are some things released for the dev versions). Actor names are required to be valid C style identifiers so they will be seen used as such in some contexts in ECWolf scripting. For UWMF the idea was to reduce the number of types to make it easier to parse so an identifier is not a valid value in a key/value pair. The xlat code shares parsing code from the UWMF parser so that's why there's an inconsistency.

I did keep your comment in mind with the change to changetrigger though.

On a related note, if you haven't noticed, $Player1Start is two tokens so ECWolf will accept white space after the dollar sign although I would consider that bad style.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

Blzut3 wrote:
david_a00 wrote:* The "modzone changetrigger" lines still use a number for the action. Does that number actually correspond to the action number special? Is it also supposed to be a string?
This was an oversight and is now fixed. Thanks!
Is the action special name a quoted string in this context?
Blzut3 wrote:
david_a00 wrote:* In the "things" section, the big mapping table doesn't actually use quoted strings; it uses the actor names directly. Is there a reason for that? It makes parsing the format inconsistent with UWMF.
I see your point, but in my opinion too late to change (already dealt with transitioning mod authors and I know there are some things released for the dev versions). Actor names are required to be valid C style identifiers so they will be seen used as such in some contexts in ECWolf scripting. For UWMF the idea was to reduce the number of types to make it easier to parse so an identifier is not a valid value in a key/value pair. The xlat code shares parsing code from the UWMF parser so that's why there's an inconsistency.

I did keep your comment in mind with the change to changetrigger though.
After I posted that I did realize it's consistent with how they're defined in DECORATE. I can see the pragmatic rationale for leaving it alone as opposed to an Apple-style "upgrade or die" edict.

I think I can parse them without too much trouble, but it does push some of the validation into a deeper level. When I first implemented UWMF parsing I used a hand-written lexer fairly similar in concept to the one ECWolf uses, but I wasn't happy with the amount of code required and thought it was an unsustainable pattern for adding support for xlat. I switched over to a lexing framework instead which gives me a stream of tokens. If I define the actor name token last it should work, but it does mean that any typo in a keyword will be lexed as an actor name... I don't know that this will cause any major problems, however.

For xlat, will both strings and numeric ids for actors / actions be supported going forward? That will also make parsing a bit more cumbersome but it's doable. For UWMF I don't see a point in supporting the old style since I think I have a strategic reserve of the world's UWMF maps at the moment :)
Blzut3 wrote: On a related note, if you haven't noticed, $Player1Start is two tokens so ECWolf will accept white space after the dollar sign although I would consider that bad style.
$ is a token by itself? What does it actually signify?
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:Is the action special name a quoted string in this context?
Yep. Unless you think it would be better to do otherwise (not to late to change this).
david_a00 wrote:I think I can parse them without too much trouble, but it does push some of the validation into a deeper level. When I first implemented UWMF parsing I used a hand-written lexer fairly similar in concept to the one ECWolf uses, but I wasn't happy with the amount of code required and thought it was an unsustainable pattern for adding support for xlat. I switched over to a lexing framework instead which gives me a stream of tokens. If I define the actor name token last it should work, but it does mean that any typo in a keyword will be lexed as an actor name... I don't know that this will cause any major problems, however.
You should be lexing all the keywords into generic identifiers. Then look them up through some kind of hash table preferably (I use a giant set of ifs out of mostly laziness). Since UWMF has the semantics that any unknown keys should be preserved by the editor (and custom keys are allowed even if they're not yet useful) it's kind of counterproductive to differentiate them during lexing. ECWolf doesn't show this behavior yet since it doesn't have the ability to use custom fields in scripting and doesn't write out.
david_a00 wrote:For xlat, will both strings and numeric ids for actors / actions be supported going forward? That will also make parsing a bit more cumbersome but it's doable. For UWMF I don't see a point in supporting the old style since I think I have a strategic reserve of the world's UWMF maps at the moment :)
Action special numbers and thing ids are deprecated in 1.4. Both forms will be accepted in 1.4, but the numeric ids will be removed from the code some time prior to 2.0 (which is the version where any backwards compatibility issues will be considered regressions, so I will want to clean out any deprecated things before I'm "forced" to support them forever).
david_a00 wrote:$ is a token by itself? What does it actually signify?
Yes. Don't really have a name for it, but there is no class "Player1Start" so I guess it signifies that it's a meta thing. There will be more types of player start point in the future which will use the same syntax.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

Blzut3 wrote:
david_a00 wrote:Is the action special name a quoted string in this context?
Yep. Unless you think it would be better to do otherwise (not to late to change this).
On the one hand, unquoted strings would match the actor names. On the other hand, users can't create new action specials, and even if they could, it wouldn't make any sense because they wouldn't use those in the binary formats. I guess quoted is better since it matches UWMF.
Blzut3 wrote:
david_a00 wrote:I think I can parse them without too much trouble, but it does push some of the validation into a deeper level. When I first implemented UWMF parsing I used a hand-written lexer fairly similar in concept to the one ECWolf uses, but I wasn't happy with the amount of code required and thought it was an unsustainable pattern for adding support for xlat. I switched over to a lexing framework instead which gives me a stream of tokens. If I define the actor name token last it should work, but it does mean that any typo in a keyword will be lexed as an actor name... I don't know that this will cause any major problems, however.
You should be lexing all the keywords into generic identifiers. Then look them up through some kind of hash table preferably (I use a giant set of ifs out of mostly laziness). Since UWMF has the semantics that any unknown keys should be preserved by the editor (and custom keys are allowed even if they're not yet useful) it's kind of counterproductive to differentiate them during lexing. ECWolf doesn't show this behavior yet since it doesn't have the ability to use custom fields in scripting and doesn't write out.
It would have been best if I had looked at what the code does in the last couple of months :P
My app does work like that, so other than adding another token for the meta marker it's not a problem. Although, I doubt anyone realizes that it's a different token (unless there's a page somewhere that mentions it), so it's tempting to just treat the entire thing as a different type of identifier to make the space illegal. I can't think of why I wouldn't end up concatenating the $ and identifier in the semantic analyzer anyway.
Blzut3 wrote:
david_a00 wrote:For xlat, will both strings and numeric ids for actors / actions be supported going forward? That will also make parsing a bit more cumbersome but it's doable. For UWMF I don't see a point in supporting the old style since I think I have a strategic reserve of the world's UWMF maps at the moment :)
Action special numbers and thing ids are deprecated in 1.4. Both forms will be accepted in 1.4, but the numeric ids will be removed from the code some time prior to 2.0 (which is the version where any backwards compatibility issues will be considered regressions, so I will want to clean out any deprecated things before I'm "forced" to support them forever).
OK, I won't bother with supporting number ids. Makes things simpler.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

I think I have XLAT parsing done other than 'include' statements. How exactly do lump names work in ECWolf when it tries to resolve something? I saw something about namespaces versus absolute lump paths in the source. Do the absolute paths always use Unix slashes?

I think I know the answer to this, but does ECWolf theoretically support a mod entirely done in a single WAD file? I.E. multiple levels, an XLAT, mapinfo, the works. Does the answer depend on the level format (UWMF versus GameMaps)?


EDIT: What does "enable globalmeta;" do in the planet.txt XLAT? It looks like it triggers the use of data from other planes as metadata? The ECWolf code to handle it doesn't look like it's complete yet, so is it safe to ignore it?

EDIT2: I found the wiki page that answers most of my questions. Does ECWolf just walk the stack of loaded PK3/WADs when it tries to look up a lump?

EDIT3:
* The gameinfo documentation mentions a 'pagetime' property that I can't find in the source or base PK3 mapinfo files.
* What happens if 'music' is undefined in a map definition?
* What happens if all of the 'next' properties are undefined in a map definition?
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:EDIT: What does "enable globalmeta;" do in the planet.txt XLAT? It looks like it triggers the use of data from other planes as metadata? The ECWolf code to handle it doesn't look like it's complete yet, so is it safe to ignore it?
It is probably best to ignore it for now. The general gist is blake stone uses high bytes to signal various effects in the level and this tells ECWolf to handle them. The Blake Stone stuff is hidden behind a hidden cfg flag since it's all experimental and subject to change with no notice.
david_a00 wrote:EDIT2: I found the wiki page that answers most of my questions. Does ECWolf just walk the stack of loaded PK3/WADs when it tries to look up a lump?
Depends on the type of lump. Most things are done through a hash table lookup, but if it a cumulative script (MAPINFO, DECORATE, etc; but not Xlat) then a linear search is done.
david_a00 wrote:The gameinfo documentation mentions a 'pagetime' property that I can't find in the source or base PK3 mapinfo files.
Removed those a long time ago. Updated the page.
david_a00 wrote:What happens if 'music' is undefined in a map definition?
No music will play.
david_a00 wrote:What happens if all of the 'next' properties are undefined in a map definition?
I believe right now ECWolf will terminate. If you have a command prompt/terminal window open for ECWolf then you should see a message about there being no such map. Eventually ECWolf will be made to recover from this a little more gracefully, but it is illformed to have an exit and not have a next map.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

I found about a dozen properties in gameinfo that aren't documented; haven't looked at other blocks yet. Are there any properties that should be called out with "experimental" or just totally ignored from the documentation?

Also, what does ZScript mean for ECWolf?
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

david_a00 wrote:I found about a dozen properties in gameinfo that aren't documented; haven't looked at other blocks yet. Are there any properties that should be called out with "experimental" or just totally ignored from the documentation?
Might be. Since originally the Blake Stone stuff was developed separately I didn't feel a need to mark things as experimental. If the property exists on 1.3.3 then it should be fair game, otherwise if it's not clear if it's a Blake Stone thing list it here and I can tell you. I don't remember adding much though.
david_a00 wrote:Also, what does ZScript mean for ECWolf?
To be determined. The actor system (DECORATE dialect) in ECWolf is from scratch although heavily influenced by ZDoom. From what I've seen so far I don't see why ECWolf wouldn't get a ZScript dialect as well, but it needs to be stabilized in GZDoom first.
david_a00
Posts: 42
Joined: Wed Feb 17, 2016 4:07

Re: UWMF questions

Post by david_a00 »

I finished the map info documentation. I put in TODOs in Game Info for the new properties and for the Automap / Skill blocks. I didn't double-check the source with the other blocks, but the Wolf3D MapInfo at least doesn't use any properties of other blocks that aren't documented.
Blzut3
Developer
Developer
Posts: 491
Joined: Sun Jan 24, 2010 22:21

Re: UWMF questions

Post by Blzut3 »

Wow, I didn't realize I let the docs get that far behind! Some of those I was convinced you deleted the descriptions for, but the history proves otherwise. :)
Post Reply

Return to “ECWolf”