Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
GooberMan

ID24 - a new feature set standard

Recommended Posts

1 hour ago, boris said:

So how's that supposed to work? If a single member of the entire community is not OK with using a index for something then it can't be used?

 

The intention is to give the community space to develop their own feature sets and specs, similar to how MBF21 has had wider adoption. I can iterate on the wording here to make that clearer.

Share this post


Link to post
1 minute ago, Gothic said:

So, can you translate any color from the palette now, not just green?

 

The translation lumps require you to remap every palette index, even if it's to the same entry. So yes, you can translate any colour.

 

And yes, this should free up player sprites to use the full colour range better.

Share this post


Link to post
3 hours ago, Doomy__Doom said:

I don't see the point of JSON validation being required to hard fail on "metadata" field absence and/or contents. Community-wise, it's going to produce nothing but extra traffic to Editing Questions subforum with a typical answer being "copy sample from <wiki or smth link> and edit just the 'data' section".

 

JSON is not meant to be edited by hand. The point is that the tools will evolve to handle that for you, because you're not meant to edit JSON by hand. You're going to have a harder time explaining how commas work in a JSON document to community members, because you're not meant to edit JSON by hand.

Share this post


Link to post
Posted (edited)

Great, had a quick look at ID24 capabilities, not much is clear yet, but it looks very powerful. Let's wait for implementation in other source-ports (let's put a candle for source-port developers, now they have one more complevel to do). Or fix remaster, because that it is now very buggy and breaks at every second step (especially on custom wads).

 

Share this post


Link to post

My thoughts on reading some of the specs and watching the example video:

 

  1. The wad in the example should probably be included in the specs as a test-case. Maybe it is? I didn't see it.
  2. The impression that I'm getting is that Legacy of Rust was shipped as MBF21 for time-constraint reasons, and it'll become ID24 at some point. Going from multi-port-compatible to not and (hopefully) back again is going to be a bit of a weird trip... Which brings me to my third point:
  3. This new standard allows for some pretty cool stuff, but I can imagine that it's probably going to be a bit of a messy process getting other ports up to the new fire codes. On the plus side, the explicit specs and prominent example mod in Legacy of Rust will hopefully prevent another situation like GZDoom's initial struggles with MBF21 where they were kinda flying blind and still suffer the occasional bug to this day.

Share this post


Link to post
13 hours ago, Xaser said:

 

The purpose of this spec is to make it not a walled garden, i.e. explicitly document these features so they're available for community ports. Also see Gooberman's post above -- the cleanroom reimplementation is open source (from Rum & Raisin); id/Bethesda licensed it from Gooberman for use in the official port. Same process as when fraggle's DEHACKED code from Chocolate Doom was licensed for use in the Unity port a while back.

 

 

The standard includes definitions for the new expansion's monsters and weapons (taking all new slots, not replacing any old ones); the resource contains the sprites and sounds for these. Though nothing's stopping the community from making a Freedoom-esque libre resource either (that'd be rad).

I could see an alternate where you have a reduced ID24 standard which supports all baselane ID24 features minus anything in the ID24res file.

Share this post


Link to post

And now, another question: What's the licensing for the resources in the "ID24 resources" folder in the Google Drive? Are GPL-licensed source ports or the BSD-licensed Freedoom able to incorporate those?

 

Also, what's WATERMAP for? Maybe I missed something skimming through the docs, but I couldn't find anything mentioning that.

Share this post


Link to post
1 minute ago, Shepardus said:

Also, what's WATERMAP for? Maybe I missed something skimming through the docs, but I couldn't find anything mentioning that.

WATERMAP was included as part of Boom and is a predefined colormap for underwater effects. Most wads use an all-blue colormap because it looks a little better, but for full Boom compatibility WATERMAP is required.

 

from boomref.txt:

"WATERMAP is a colormap predefined by Boom which can be used to provide a blue-green tint while the player is under water. WATERMAP can be modified by pwads."

Share this post


Link to post

Hypothetically, if dsda-doom implemented ID24 and I wanted to ship a wad that uses ID24's new sky and colormap and music change features but none of the new Legacy of Rust things, could people play my wad in dsda-doom without id24res.wad?

Share this post


Link to post
Posted (edited)

None of that relies on anything in id24res.wad so I don't see a reason why not.

 

It would be up to whether DSDA-Doom's hypothetical implementation makes it a hard requirement or not.

Share this post


Link to post
Posted (edited)

I have a question : let's say if by the end of the year a Legacy of the Rust 2 comes out with a cool third new weapon. 

 

That means id24 should be updated? Because the actors logic is harcoded in the code, so the sources port can play such wad, right ? 

 

Still everything is a cool thing that important members of this community were involved and they came out with a new standard with cool features:) 

