Support for ID24 format and the Legacy of Rust Intermission Map Screen

[OpenRift412]

A new remaster, a new episode, and a new format. I'm sure you guys have heard the news already. You can learn more about the info collected so far on ID24 format here. Thankfully the new additions over MBF21 aren't too drastic, so I'd imagine adding this would be within scope, right? I don't know if the list of features from doomwiki is complete or not, but it's a start, I suppose.

[NightFright2k19]

Strong argument here: It's official. I have only played one level in Woof right now since I want to experience it in the original port first, but ofc it's desirable to make it work and look as closely to the Nightdive port as possible.

Long story short: I second that motion.

[rfomin]

The ID24 additions seem purely cosmetic, Legacy of Rust should be playable in MBF21 ports (it even contains COMPLVL lump). I've played a few levels, no issues so far.

I think we can implement some of the ID24 additions, but maybe we should wait a bit for the promised official documentation.

[rfomin]

Documentation is here: [doomworld]

[NightFright2k19]

It's more about stuff like the new intermission screens, status bar expansions and other "side effects". The maps themselves work just fine.

[SladeWilson52]

I completely agree with this. I wonder if this also means we can have the optimized renderer from the KEX port and Rum and Raisin DOOM? They have the same renderer, I think.

[OpenRift412]

I completely agree with this. I wonder if this also means we can have the optimized renderer from the KEX port and Rum and Raisin DOOM? They have the same renderer, I think.

That's a lot easier said than done. I think the renderer in Woof is pretty good as-is for the most part.

[NightFright2k19]

Please don't try to push this towards turning it into a different port. Woof is doing quite a few things a LOT better than Nightdive. It can and should stay that way. Besides, that thing has just been released and is, frankly spoken, still quite flawed.

[ceski-1]

There are some cool features like the transposed backbuffer and multi-threaded renderer, but yes, that's a different topic for a different time. The focus here is supporting the cosmetic features of LoR.

[fabiangreffrath]

Isn't this solved now?

[OpenRift412]

Isn't this solved now?

Sort of. Should I keep this open for the ID24 milestone though?

[fabiangreffrath]

Not sure which milestone you mean. AFAIK all that's still missing is support for the KEX-style HUD definitions, and that's already tracked n a separate issue.

[OpenRift412]

Not sure which milestone you mean. AFAIK all that's still missing is support for the KEX-style HUD definitions, and that's already tracked n a separate issue.

I moreso meant the overall feature set standard of ID24, as outlined on Doomworld.

[fabiangreffrath]

Tl;dr so what's still missing for full id24 format support?

[elf-alchemist]

Tl;dr so what's still missing for full id24 format support?

So it would seem that what is next is GAMECONF, DEMOLOOP, the endfinale lump format and player translations.

And the bigger bullet point ones are id24 map format, ID24HACKED and ID24HACKED hashing

All from here.

[rfomin]

So it would seem that what is next is GAMECONF, DEMOLOOP, the endfinale lump format and player translations.

GAMECONF defines a lot of complevels that I think is unnecessary. If we implement it, it would be partial. Other additions seem reasonable.

And the bigger bullet point ones are id24 map format, ID24HACKED and ID24HACKED hashing

I think we will implement some parts of the map format (without new content). I don't like DEHACKED additions, we will probably implement some form of DECORATE (hopefully part of MBF25).

[elf-alchemist]

I think we will implement some parts of the map format (without new content). I don't like DEHACKED additions, we will probably implement some form of DECORATE (hopefully part of MBF25).

This seems ill-advised, unless you plan on actively coordinating with other port developers and the community at large which features to implement and not implement. I'm pretty certain that hobomaster22 is already on his way to implement most mapping and dehacked features on Helion already, last I checked. Also I'm not entirely sure why DECORATE or something like it would be fitting for Woof or the next MBFxy, but okay.

[rfomin]

This seems ill-advised, unless you plan on actively coordinating with other port developers and the community at large which features to implement and not implement. I'm pretty certain that hobomaster22 is already on his way to implement most mapping and dehacked features on Helion already, last I checked. Also I'm not entirely sure why DECORATE or something like it would be fitting for Woof or the next MBFxy, but okay.

There is some coordination going on behind the scenes, although not very active. Helion also supports DECORATE in some capacity, so it's not a problem for them.

I think even more extensions to DEHAKED are not a good idea. Sure, if it is going to be widely adapted, we would have to implement it.

[elf-alchemist]

There is some coordination going on behind the scenes, although not very active.

I really wanna try and see this in the most positive way possible, but this divergency in spec leaves me feeling a great unease. If such a discussion was at least publicly readable, about what to add or remove, and left everything absolutely explicit about which features are going to be picked and chosen, it'd be easier to understand.

Helion also supports DECORATE in some capacity, so it's not a problem for them.
I think even more extensions to DEHAKED are not a good idea. Sure, if it is going to be widely adapted, we would have to implement it.

My point was about DECORATE in Woof or other such Boom-family, or just any non-ZDoom-family ports. Helion is fine it does whatever it wants, but this feels like a shame to not stick to the more "fundamental" modding tool, instead of jumping to a completely new scripting system. Would it even be the same DECORATE so older mods could remain compatible? Will it be a formal spec with a proper grammar and well thought-out features that'll be not only well versioned but also extremely well documented?

As much as I have my criticisms of Bethesda and idSoftware and Nightdive for how this port and it's accompanying features were handled, putting a fork halfway on the road to ID24 doesn't sound like it bodes well. As far as I understand it, and correct me if I'm wrong don't most features in ID24 not exactly conflict so much with the already existing MBFxy spec that they have to be wholely remade? And could semi-easily readjust to accommodate all of ID24 as a base?

I'd like to be comfortable with the idea of a given formal specification not being followed in it's entirety, but the only way I could see that, is if a newer publicly discussed spec explicitly defined which features are entirely ignored, because that would fundamentally do what Bethesda didn't, it would actually involve the community in the design of the new complevel and it's features, this behind the scenes stuff is exactly what caused 99% of the ID24 drama in the first place, because noone was actually informed of anything before the floodgates opened. And had the community at large known beforehand what was being discussed for that spec most of issues that Doomworld had wouldn't have existed at all or would've been resolved before they became issues at all. As a community member like any other, and more personally as a fan of this port in specific, I'd like to be able to understand why things are happening the way they are, or maybe even be given the option to have some input or feedback before anything is truly finalized. Much as I don't believe it was right for Beth to leave the entire community in the dark, then suddenly dropping an entire feature-set on everyone. It doesn't seem right either to implicitly skip on features that people could definitely make real good use of, at least not without clear understanding the reasoning beforehand.

I'm sorry if I'm being out-of-line, here.

[rfomin]

Well, it's still in the early stages, so there's not much to discuss yet 😄 Sure, we'll make thread on DoomWorld when the time comes.

Would it even be the same DECORATE so older mods could remain compatible? Will it be a formal spec with a proper grammar and well thought-out features that'll be not only well versioned but also extremely well documented?

Early document if you are interested: https://bitbucket.org/Blzut3/declarate/src/master/docs/language.md

[elf-alchemist]

I see. Sorry for my overly anxious response, here. I'll take a look into this Declarate as soon as I have the time.

[rfomin]

I'll take a look into this Declarate as soon as I have the time.

It's still very early, I don't know what will be implemented. Maybe we will end up with ID24HACKED extensions if people like them. We'll see.