ID24 - a new feature set standard

[dpJudas]

3 hours ago, Ferk said:

What does "breaking older parsers" mean here?

I mean that the config files uses a syntax where you can't know when a statement or directive ends. If you add another feature by adding a new keyword then all older versions can't just ignore it - the rest of the file more or less falls apart due to how it reads tokens. This is in contrast to CSS, where the properties are always parsed in such a way that you can add new properties that older browsers don't understand. JSON and YAML also don't have this problem.

[Christopher Brown]

@GooberMan Forgive me if this has already been asked within the 20+ pages of the thread, but are there any goals to bring friendlies to ID24 eventually, and if so is that likely to make its way to the official port? I have a level set I'm planning to make that would revolve around friendly monsters, and I'd love for people to be able to play it in the official port once it's done. That said, I'd definitely prefer to know what compatibility to shoot for in advance before I start mapping for it.

[Redneckerz]

On 8/27/2024 at 11:39 AM, Professor Hastig said:

After reading through the entire spec, here's my take about some parts of ID24:

 

* using JSON for user defined files is not the best idea IMHO. Even for experienced people, creating a valid JSON file in a text editor is hard, the format is very strict and unforgiving. Yes, it is easy to handle in the engine but creating these files can be very annoying.

I know this is addressed but i just want to capitalize - JSON is mean't for automated editing, not the other way around. 

 

This is only annoying if you never used JSON. Its a universal standard, if anything i'd consider that one of ID24's stronger points because it forces folks to accept a universal standard that anyone could understand.

On 8/27/2024 at 11:39 AM, Professor Hastig said:

What I am missing here so far is some input from the port authors. The only one who responded was kraflab and he never went into details about the technical side.

That was not really the intent of his initial contribution, was it now? In fact, a technical critique is what i would have expected. 

 

Its why i want to hear @rfomin or @fabian on the matter. What does this do for their respective projects? Or what does @Julia Nechaevskaya say on the ID24 standard?

3 hours ago, Christopher Brown said:

@GooberMan Forgive me if this has already been asked within the 20+ pages of the thread, but are there any goals to bring friendlies to ID24 eventually, and if so is that likely to make its way to the official port? I have a level set I'm planning to make that would revolve around friendly monsters, and I'd love for people to be able to play it in the official port once it's done. That said, I'd definitely prefer to know what compatibility to shoot for in advance before I start mapping for it.

Regarding the bolded: The basis is MBF21, so one could always target that. If MBF21 doesn't support friendlies, then that's another matter. Having said that, friendlies are a severely underutilized MBF-feature, afaik.

[Ar_e_en]

Questions about the new standard (that may or may not have been answered before): The new Bethesda Doom port has implemented various previous mapping standards in a cleanroom environment, because they didn't want to mess with the various original open-source standards, but what about the new ID24 standard? Is this new standard open-source, or is it proprietary? If others want to implement this new standard in their own ports - will they also have to come up with their own cleanroom interpretations?

[Gez]

4 minutes ago, Ar_e_en said:

Questions about the new standard (that may or may not have been answered before): The new Bethesda Doom port has implemented various previous mapping standards in a cleanroom environment, because they didn't want to mess with the various original open-source standards, but what about the new ID24 standard? Is this new standard open-source, or is it proprietary? If others want to implement this new standard in their own ports - will they also have to come up with their own cleanroom interpretations?

1. Best I can tell, Bethesda was not really involved in this new port outside of being the publisher as usual. It's id + Nightdive + MachineGames + outside contractors.
2. Speaking of outside contractors, the implementation of Boom+MBF+MUSINFO+UMAPINFO+MBF21+DSDHacked was done by @GooberMan for Rum and Raisin.
3. The implementation is open-source in R&R, a well as in the actor reference code here: https://drive.google.com/drive/folders/1Q9GHoykGVJ7JONzYDXStM_vRdceL4Vi5

[rfomin]

42 minutes ago, Redneckerz said:

Its why i want to hear @rfomin or @fabian on the matter. What does this do for their respective projects?

 