Share this post


Link to post
13 minutes ago, Walter confetti said:

Is this port specific?

Yes, of course. New features don't just magically appear in already-compiled programs; they have to be coded in a new version first, so only ports that have implemented ID24 standard will be compatible with ID24 stuff.

Share this post


Link to post
Posted (edited)
16 minutes ago, Walter confetti said:

Is this port specific?

 is an open standard, which is a superset of MBF21. Our "flying head" :) made some pages on doomwiki, I could suggest to start from the "id24" page :) 

 

 

For a 100% open implementation the assets need to be recreated , but the a actor logic is open. 

Share this post


Link to post
Posted (edited)

I'll point out that "new standards" adding new things is not an entirely new thing either; MBF back in the days added dogs (ripped from Wolfenstein 3D) and some miscellaneous other things (ripped from the Doom press release beta).

 

The community standard for MBF compatibility has been to ignore these and just let people reuse them as DEHACKED fodder; something which to be fair isn't needed anymore with DSDHacked's practically unlimited things and frames and so on. Though eventually, a free-libre replacement for the dog sprites was made by Nash and are now included in many ports.

 

I believe it's not impossible that such libre sprites could be made for the new props, weapons, and monsters (well, at least one prop doesn't need a new sprite at all, since it's just finally giving an actor to a sprite that's in the IWAD but left unused, something that Skulltag did first). They could be placeholders to ensure basic functionality (even if not visual fidelity) in case id24res.wad is not located.

Share this post


Link to post

Pretty sure the GAMECONF lump can identify whether a wad should be loaded with id24res as it defines complevel. How most ports will do this post-runtime, I am unsure but there are likely creative solutions available 

Share this post


Link to post
On 8/10/2024 at 7:13 AM, GooberMan said:

And then there’s the DeHackEd capabilities

  • Limits removed on weapon and ammo types (ie you can define entirely new ones)
  • Item pickups definable with parameters instead of hardcoded to sprites

And that's what I was willing to have in MBF21. Thank God, at least, you did it!

Share this post


Link to post

Okay! I split off the discussions about the concerns from people who seem to think you need Todd Howard's written permission to use a linedef special in 2024 in a different thread. Things are a bit hectic right now because this Doom re-release coincided with QuakeCon (where a lot of community members are hanging out currently, so they may not be immediately available for comment/replies/clarifications until next week) and there's undoubtedly going to be some patches and changes going forward. Now, please resume the discussion on ID24: feel free to ask any pertinent questions, express any concerns you have, demand better clarity from the documentation, whatever have you so long as you do it in a civil manner and in a way that doesn't follow baseless rumors, misinterpretations and off topic matters. But if you are going to once again post how this is the End Times because we can no longer mod the game how we please then I'll have my pet Cacodemon munch on your head, and then your soul. And then your post.

Share this post


Link to post
Just now, Dynamo said:

Okay! I split off the discussions about the concerns from people who seem to think you need Todd Howard's written permission to use a linedef special in 2024 in a different thread. Things are a bit hectic right now because this Doom re-release coincided with QuakeCon (where a lot of community members are hanging out currently, so they may not be immediately available for comment/replies/clarifications until next week) and there's undoubtedly going to be some patches and changes going forward. Now, please resume the discussion on ID24: feel free to ask any pertinent questions, express any concerns you have, demand better clarity from the documentation, whatever have you so long as you do it in a civil manner and in a way that doesn't follow baseless rumors, misinterpretations and off topic matters. But if you are going to once again post how this is the End Times because we can no longer mod the game how we please then I'll have my pet Cacodemon munch on your head, and then your soul. And then your post.

Hello Dynamo can you please be so kind to either remove "largely based on false rumors and misinterpretations" part of the title from the split or return the posts that were already asking "pertinent questions" to the main thread?

