ZDBSP deletes unknown UDMF blocks

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!

ZDBSP deletes unknown UDMF blocks

Postby boris » Sun Oct 03, 2021 11:33 am

ZDBSP removes blocks it doesn't know from TEXTMAP. Top level fields will be preserved. Example:

Code: Select allExpand view
namespace = "zdoom";

my_global_field = 123;

my_global_section
{
   my_global_section_field_1 = "hello world";
   my_global_section_field_2 = 1.2;
}

my_global_section
{
   my_global_section_field_1 = "hello world 2";
   my_global_section_field_2 = 2.4;
}

// Other blocks like "thing", "vertex", "sector" etc. here


After the map is run through ZDBSP the "my_global_section" blocks are gone, only the "my_global_field" field is preserved.

Example map is attached.
You do not have the required permissions to view the files attached to this post.
boris
I post less than Manc and Hobo
 
Joined: 15 Jul 2003

Re: ZDBSP deletes unknown UDMF blocks

Postby Nash » Sun Oct 03, 2021 5:25 pm

For added context - the plan was to create a new custom block at the top level to store lightmap/ZDRay-related settings (like the sun color and direction). Currently this is impossible because ZDBSP nukes unknown top level blocks.
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 12:03 am

Please put this stuff in a different lump inside the map. There is zero guarantee that any of this can be preserved by tools as custom blocks have never been used by any port so tool support in general will be spotty as well.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 4:27 am

I'm not sure that is particular more reliable as at least the version of UDB on my computer didn't like seeing the output LIGHTMAP lump either.
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 4:40 am

Then UDB is not spec compliant - the spec clearly states that all lumps up to ENDMAP need to be preserved.
The entire setup was done this way so that tools can preserve such additional data.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 4:55 am

Ignoring new sections in the UDMF blocks is spec compliant?

What I'm trying to get at here is that we are breaking existing tools in any case. Might as well design the solution for what is the best place to put this data. That said, I don't know if that should be the TEXTMAP block or not.

By the way, do you know why ZDBSP updates the TEXTMAP block at all? Wouldn't this just be the input to ZDBSP while the other lumps it generates is the output?
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 5:02 am

The node builder messes around with the vertices, so it needs to write out the data again so that the generated nodes reference them correctly.

Regarding where to store stuff - the general rule should be that TEXTMAP should only contain the pure map data, everything machine generated that may be discarded by consumers of the map data should be put elsewhere.
Ultimately, adding custom data to the TEXTMAP is never defined in the spec, neither core UDMF nor ZDoom's extensions, so by adding such things you create a non-compliant map if we were strict about it.
This is something that other namespaces may add later, but none of the current ones do.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 5:30 am

So, basically if zdoom were to extend its feature set it would have to create a new namespace to be standard compliant with itself. This is pure W3C style gold. Can't we just promote it all to a living standard while we are at it? That way we can change anything we want as long as Chrome does it first. ;)

On a more serious note, the data here is map data. The output of ZDRay is the LIGHTMAP lump. Of course one could also argue that it doesn't belong in TEXTMAP as mapinfo stuff isn't stored there. Doom source ports aren't exactly famous for their consistency. :) In any case, I'm fine with whichever method works for boris as it is UDB that will be running in zdray and thus feeding it with input files and command line arguments.
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby Redneckerz » Mon Oct 04, 2021 5:46 am

dpJudas wrote:On a more serious note, the data here is map data. The output of ZDRay is the LIGHTMAP lump. Of course one could also argue that it doesn't belong in TEXTMAP as mapinfo stuff isn't stored there. Doom source ports aren't exactly famous for their consistency. :) In any case, I'm fine with whichever method works for boris as it is UDB that will be running in zdray and thus feeding it with input files and command line arguments.

It is kinda superfluous to state this but ill do it anyway - Whatever new and exciting additions you are adding to ZDRay (Having UDB in ZDRay? interesting!) please document these features. At the moment i am relying on your GitHub commits to update the current set of documentation that is available regarding ZDRay.

Don't get me wrong though. I for one am delighted that after December 2018, there is development on this again. :D
User avatar
Redneckerz
To it's ports i may have seen
Spotlight Team
 
Joined: 25 Nov 2019
Discord: Redneckerz#8399
Operating System: Windows 10/8.1/8/201x 64-bit
Graphics Processor: Intel (Modern GZDoom)

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 5:52 am

The main problem with adding a new section type to TEXTMAP is that it'd invalidate all tools not aware of it and also require any tool wishing to support editing this to be extended, because you couldn't even use a generic property pane to handle it.

Regarding the namespacing it was definitely mishandled, but that only became obvious when it was too late.
Ideally all the namespace should have defined is how numeric properties like thing editor numbers or line and sector specials need to be treated, but not being a global filter. Property namespaces should have been embedded into their name, e.g. zdoom:lightcolor = 0xff00ff or eternity:portaltag = 5.
Well, now it is too late. :(
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 6:02 am

@Redneckerz: ZDRay is still under development. Nothing is set in stone there yet - hence why I'm discussing with Nash, Boris and Graf where the best place is to put this data. :)

I can give you basic feedback of the current plan.

The TEXTMAP lump contain two new actor/thing types: static lights and light probes. ZDRay is a ZDBSP replacement. It performs exactly the duties as ZDBSP, except it also generates an additional LIGHTMAP lump. That lump contains the lightmap texture, the texture coordinate info that maps subsector, sides and 3d floors to locations in the texture, and light probe data for the sprites and 3d models.

The general idea is that UDB will get editing support for placing light probes and static lights. Then instead of calling zdbsp it will call zdray and the resulting wad will be ready to be consumed by GZDoom. That's partly why the documentation of zdray itself isn't particular important - it will just be an overview of the new arguments that weren't there already from zdbsp. This is all behind the scenes plumbing for the mappers. For them this is just a few new tools in UDB and the rest should be as they've always known doom mapping.

@Graf: My original idea was actually to read this new information from an input file, possibly the mapinfo file. I'm not sure if it is Nash or Boris that came up with the idea to put it into the TEXTMAP lump, but for me it basically comes down to what is most ideal for UDB. If it already has support for editing the other files in play then we could just put it in one those files instead.
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 6:06 am

For editing this stuff, placing things on the map and allow editing their properties is surely the best way. It's also the easiest for other tools to deal with.
You won't even need new actor types if you set them to "do not spawn" in the DoomEdNums section of MAPINFO.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 6:19 am

I just remembered one thing we haven't considered.

The current sun light source direction and color is done the dlight way: from a config file. But there's an alternative, which is the Unreal Engine 1 way. Here there is a ZoneInfo actor which contains the skybox linking info, ambient light info, gravity rules and so on. Each sector in an UE1 map is then linked to a specific ZoneInfo actor or using the map's default ZoneInfo actor. Using such an approach would sidestep the need for a new global section in the TEXTMAP lump.
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby dpJudas » Mon Oct 04, 2021 6:29 am

Another way of looking at this could be to simply put it on any sector with a sky texture. But then that'd be duplication of data. Or it could use a control sector for it. So many options!
dpJudas
 
 
 
Joined: 28 May 2016

Re: ZDBSP deletes unknown UDMF blocks

Postby Graf Zahl » Mon Oct 04, 2021 6:35 am

I'd suggest to do it the same way as the skybox pickers work, i.e. have one global setting and for sectors with special needs, place a link in the sector - unlike the skyboxes, where it had to use a thing due to lack of other options, you can just add a new property, called sunlighttid.

The sunlight is then defined as a separate thing you can put wherever you want.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Bugs

Who is online

Users browsing this forum: No registered users and 0 guests