ZDBSP deletes unknown UDMF blocks

[boris]

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

Code: Select all

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.

[Nash]

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.

[Graf Zahl]

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.

[dpJudas]

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.

[Graf Zahl]

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.

[dpJudas]

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?

[Graf Zahl]

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.

[dpJudas]

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.

[Redneckerz]

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.

[Graf Zahl]

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.

[dpJudas]

@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.

[Graf Zahl]

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.

[dpJudas]

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]

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!

[Graf Zahl]

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.