Mostly because if you look at for example the questions I asked here https://www.doomworld.com/forum/post/2831729, two of them Xaser answered with "we need to update the spec", which implies they are not "based on false rumors and misinterpretations" and were valid questions and the other two were not answered at all. 

Share this post


Link to post
2 minutes ago, Ravendesk said:

Mostly because if you look at for example the questions I asked here https://www.doomworld.com/forum/post/2831729, two of them Xaser answered with "we need to update the spec", which implies they are not "based on false rumors and misinterpretations" and were valid questions and the other two were not answered at all. 

I brought this post back to the main thread, I hope you can get the answers you seek in due time given the QC craze.

Share this post


Link to post
5 hours ago, Xaser said:

Just to clear up the main point of contention in this thread: id24res.wad is only required when using the new actors (LoR's weapons/monsters/props). Other features such as line specials, new JSON lumps, etc. are absolutely intended to work for players who don't have id24res.wad.

 

Doesn't this get a bit murky as far as detection goes? You could scan all the maps for Thing IDs, but for ports that permit scripting, it would be difficult to search all the relevant code for spawns. I would think some maps might crash at seemingly-random points.

 

I actually understood the way it was written (if you specify "ID24-complevel", then you must include id24res.wad [or a freely-licensed replacement]) to be the only sensible implementation. But I wonder if I'm missing something there.

Share this post


Link to post
8 minutes ago, JadingTsunami said:

 

Doesn't this get a bit murky as far as detection goes? You could scan all the maps for Thing IDs, but for ports that permit scripting, it would be difficult to search all the relevant code for spawns. I would think some maps might crash at seemingly-random points.

Yeah, this is something I don't quite understand, too. If source ports don't fail to load id24-compatible wad when then don't find id24res.wad, what happens if the wad actually required this resource. I cannot find a clear way to distinguish between "id24 but id24res is not needed" and "id24 with id24res required" in the spec so far.

 

And GAMECONF lump also only specifies one engine for "id24", so also no way to state if id24res.wad resources are required for the wad or not using this lump. The spec definitely needs some updates to clarify how this is supposed to work and how mappers can specify what exactly they need. It doesn't mention a possibility to have "a freely-licensed replacement" either at the moment. So I would also like to have Xaser clarify all these details when he is back.

Share this post


Link to post
Posted (edited)
19 minutes ago, JadingTsunami said:

Doesn't this get a bit murky as far as detection goes? You could scan all the maps for Thing IDs, but for ports that permit scripting, it would be difficult to search all the relevant code for spawns. I would think some maps might crash at seemingly-random points.

 

I'd expect that it's just a requirement for the WAD to work, not a legal requirement for ports that implement ID24. Similar to how MBF shipped an extra wad that was "required" for the MBF dogs. There's no easy way to differentiate between a MBF-compatible wad that uses the actual dogs as an enemy and one that does not use them.

 

I guess one thing that is not made clear is what should the port do if the res.wad is not found but the pwad actually uses the new Thing IDs... however, I expect every MBF21 port already has their own behavior when the sprite lumps for a Thing are not found.

Share this post


Link to post
Posted (edited)

 

On 8/10/2024 at 1:37 PM, Ravendesk said:

I'm very confused about this, can you please clarify how this works?

So, features were developed in R&R which is GPL, then they got merged to the official port (KEX), then were modified in KEX and then the updated features will be merged back to R&R.

Doesn't this mean that KEX contains GPL code and should be GPL as well? What's the point in merging things back to R&R then and not just releasing KEX source?

I'm probably misunderstanding something though :)

In lieu of the developers's response, let me try to answer the ones missed so far:

 

As i read it:

  • The definition of a new standard (Which later would be ID24) originated with R&R and was developed in the open from there, at some point calling it RNR24.
  • Gooberman used these to make things official for Id-software, licensing its code to them. Dual-licensing is perfectly possible and the preliminary 0.99.1 spec has various source code files available.
  • It doesn't mean that KEX uses GPL-code perse, Gooberman can license his code any way he wants. I can assume that certain bits are closed off, for instance, for the consoles, since those are under NDA. But that's more than likely just an output to those platforms and not inherently part of the spec itself since that's released.
  • R&R has a different target goal than ID24/Kex. R&R is more about improving the renderer through multithreading for the software renderer and doesn't have the kind of outputs Kex has (DX11, Vulkan, etc). Whereas Kex is a framework designed to bring old games to multiple platforms, including consoles.
14 hours ago, Ravendesk said:

3. Does reserving linedef specials range in a standard imply that the standard will be further revised and changed? If so, how this is supposed to affect source port compatibility and demo compatibility?

4. This is the most important one, I guess. What future do id24's developers see for id24 in community standards' development? For example, what can successor of MBF21 do with id24 features? Incorporate this standard fully? That seems dubious not only because id24 includes commercial things as part of a standard without providing free alternatives, but also because at least in my impression, the direction MBFXX was headed was not the direction id24 took. It seems like MBFXX wasn't going to just include a bunch of UDMF features (because there is already UDMF for that) and instead was focusing on fixing and refining mapper/user experience with existing feature set. While id24 seems like it went into a direction of mini-udmf feature grabbing.

Now if future MBFXX standard does not incorporate id24, does that mean we are getting branching standards yet again, with mbf and id24 going in completely different direction? That seems like additional headache for source port and tools (e.g. map editors, doomtools, etc) developers. While benefits are uncertain.

Or was this discussed and agreed with source port and tools developers beforehand and they are on board with supporting it and approve of this feature set and direction it took? That's not the impression I got from seeing their reactions to it, but maybe I lack the context.

  • 3: As far as i understand the spec, NO. These ranges are reserved for further use, which to me implies that they can't be added to ID24, but are there as a gateway to use if one implements yet another new spec (Say: NightDive26 or something). In that way, those authors won't have to re-write the law and can just start from where ID24 is leaving it as for now.
  • 4: The intent of ID24 (again, as far as i understand) is to bring all these community standards together in one spec. After all, to be ID24-compliant, you need to support MBF21. That's the only hard requirement i am reading. What i get from your question is that you treat ID24 as a singular entity where specs and resources are equal. This isn't the case. ID24's resources are commercial, yes, but you don't have to use them and yet you can still use all ID24's features because the tech specs (Which is the actual nitty-gritty) are out there. Any port author can implement those tech specs now and be ID24 compliant, with the only requirement that by doing so, you are also MBF21/MBF/DSDHacked/DEHEXTRA compliant. The issue seems to be that ID24res doesn't have a libre equivalent, but that does not stop anyone from implementing the ID24 spec. Using the new beastiary isn't a hard requirement. Using id24res isn't a hard requirement. And again, the spec isn't finalized. Obviously things will change, so lets weigh the spec when it is finalized.
  • 4.1: Xaser is part of the community, Goober is part of the community. I get your wish is that people like Kraflab, Graf Zahl, etc were consulted first before this was announced, but then again, this is a canon spec. Its ID-Software's, a company one. That to me carries a lot of weight, and on top of that, it respects the community works because it works on top of MBF21 and prior. Previous standards were by the community themselves and yes, it was better if the prominent members have their say. But a company doesn't have to adhere to that. So now the official code supports MBF21 and beyond.  Sure, a MBF27 can come, but the whole idea of ID24 is that MBF27 will work from ID24's baseline because it is mean't to be for both modders and the company alike. Ask yourself this: Why would you keep a separate standards path when the official path is done by both the community and the company?

EDIT: This post was a lot more meaty before the split, so i've pruned the split-worthy stuff and only focused on the straight questions given.

 

Edited by Redneckerz : A bit more clarificaton.

Share this post


Link to post

Going forward I think it'd be best if the answers to the questions being asked were actually given by the developers themselves: this way we can avoid further speculation that would lead us to re-enter the cycle of Instructions Unclear.

Share this post


Link to post

Sometimes the specs are very detailed and strict, and sometimes you get this:

Quote

Music formats

A complete ID24 implementation supports the following additional audio formats for music playback:

OGG Vorbis

Tracker

"Tracker"?

There are a ton of different tracker formats so which ones are expected to be supported? "All of them"? Or perhaps just those from the Library of Congress?

 

A somewhat reasonable expectation would be just the "big four" of module formats: MOD, XM, IT, and S3M. They represent the vast majority of the module scene (from a cursory glance at the 200 most popular files on modarchive.org, I noticed only one file in a different format, in position #175), the rest can be considered relatively obscure.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×