GooberMan Posted August 10 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. 0 Share this post Link to post
GooberMan Posted August 10 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. 0 Share this post Link to post
GooberMan Posted August 10 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. 0 Share this post Link to post
DRON12261 Posted August 10 (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). 1 Share this post Link to post
Kinsie Posted August 10 My thoughts on reading some of the specs and watching the example video: The wad in the example should probably be included in the specs as a test-case. Maybe it is? I didn't see it. 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: 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. 6 Share this post Link to post
Lemon King Posted August 10 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. 1 Share this post Link to post
Ravendesk Posted August 11 To also add a few concerns from myself (mostly from a mapper perspective): 1. The inclusion of custom things from LoR in a standard looks very weird to me. The direction previous mapping standards (boom, mbf, mbf21) were taking was providing abstract set of features for mappers and not exact implementations of those things. Considering that these implementations currently require commercial assets, this creates a very weird restriction on what is supposed to be an open standard. Why can't these resources just be a part of LoR, which is a commercial release anyway, and not a part of a standard? Especially considering the implementation itself is mbf21-compliant. 2. Same with the requirement to have id24res.wad for id24 compatibility overall. Why do we need yet another iwad? It looks like a completely unnecessary thing to include in a "feature set", because feature set is abstract and should work with any resources. 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. 43 Share this post Link to post
Shepardus Posted August 11 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. 0 Share this post Link to post
plums Posted August 11 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." 2 Share this post Link to post
Benjogami Posted August 11 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? 0 Share this post Link to post
Trov Posted August 11 (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. 1 Share this post Link to post
LuciferSam86 Posted August 11 (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:) 0 Share this post Link to post
Gez Posted August 11 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. 1 Share this post Link to post
LuciferSam86 Posted August 11 (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. 1 Share this post Link to post
Gez Posted August 11 (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. 4 Share this post Link to post
Xaser Posted August 11 (edited) 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. We should definitely update the spec to make this more explicit -- it's the same concept as how features like fast doors are usable in Doom 1 despite being added to the engine for Doom 2 (since the two games share an engine/exe). A couple of folks have quoted this blurb from the spec: Quote All required data to support the ID24 specification is contained within the id24res.wad file. As this is a commercial product, note that illegal redistribution of this file is covered by normal copyright laws. Source ports should use their normal IWAD resolution rules to locate and load this WAD before the main IWAD when ID24 compatibility is enabled. This is stating: - Treat id24res.wad as an IWAD (I.e. don't copy/warez it plz) - Ports should autoload this wad when ID24 features are enabled so players don't have to do it themselves. We should add a piece clarifying that ports should not bomb out if the wad isn't present, and probably change that final line to read something like "Source ports should use their normal IWAD resolution rules to locate and load this WAD if present before the main IWAD when ID24 compatibility is enabled." Exact wording to be workshopped later; this post is a rough draft. :P 2 hours ago, boris said: What's a bit perplexing is that some of the ID24 features are not used at all in LoR A few of the spec's features are low-hanging fruit or fixups to grievances with existing features (e.g. the new music change linedefs), and the finale lump was written shortly before launch after LoR had already "gone gold" (though if we do a future update, it'll use the new lump instead of the quicky hardcoded finale the port currently uses). It's a spec for modders, with LoR being a showcase of a good chunk of the new stuff. Edited August 11 by Xaser 38 Share this post Link to post
Ralphis Posted August 11 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 0 Share this post Link to post
Dimon12321 Posted August 11 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! 0 Share this post Link to post
Dynamo Posted August 11 An impressive and frankly unexpected amount of catastrophizing in this thread, partly fueled by false rumors that have been disproven by GooberMan, Xaser, LexiMax, Kinsie etc. Such off topic derail benefits nobody, be it the people who worked on this new format or the people trying to understand more about it. While we clean up the mess and remove posts that have nothing to do with the topic at hand, I'll respectfully note a few points: a) if sass and sarcasm are the only motivators for posting on this thread, then don't bother posting at all, and b) there certainly are things that need to be cleared up, and the document for id24 itself needs to apparently be clearer on a few points, but spreading misinformation and catastrophizing is absolutely not the correct or productive way to go about it. So uh, yeah, time out! In the meantime I'll post links to some of the more useful explanatory posts here: 14 hours ago, LexiMax said: ID24 was delivered as a documented standard, with an open-source GPL implementation in Rum & Raisin Doom, and a new commercial IWAD that utilizes some of the features. This seems about as above-board and good faith as one could possibly be when delivering a set of new features. On 8/10/2024 at 9:45 AM, 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. 15 hours ago, Blast_Brothers said: I feel like I need a sanity check. What exactly does id24res.wad contain that is a required part of the ID24 standard, other than the data and assets for the new monsters and weapons? Because it seems like the quoted blurb is referring to that only. Things like colormap sectors are spelled out in the open format docs, and don't require any Bethesda-made assets to use, because they're implemented as changes to the map format itself, and not any copyrighted assets that make it possible. So outside of the new weapons and monsters, you don't need to buy the KEX port to target ID24 or play WADs that target it, correct? Yes, the above is correct. 9 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. 13 hours ago, Trov said: To me this is akin to the Super Shotgun in Doom 1. It's in the code (post-Thy Flesh Consumed) and most ports will let you select it in Doom 1 as long as the sprites are present. Got it? Good. Hopefully that spares us any more baseless concerns going forward, because they would get in the way of concerns that are actually legitimate, whatever and whichever they might be. EDIT: I just wanna make one thing clear before I reopen, which is that if your argument boils down to merely stating "there are many concerned people not speaking openly who agree with me", then don't bother posting. It's not that people's concerns outside of the forums don't matter, but wording it in such a manner is meant solely to add credibility to your personal claims in a way that cannot be verified. Either explain point by point what these off-site concerns are, or let sleeping dogs lie. Or in other words: you want to bring up concerns from people off-site? Sure cool go ahead and explain them. You want to merely state that you have people out there who agree with you and therefore you must be right? No thanks. 21 Share this post Link to post
Dynamo Posted August 11 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. 7 Share this post Link to post
Ravendesk Posted August 11 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. 13 Share this post Link to post
Dynamo Posted August 11 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. 1 Share this post Link to post
JadingTsunami Posted August 11 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. 1 Share this post Link to post
Ravendesk Posted August 11 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. 5 Share this post Link to post
Ferk Posted August 11 (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. 2 Share this post Link to post
Redneckerz Posted August 11 (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 August 11 by Redneckerz : A bit more clarificaton. 9 Share this post Link to post
Dynamo Posted August 11 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. 9 Share this post Link to post
Gez Posted August 11 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. 1 Share this post Link to post