For full Legacy of Rust support, we will probably implement some of the cosmetics, intermissions and skies.

 

There is an open source ID24 implementation in Rum and Rasin, but maybe incomplete? Not sure.

Supporting another implementation of Boom/MBF/MBF21 standards for demo compatibility with Kex port is cumbersome, I doubt it will happen.

[Macil]

5 hours ago, Christopher Brown said:

@GooberMan Forgive me if this has already been asked within the 20+ pages of the thread, but are there any goals to bring friendlies to ID24 eventually, and if so is that likely to make its way to the official port? I have a level set I'm planning to make that would revolve around friendly monsters, and I'd love for people to be able to play it in the official port once it's done. That said, I'd definitely prefer to know what compatibility to shoot for in advance before I start mapping for it.

I think it was stated somewhere in the thread that friendlies are part of the standard but it's a part the official port doesn't currently support.

[Redneckerz]

18 minutes ago, rfomin said:

 

For full Legacy of Rust support, we will probably implement some of the cosmetics, intermissions and skies.

 

There is an open source ID24 implementation in Rum and Rasin, but maybe incomplete? Not sure.

Supporting another implementation of Boom/MBF/MBF21 standards for demo compatibility with Kex port is cumbersome, I doubt it will happen.

Enlighten me: What exactly is cumbersome about something which builds from MBF21? No attack, just curiosity.

Demo compat is limited to Vanilla.

[Xaser]

1 hour ago, rfomin said:

Supporting another implementation of Boom/MBF/MBF21 standards for demo compatibility with Kex port is cumbersome, I doubt it will happen.

 

Demo compatibility with Kex/R&R's Boom/etc. implementation is not something that's required (or encouraged) by the ID24 spec -- community ports ought to build atop their own Boom/MBF21/etc. implementations.

[Gez]

I don't think you're talking about the same thing. rfomin mentioned demo compatibility with Kex port, which is not part of the ID24 feature specs. There is indeed no reason to duplicate all the Boom, MBF, and MBF21 specs just to have compatibility with demos from the new official engine; that engine is not really going to be used for demos.

[rfomin]

1 hour ago, Gez said:

There is indeed no reason to duplicate all the Boom, MBF, and MBF21 specs just to have compatibility with demos from the new official engine; that engine is not really going to be used for demos.

 

Yes, that's what I meant, thanks.

 

Overall, we're going to implement some/most of the cosmetic features. About things that affect gameplay, I'm not sure. There doesn't seem to be a consensus in the community. I haven't read the whole thread.

[Redneckerz]

17 minutes ago, rfomin said:

 

Yes, that's what I meant, thanks.

 

Overall, we're going to implement some/most of the cosmetic features. About things that affect gameplay, I'm not sure. There doesn't seem to be a consensus in the community. I haven't read the whole thread.

Mostly things like the per-sector colormap stuff and morphable floors, so basically code specials.

 

As i read your response (And please correct me if i am wrong/is not indicative of the Woof team as a whole) it reads to me like you are going to follow and not lead by example for now.

[rfomin]

5 minutes ago, Redneckerz said:

As i read your response (And please correct me if i am wrong/is not indicative of the Woof team as a whole) it reads to me like you are going to follow and not lead by example for now.

 

I don't know. Honestly, I don't have much time these days. I don't represent all contributors to Woof, I'm only talking about what I'm going to do myself.

[Julia Nechaevskaya]

6 hours ago, Redneckerz said:

Its why i want to hear @rfomin or @fabian on the matter. What does this do for their respective projects? Or what does @Julia Nechaevskaya say on the ID24 standard?

 

Nothing from my side, really. Both Crispy and Inter doesn't have support for BOOM and higher mapping standards, except for few specific lumps (ANIMATED and SWITCHES) and few line specials, and not really sure will it be ever planned. Speaking for myself, I'm too "vanilla" person in terms of mapping standards, and simply have no interest for learning and working on other standards. Speaking for Woof, better ask Fabian and Roman, as they know much better how to make great things. 🙂

[eidolon_]

