UDMF woof namespace#2626
Conversation
rfomin
left a comment
rfomin
left a comment
There was a problem hiding this comment.
Thank you for your efforts. I haven't read the full PR yet, but the additions seem reasonable and will likely be accepted in other ports. Can we rename it mbf2y? It will remain unfinished for a while, but we also have a half-finished declarate.
| II.A : Storage and Retrieval of Data | ||
| ------------------------------------ | ||
|
|
||
| Any TEXTMAP lump in the "Woof" namespace must be encoded in UTF-8. Otherwise, |
There was a problem hiding this comment.
We don't support UTF-8. As far as I know, none of the other ports or editors support it in UDMF either. I don't think it's necessary.
| ----------------------------------- | ||
|
|
||
| For the purposes of demo-accuracy this namespace requires support for the | ||
| ZNODES lumps. While BLOCKMAP and REJECT |
| alpha = <float>; // Opacity percentage. Default = 1.0. | ||
| tranmap = <string>; // Custom translucency map lump. Overides alpha. | ||
|
|
||
| comment = <string>; // A comment. No special meaning is attached to it. |
There was a problem hiding this comment.
Why do we need comment? Does UDMF support regular comments in code?
There was a problem hiding this comment.
It's a field intended for editors to store on the level information itself. It's just to explicitly say that we will ignore it during parsing.
|
What's missing here? |
I'm currently looking over some other things about the UDMF base spec with boris and Quasar, before marking this as ready. There are some changes needed on upstream UDB, which I may have to change and retest this current CFG. |
|
I've removed the UDB config for now, I'll make PR to add it later on. Otherwise this is fine to merge for 16.0.0 |
|
|
||
| int32_t lump = W_CheckNumForName(udmf_linedefs[i].tranmap); | ||
| if (lump >= 0 && W_LumpLength(lump) == 256 * 256) | ||
| if (lump != NO_INDEX && W_LumpLength(lump) == tranmap_lump_length) |
There was a problem hiding this comment.
Not sure if it's a good idea to allocate the line's tranmap as PU_CACHE?
Also, why check for demo_compatibility a few lines later in the UDMF parser?
fabiangreffrath
left a comment
fabiangreffrath
left a comment
There was a problem hiding this comment.
Fine with me, thank you!
What does @rfomin say?
There is still an unanswered question about UTF-8 in the spec. We don't support it in the parser. Personally, I don't think it's necessary. Just for comments? |
@elf-alchemist could you please clarify this or just change it to ascii? |
|
I'm still not too sure about this one. To be honest, I wouldn't want to introduce a Woof-exclusive name space that's feature-incompatible with other ports. We already have this situation with dsda-doom and I would say that it's an unfortunate one. We should learn from it and not repeat mistakes. So, how are the chances that the features introduced here will make it into a new mbf2y mapping standard? And should we wait until this will be formally specified? |
I agree, that's exactly why I made the separate Woof namespace. I do not believe that any Doom source port should be denied the right to have its own, exclusive modding features, however simple, complex, small or large these features may be. I firmly believe that for the sake of the health of the Doom modding scene we should be clearer and more respectful of the boundary between features considered port-agnostic or port-exclusive. Woof, for all the general restraint and conservative nature of its design, is no less worthy of the right to own its exclusive features than any other source port, be it DSDA, Helion, Odamex or UZD, and in my opinion the creation of a bespoke namespace, not supported by any other port, is an important step in expressing those boundaries cleanly. In turn, as I want to establish the Woof namespace as ours, I do not wish for the DSDA namespace to have added support in any other source port going forward, with the same logic applying to really all current port-exclusive namespaces, we should respect each others boundaries and let exclusive features remain exclusive until any official notice of a cross-port standard adopting said features is made. The only reason I even used it in the first place is because it was convenient enough to make a map on it using UDB. Though, you will be happy to know that, yes, most of the things implemented on these past few UDMF runs have been in the name of establishing the viability of many mapping features in a simpler purist port, for the sake of the future cross-port namespace, there's definitely some overlap, for when the new mapping standard comes out. If anything, you could think of this as a 'prototype' of sorts. I can see why it is that we even reached this mess in the first place. We have no current established cross-port UDMF standard that takes advantage of the possibilities provided by the text-based format, it certainly put pressure in the few port-exclusive namespaces that have existed so far, into being partly adopted in other ports that shouldn't really be doing that. And by all means, I fully agree with, and will push for, a proper cross-port namespace so that the past mistakes aren't repeated, I just also believe that a cross-port standard doesn't have to come in the way, or at the cost, of port-exclusivity. As it stands, there's very little in the way forward in terms of getting wide cross-port UDMF adoption, I need to iron out some details with Quasar and Boris beforehand, but its all to come sooner, rather than later. |
|
Hm, so you say we can have our own "Woof" namespace and no matter if this will become the new "mbf2y" standard - or a subset or superset of it - adding that new standard will merely require a new check in |
|
Indeed, that is the practical outcome. Thank you 🙂 |
3 participants
Early draft
Final few major changes to UDMF for 16.0.0
Introducing a dedicated namespace, a handful of new props and UDB config