UWMF questions
Moderator: Blzut3
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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?
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?
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
They can be used anywhere in the global scope.david_a00 wrote:* Can 'include' statements only occur as the first line in the file?
Based on the game being played the default translator is the one that ecwolf.pk3 specifies in iwadinfo.txt.david_a00 wrote:* What exactly is the default translator?
Counterclockwise search (starting at east). First one wins.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?
NSEW.david_a00 wrote:* What does "adjacent" mean in the above context? NSEW or diagonals as well?
This is to support a vanilla hack that some map authors used to make walls that you can walk through.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?
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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
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
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
Yes.david_a00 wrote:I assume more than one other translator can be included?
Like this.david_a00 wrote: B.Things
A.Things
A.Tiles
B.Tiles
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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.
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.
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
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:which, uh, maybe was premature because I forgot that the released version doesn't do that yet.
This was an oversight and is now fixed. Thanks!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?
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.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 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.
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
Is the action special name a quoted string in this context?Blzut3 wrote:This was an oversight and is now fixed. Thanks!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?
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.Blzut3 wrote: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.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 did keep your comment in mind with the change to changetrigger though.
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
$ is a token by itself? What does it actually signify?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.
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
Yep. Unless you think it would be better to do otherwise (not to late to change this).david_a00 wrote:Is the action special name a quoted string in this context?
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: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.
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: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
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 wrote:$ is a token by itself? What does it actually signify?
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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:Yep. Unless you think it would be better to do otherwise (not to late to change this).david_a00 wrote:Is the action special name a quoted string in this context?
It would have been best if I had looked at what the code does in the last couple of monthsBlzut3 wrote: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: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.
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.
OK, I won't bother with supporting number ids. Makes things simpler.Blzut3 wrote: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: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
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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?
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
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: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?
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: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?
Removed those a long time ago. Updated the page.david_a00 wrote:The gameinfo documentation mentions a 'pagetime' property that I can't find in the source or base PK3 mapinfo files.
No music will play.david_a00 wrote:What happens if 'music' is 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 wrote:What happens if all of the 'next' properties are undefined in a map definition?
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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?
Also, what does ZScript mean for ECWolf?
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
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: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?
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 wrote:Also, what does ZScript mean for ECWolf?
-
- Posts: 42
- Joined: Wed Feb 17, 2016 4:07
Re: UWMF questions
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.
-
- Developer
- Posts: 491
- Joined: Sun Jan 24, 2010 22:21
Re: UWMF questions
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.