On 8/21/2024 at 10:14 AM, bartekmil said:

Any chance for Game Music Emu?

 

Developer on Ring Racers and SRB2 here. We don't have much stake in the complevel discussion naturally, but after reviewing our third party dependencies for Ring Racers before launch, we discovered Game Music Emu/GME includes some code that is under the old MAME license before MAME was relicensed/rewritten. We couldn't verify if including it would allow us to remain compliant with GPL 2 nor if GME is itself compliant, so we've decided to drop it. This may be of concern for Doom ports that support it currently. We also ran into issues with people using their Linux distro system packages for it, where YM2612 emulation was provided by Nuked by default, and that is far too slow for realtime playback for many systems. Above all, Kex Doom would especially not be able to provide GME, so I can't imagine they'd want to add support anyway.

 

Tangentially, given module playback support is AFAIK currently a requirement for the ID24 draft, and KEX Doom uses LibOpenMPT, I'd like to suggest libxmp-lite as an alternative to it. The lite version is MIT licensed and only supports The Big 4 module formats, but is very easy to vendor in directly, making it a good option for ports that run on embedded targets and legacy consoles. LibOpenMPT isn't license-encumbered, but it is quite a bit larger in scope and includes formats hardly anyone would likely ship a megawad if Ogg Vorbis is available. I know many ports already include LibOpenMPT but I figured I'd bring it up since we're using xmp-lite instead in Ring Racers and the next version of SRB2.

[Lemon King]

On 8/30/2024 at 5:27 AM, Redneckerz said:

I know this is addressed but i just want to capitalize - JSON is mean't for automated editing, not the other way around. 

 

This is only annoying if you never used JSON. Its a universal standard, if anything i'd consider that one of ID24's stronger points because it forces folks to accept a universal standard that anyone could understand.

That was not really the intent of his initial contribution, was it now? In fact, a technical critique is what i would have expected. 

Its a great format to have officially supported by the engine and can finally break away from the linear text file formats that have been used for years. JSONC would be better to have in this case to allow some comments to be added to JSON files - if we can see that happen for ID24 1.0.

[rfomin]

When implementing ID24 intermissions for Woof, I encountered an ambiguity in the spec:

 

Quote

The map number accessible for condition checking is dependent on whether the victory screen is currently displaying an exit animation or an enter animation. If it is an exit animation, the map number corresponds to the map being played; if it is an enter animation, the map number corresponds to the map about to be entered. The map number itself is defined through other means, including but not limited to UMAPINFO, and is outside of the scope of this document to define.

 

From my expiriments with the KEX port, it seems that the map number is determined by the order of the map definitions in the UMAPINFO lump, the episode ends when another "episode" field is encountered. The "next" and "nextsecret" fields are ignored when determining map numbers.

 

I assume the concept of “map numbers” came about because of DMAPINFO support in the KEX port? What is the main mapinfo standard for ID24? I propose to define map numbers only from UMAPINFO.

[The Almighty Egg]

Apparently ID24 supports tracker files, that's p cool I think.

[Gez]

ID24 introduces many music changing line types:

2087	W1	Change music and make it loop, reset to looping default if no track defined.
2088	WR	Change music and make it loop, reset to looping default if no track defined.
2089	S1	Change music and make it loop, reset to looping default if no track defined.
2090	SR	Change music and make it loop, reset to looping default if no track defined.
2091	G1	Change music and make it loop, reset to looping default if no track defined.
2092	GR	Change music and make it loop, reset to looping default if no track defined.
2093	W1	Change music and make it play only once, reset to looping default if no track defined.
2094	WR	Change music and make it play only once, reset to looping default if no track defined.
2095	S1	Change music and make it play only once, reset to looping default if no track defined.
2096	SR	Change music and make it play only once, reset to looping default if no track defined.
2097	G1	Change music and make it play only once, reset to looping default if no track defined.
2098	GR	Change music and make it play only once, reset to looping default if no track defined.

I'm wondering about the "play only once" lines. What's supposed to happen after it finishes playing that track? Does it just stop playing music altogether, or does it go back to looping the level's default track?

[Trov]

On 9/1/2024 at 9:14 PM, rfomin said:

When implementing ID24 intermissions for Woof, I encountered an ambiguity in the spec:

 

 

From my expiriments with the KEX port, it seems that the map number is determined by the order of the map definitions in the UMAPINFO lump, the episode ends when another "episode" field is encountered. The "next" and "nextsecret" fields are ignored when determining map numbers.

 

I assume the concept of “map numbers” came about because of DMAPINFO support in the KEX port? What is the main mapinfo standard for ID24? I propose to define map numbers only from UMAPINFO.

I think it came about because Kex Doom allows map lumpnames that are not MAPxx or ExMx, which is not something DSDA or Woof allows with UMAPINFO.

I guess the idea is the map number is more difficult to determine when when maps can have arbitrary lump names so they went with the ExMx style when episodes are defined in UMAPINFO. You may notice this affects IDCLEV as well.

 

Next/nextsecret might not be sufficient to determine map numbering because of the possibility of 2 parallel branching paths.

Edited September 3 by Trov

[rfomin]

52 minutes ago, Trov said:

I guess the idea is the map number is more difficult to determine when when maps can have arbitrary lump names so they went with the ExMx style when episodes are defined in UMAPINFO. You may notice this affects IDCLEV as well.

 

It is not difficult to determine, quite the opposite. If the lumps are in ExMy format, check the condition with y, if in MAPxx format, check xx. “Map numbers” are difficult to determine for ports like DSDA and Woof because the method the KEX port uses is not documented:

 

Quote

The map number itself is defined through other means, including but not limited to UMAPINFO, and is outside of the scope of this document to define.

 

[Trov]

2 minutes ago, rfomin said:

If the lumps are in ExMy format, check the condition with y, if in MAPxx format, check xx

What I was saying is that Kex allows lumps that are not either of those formats which puts a wrench in things.

[yum13241]

Which is something ZDoom figured out a long time ago. It did it by just not allowing `idclev` for non ExMy/MAPzz maps! Then you'd just need a map command since Kex already has a console, and other ports can make it a menu option or something.

[Trov]

Sure, but that doesn't help things like demos' level/episode byte or the new intermission definitions referencing by a map number.

[ixfd64]

Silly question: how does ID24 compare to UDMF? Is one a subset of another? Or are there things that ID24 can do that UDMF cannot (and vice versa)?

[esselfortium]

ID24 is unrelated to UDMF. It's an extension of the Boom -> MBF -> MBF21 tree.

[ixfd64]

Ah I see. I take it that there's no need to abandon UDMF as each format has its own merits.

[Gez]

1 hour ago, yum13241 said:

Which is something ZDoom figured out a long time ago. It did it by just not allowing `idclev` for non ExMy/MAPzz maps! Then you'd just need a map command since Kex already has a console, and other ports can make it a menu option or something.

You can just use the LevelNum property in your map definition...

[msx2plus]

On 8/31/2024 at 7:42 PM, eidolon_ said:

I'd like to suggest libxmp-lite as an alternative to it.

as long as it supports modplug-extended IT files (stereo samples etc) with good accuracy, it seems like a no-brainer

[Lizardcommando]

Ok, sorry if this has been answered in this thread already (not even really sure if this fits in this specific thread or not), but I'm still very confused as to what wad needs to be included in the GAMECONF lump if you want to use any of the Legacy of Rust stuff in the KEX Engine. Is the pwadfiles section supposed to have the id1.wad file there or is it the id24res.wad file?
 

Spoiler

{
  "type": "gameconf",
  "version": "1.0.0",
  "metadata": { },
  "data":
  {
    "title": "Spelunker",
    "author": "Clifftron1986 aka Lizardcommando",
    "description": "There's a cave to explore that has demons and stuff",
    "version": "2.0",
    "iwad": "doom2.wad",
	"pwadfiles": "id1.wad",
    "dehfiles": null,
    "executable": "id24",
	"mode": "commercial",
    "options": null
  }
}