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

ID24 - a new feature set standard

Recommended Posts

Posted (edited)
1 hour ago, LexiMax said:

short of putting the all of the resource files under creative commons

Doing that would have actually solved a lot of problems with the spec. Imo that would be the correct approach to releasing new things.

 

And this is actually a thing that I was going to elaborate on.

 

There are several things in the standard that exist there for the sole purpose of accommodating new commercial resources (not just LoR ones, I mean ensuring future accommodation of more commercial resources):

1. Hardcoded table of things in "ID24 Mapping Additions" document. The reasons they are hardcoded is because there is no other way for mappers to include these things in their wads, as these things are a part of a commercial product ("note that illegal redistribution of this file is covered by normal copyright laws"). So you have to rely on iwad resolution rules and hardcode the whole bunch of stuff. If id24res was released under an open license (e.g. MIT), there would be no need for that, it would simply use existing DEHEXTRA (or DSDHACKED) space, and everyone would be able to reuse them in their maps the exact same way people reuse custom monsters now. Existing tools (decohack) also make it extremely easy to do so.

2. Requirement of id24res.wad, which was previously discussed. This creates a table of scenarios on what to do when id24res is (not) needed and (not) found, some of which get ugly no matter what approach you choose to requiring it. On top of already clunky double-iwad loading.

3. Hardcoded tables of strings and things in ID24HACKED document. Same as (1).

4. ID24HACKED reserving separate ranges for id and for "community". The reason there was no need to ever reserve anything for anyone's future use with DSDHACKED is because all resources and dehacked could always be supplied along with the pwad. So the only reason to reserve the range like this is, coming back to (1) - to ensure you can add more commercial resources in the future. I guess the "community" part was simply done to make it feel "fair", but in reality community doesn't need these ranges at all, because we never need to hardcode stuff, because we don't create new iwads.

 

I might have missed something, these specs are quite large, but I think this is more than enough to demonstrate the idea.

 

Now if id24res.wad is released for free for non-commercial use, all 4 of these parts can be fully cut from the standard and good half of ID24HACKED standard becomes completely redundant. I don't expect this to happen, but I believe this is the type of step that can at the same time demonstrate good intentions from id side towads community, simplify the spec significantly and simplify the work of community developers. I of course understand that there is work that was done and people want to get money for their work, but the way doom community operates is exactly the opposite, things are done for the love of doom and not for money. And, well, I keep getting reassured that there is no commercial incentive behind this standard. I have listed the commercial incentive parts - let's cut them down?

 

8 hours ago, Xaser said:

An example non-ID24 use case: a suggestion that's come up a few times is a flag that lets an actor trigger walkover linedefs as if they were a player, allowing it to be used instead of a voodoo doll for conveyor scripts. The spec could then go one step further and reserve a dedicated "pseudo-voodoo" actor with this flag already set so mappers can just drop it in a map without ever needing to learn DEHACKED. Something to this effect has been suggested at least once and shot down with the very-valid reason that reserving an actor number encroaches upon DEHEXTRA/DSDHACKED -- this is what the reserved state ranges aim to solve.

Since this is relevant: I don't think expanding on custom actors that mappers can use without learning dehacked has any value. Decohack allows extremely easy reuse and we are slowly building custom decohack things bases, that will eventually get more accessible and easily reused. Copypasting a thing from a reference decohack to your decohack is trivial to learn. Once again, the only reason why these reserved ranged are really needed is to allow future commercial resources.

 

 

Also @bofu, as I understand you are looking at future mbf standard directions and how it can coexist with id24. Regardless of what direction it takes feature-wise, I believe these four things (and any similar for-the-future-iwads hardcode) have absolutely no place in a community standard, as the only reason for their existence is commercial.

Edited by Ravendesk

Share this post


Link to post

@Ravendesk I think a better license for the assets would be a CC BY-NC-ND 4.0 license.

 

Quote

This license requires that reusers give credit to the creator. It allows reusers to copy and distribute the material in any medium or format in unadapted form and for noncommercial purposes only.

MIT might be too much permissive in this case.

Share this post


Link to post
Posted (edited)
25 minutes ago, Ravendesk said:

Now if id24res.wad is released for free for non-commercial use, all 4 of these parts can be fully cut from the standard and good half of ID24HACKED standard becomes completely redundant.

 

Something I continue to be unclear about is why a community-supplied resource substitution is unacceptable.

 

And I actually have personal experience dealing with these kinds of resource-provenance questions.  In order to allow Linux distros to package Odamex, Odamex's resource WAD tries to avoid using resources derived from commercial products whenever feasible, even when they result in things that don't look quite right.  Our BIGFONT equivalent is a unique font, and I don't think we even have sprites for MBF dogs, which canonically use Wolfenstein 3D dogs.

 

image.png.255cf64aa24e907f29911cb68a50ea3d.png


There's probably a dozen good options for substitutes on DRDTeam - or whatever succeeded it, I haven't visited since the takedown drama.

 

EDIT: For reference, this is a match countdown screen that would normally show a game mode name, and the game mode name can be overridden with a cvar.  Turns out that Odamex players are memelords too. 😛

Edited by LexiMax

Share this post


Link to post
8 minutes ago, LexiMax said:

Something I continue to be unclear about is why a community-supplied resource substitution is unacceptable.

It is perfectly possible, but that's not the point of what I was talking about? There will be another commercial idxxres.wad or an update to the existing id24res.wad, and it's going to be the same story again. Community has to work on alternative resources every time id decides it wants to hype up on doom a bit? The whole spec is designed to allow id to drop more and more commercial resources into doom2.

Share this post


Link to post
15 minutes ago, LexiMax said:

I don't think we even have sprites for MBF dogs, which canonically use Wolfenstein 3D dogs.

Let me tell you about Nash's CC-BY dog sprites.

 

36 minutes ago, Ravendesk said:

2. Requirement of id24res.wad, which was previously discussed. This creates a table of scenarios on what to do when id24res is (not) needed and (not) found, some of which get ugly no matter what approach you choose to requiring it.

I don't really agree here. The table has four possible scenarios:

  1. Not needed and not found. No problem.
  2. Not needed and found. No problem.
  3. Needed and found. No problem.
  4. Needed and not found. This is the only scenario in which there is something to address. And the precedent here would be "new Doom II actors in Ultimate Doom".

Share this post


Link to post
Posted (edited)
1 hour ago, LexiMax said:

This does make me want to significantly cut back on my engagement with the greater Doom community, as I now feel like people like me have been "othered" and considered the enemy, which is soul-rending for a community that I once considered "home."

People for and against id24 or the new port need to stop thinking this way. You are losing all concept of scale because a few pages of posts seem like a lot. But there's maybe a few dozen posters in this thread out of the thousands and more who play. Don't take this thread to represent "the greater Doom community."

Share this post


Link to post
Posted (edited)
28 minutes ago, LexiMax said:

Something I continue to be unclear about is why a community-supplied resource substitution is unacceptable.

Because then the community would be playing the catch-up game. It's like Chrome vs Firefox all over again. Of course Chrome features can be developed for Firefox, but that's not so simple, and while you do, Chrome keeps releasing feature after feature. That's one of the key reasons the former holds a monopoly over the internet: you can't do battle against resources like that. Freedoom and such have years of work poured in and still no 1.0 release.

Share this post


Link to post

When building my unofficial MBF24 spec, one thing I was very careful about was to make sure all of those features and gameplay changes were gated behind a very specific complevel. Some of that is less practical than others, and I feel genuine sympathy for both source port developers, who will now have to dedicate effort to a standard they had no visibility into, and the creators of ID24, who were more than likely contractually forbidden from giving them that insight.

 

There is nothing I’m building or have built that is contradicted or made impossible by the things done in ID24. It adds a few things that were on the roadmap - customizable cast calls, weapon and ammo slots chief among them - but had not yet started active development. As such, for those items and a few others, I do not see any issue with adopting the ID24 approach so that we don’t have forked standards.

 

Ultimately, though, I think it’s important that standards be scaffolded upon one another. Nothing in a standard developed tomorrow should break a wad that’s playable today. Part of why I love MBF21 so much is that, barring some very intentional uses of certain complevels’ idiosyncrasies, it runs everything pretty damn well. It also helps when a source port sticks to the tradition of complevel implementation that PrBoom and its successors have used, as gating changed code behind conditionals based on the current complevel helps ensure that you won’t get unintended side effects.

 

Which brings me to my point: a lot of this is going to depend on how, and if, the source ports currently moving things forward in the community implement any new standard. I have faith that the current issues will be ironed out over time.

 

As for resource files being required, my understanding is that you only need the id24 resource files if you’re specifically using the things that they define. Correct me if I’m wrong, but I think you can make use of all the other ID24 features without using that file so long as you reference and include your own sprites and dehacked code. It’s a little weird how the new source port puts the new weapons into the rotation for wads not built with them in mind (which may be unintended), but I think that’s a side effect of the implementation in the port, not the standard itself as we would see it used in other ports.

Share this post


Link to post
1 minute ago, Gez said:

I don't really agree here. The table has four possible scenarios:

I might have not been very clear. According to Xaser, the requirement will be amended where not finding id24 will not lead to failing to load the id24-compatible wad. So the catch here is that source port doesn't know if resource is needed or not until it encounters the usage of this thing in runtime. Which makes it ugly for wads that actually used id24 resources and then crashed in runtime because the warning that id24 wasn't found was ignored.

 

I don't think it's meaningful to discuss all scenarios here until the spec is updated. Because how the spec currently describes this (failing to find id24res will fail to load id24-compatible wad) is not how Xaser said it should look (will not fail to load), and depending on how it is described, the problematic scenarios are different.

 

But this is just one of the awkward parts of the spec that is there purely to support new commercial resources.

Share this post


Link to post
17 minutes ago, Ravendesk said:

It is perfectly possible, but that's not the point of what I was talking about? There will be another commercial idxxres.wad or an update to the existing id24res.wad, and it's going to be the same story again. Community has to work on alternative resources every time id decides it wants to hype up on doom a bit? The whole spec is designed to allow id to drop more and more commercial resources into doom2.

1. This is id Software, not Bugthesda.

2. Even going by Skyrim and Fallout 4 precedence, updates breaking most mods en-masse are very rare and only happen once in a blue moon.

 

1 minute ago, Ravendesk said:

I might have not been very clear. According to Xaser, the requirement will be amended where not finding id24 will not lead to failing to load the id24-compatible wad. So the catch here is that source port doesn't know if resource is needed or not until it encounters the usage of this thing in runtime. Which makes it ugly for wads that actually used id24 resources and then crashed in runtime because the warning that id24 wasn't found was ignored.

Like I said, the only meaningful way to address this is to make an alternate "supported engine version" specification named "id24-bfg" (or "id24-nocommercial" or something more appropriate) that strictly forbids usage of Legacy of Rust assets in any capacity.

 

A Creative Commons license release of the ID24 assets is very unrealistic, and goes against precedence set in the 90s with Evilution and Master Levels' releases.

Share this post


Link to post
2 minutes ago, Cacodemon345 said:

1. This is id Software, not Bugthesda.

Id Software's Id Software, they can make mistakes and aren't above all criticism, like all gaming companies. They can be on a streak of goodness until they suddenly go 'rogue', it's been proven time and time again in the gaming industry.

 

3 minutes ago, Cacodemon345 said:

2. Even going by Skyrim and Fallout 4 precedence, updates breaking most mods en-masse are very rare and only happen once in a blue moon.

Yet they still happen. And they destabilise their respective communities massively, from modpacks/mods becoming unplayable to ongoing projects having to suddenly go "HOLY SH**!!!!!" and adapt by either telling users to downgrade or spending MORE DEVELOPMENT TIME to get their projects out. Fallout: London basically tells you "if you own the game on Steam, downgrade Fallout 4 or you won't be able to play! Good luck following the downgrade guide! If it breaks, it's not our fault!". One thing we like in Doom, especially speedrunning, are final versions. We want things at one point to have the ultimate 1.0 and stop being updated, for the sake of order and keeping ourselves sane.

Share this post


Link to post
1 hour ago, msx2plus said:

this is an incredibly upsetting and tribalistic thread that i can only read as frustratingly full of myopia, willful misinterpretation, armchair legalese and above all dehumanizing impatience. i am 100% onboard with being critical of commercial products from big corpo, as everybody should be, but i can't understand the depth of it all beyond it being a surprise to port developers. open standard, doesn't require commercial data to be actually used (minus assets, which is true of every commercial doom-related thing*), etc.

1 hour ago, LexiMax said:

The positive reaction I saw in response made me realize that perhaps my fears were a little overblown.  After witnessing what just unfolded in these threads, I now believe that my fears were justified - I just got lucky because my additions were low hanging fruit and didn't cross anybody's lines.  I intend to continue contributing to Odamex, and I plan on adding ID24 features to it, but this does make me want to significantly cut back on my engagement with the greater Doom community, as I now feel like people like me have been "othered" and considered the enemy, which is soul-rending for a community that I once considered "home."

yeah, it's just....really bad.

 

none of the people who worked on either the new port or id24 have any malicious intentions. they've tried time and time again to make that clear, but a lot of people seemingly don't want to listen or even work with them to reach some sort of compromise. a lot of people have valid concerns, but for every post like that, there's five others that read as though they see everyone who worked on it as being pure evil. (see: gpl launderer)

 

some of you need to step back and realize that you're talking to other humans and not corporate ai's. you can reach an agreement with them, but you need to stop seeing them as an enemy.

Share this post


Link to post
Posted (edited)
1 hour ago, dsda-dev said:

the port having the features doesn't bother me. It's that it has the features wrong. Its demos won't play back in existing ports and vice versa (at least, for boom and further).

I have a question (and please don't interpret this as me singling you out or even thinking that you are wrong to do this in some way, I am simply wanting to understand)

 

Given that you've been going out of your way to add ZDoom related stuff to DSDA recently, why does the quoted sentiment not apply to ZDoom/GZDoom? Its whole history is adding new features without really giving a shit about whether or not other ports can implement them, and its whole history is also not caring about demo intercompatibility.

 

Do you give ZDoom/GZDoom a pass for this? If so why do they get the pass and a future of adding features from it and not the new nightdive port?

 

 

Realistically I see most of the new id24 additions as things like "we wanted to have a Doom 1 style intermission and made a way to define it" and simply revealed its specs to people. There wasn't this kind of pushback against, say, DMAPINFO from the Unity version, or against ZDoom MAPINFO being able to define custom intermission maps.

Is the hardcoded Legacy of Rust object stuff the main contention here or is it also the other features?

Share this post


Link to post
3 minutes ago, Daniel, the NCR Veteran said:

Id Software's Id Software, they can make mistakes and aren't above all criticism, like all gaming companies. They can be on a streak of goodness until they suddenly go 'rogue', it's been proven time and time again in the gaming industry.

We will see when they actually go 'rogue' on Classic Doom.

 

News flash: they didn't in the last 11 years.

 

Which leads to...

7 minutes ago, Daniel, the NCR Veteran said:

Yet they still happen. And they destabilise their respective communities massively, from modpacks/mods becoming unplayable to ongoing projects having to suddenly go "HOLY SH**!!!!!" and adapt by either telling users to downgrade or spending MORE DEVELOPMENT TIME to get their projects out. Fallout: London basically tells you "if you own the game on Steam, downgrade Fallout 4 or you won't be able to play! Good luck following the downgrade guide! If it breaks, it's not our fault!". One thing we like in Doom, especially speedrunning, are final versions. We want things at one point to have the ultimate 1.0 and stop being updated, for the sake of order and keeping ourselves sane.

Fallout 4/Skyrim's PC modding scene are far more likely to suffer from such severe breakage issues because whatever extended modding support is provided is completely unofficial. It's not the developers' fault for all the mod breakages that happen there.

 

ID24 is official; we WILL recover from breakages far better because there's at least some proper semblance of a standard and not a DLL/executable/code-injected mess that was, is and will always remain a liability forever.

Share this post


Link to post
Posted (edited)
14 minutes ago, Cacodemon345 said:

Fallout 4/Skyrim's PC modding scene are far more likely to suffer from such severe breakage issues because whatever extended modding support is provided is completely unofficial.

Well, to argue in the other direction now, even Goober just described how poor most of the documentation is for the most common Doom modding feature sets (especially when it comes to Boom features, there's a pretty long list of bugs in Nightdive Doom. Boom+ demos not being compatible is one thing but even vanilla demos from the ND port cannot be expected to be vanilla compatible right now) and several pretty high profile Boom mappers have come forth saying their stuff doesn't work.

Edited by Trov

Share this post


Link to post

In my past (2) posts on this thread I tried to voice my concern about the whole ID24 thing and the dishonest way it was presented as "an act in good faith" when in reality the involvement of a big company in community matters (such as mapping standards, to name one) is intrinsically negative any way you look at it. Maybe this is not so bad yet for many of you, but if people at Bethesda/Nightdive are testing the waters with these actions and the community is not pushing back, they will find more intrusive ways to monetize the community output in the future. There are many examples of this in other video game communities in the past.

 

The main goal of a company is to make money as opposed to the goal of any community creating content for free, which is just to create and share stuff for the love of it, with no financial incentives involved; mixing both is never a good idea if the past is anything we can learn from. The moment money is included in the picture, things start to smell bad, this is just the way the world works. I'm not against capitalism or against people trying to earn some money through their hobbies, but I do have a strong opinion about the way the ID24 concept was introduced and presented to the community.

 

I posted my opinions without insulting anyone personally, just critical of their actions and decisions, which are very much real and out there for everyone to see. I never used bad words or other personal attacks, but I just received a warning by the moderators for being rude. This warning can only be interpreted as a punishment for an opinion in disagreement with a group of renown members of this community, not for breaking any TOS of a public forum.

 

Maybe I just have a different set of values and philosophies, or maybe this is a cultural difference thing (I am from a different country, not a native English speaker), but I never said anything so vile as to warrant a warning by the forum moderation team. If this is how these types of disagreements are handled around here (with threats to silence opposing views), do not even bother banning my account, I will show myself out.

 

I sincerely hope this community keeps thriving despite everything and every bad actor trying to take advantage of it now or in the future.

 

 

Share this post


Link to post
16 minutes ago, GooberMan said:

But more importantly, kraflab claimed the rest of the built-in tables for the community and didn’t ask id Software if they were planning to do anything with it.

I'm honestly at a loss of words.

Share this post


Link to post
Posted (edited)
26 minutes ago, GooberMan said:

But more importantly, he claimed the rest of the built-in tables for the community and didn’t ask id Software if they were planning to do anything with it. 

DSDHACKED was made years ago, wasn't it? Why should id Software have had any consideration in it? Do other ports (GZDoom et al) have an expectation to consider what id Software or even other ports plan to do? Or was ID24 being floated around that long ago?

Share this post


Link to post
Posted (edited)
14 minutes ago, Ravendesk said:

I'm honestly at a loss of words. 

Not just id software - it was a pain in the neck in most other ports, because it requires a reworking of how you allocate frames, and left no room for anybody else to iterate on or have a reserved block guaranteed not to conflict with anything else.

 

Odamex has port-specific frames for its CTF objective flags.  Where were they supposed to go?

Edited by LexiMax

Share this post


Link to post
Posted (edited)

 

10 minutes ago, Spicy tacodemon said:

 

 

I posted my opinions without insulting anyone personally, just critical of their actions and decisions, which are very much real and out there for everyone to see. I never used bad words or other personal attacks, but I just received a warning by the moderators for being rude. This warning can only be interpreted as a punishment for an opinion in disagreement with a group of renown members of this community, not for breaking any TOS of a public forum.

 

 

 

 

 

 

I'm no mod but it does sound like you were accusing people from the community of wanting to make a quick buck in your last post when in truth, that's not how it works. It's not like they'll get a huge cut from royalties  or even anything at all. It's such a simplification of something more complex than "Xaser and Gooberman get money" that I don't think you can see why that comes dangerously close to a personal attack, even when you didn't actually call anyone names. When you assume anyone that's not Bethesda's acting in bad faith by doing this, it shouldn't be too surprising if you end up getting a mod clapback.

Share this post


Link to post
6 minutes ago, Ravendesk said:

I'm honestly at a loss of words.

Hopefully not at a loss of eyesight, as right below that part it says:

 

Quote

Honestly, I get it. No limits for the community.

I don't think a statement of fact (and something he literally says he understands) should be that unsurprising or shocking, but just my two cents.

Share this post


Link to post

I think it's more that nobody knew Id was doing anything, so they couldn't ask. They just kinda assumed the Unity port was it.

 

22 minutes ago, Trov said:

Given that you've been going out of your way to add ZDoom related stuff to DSDA recently, why does the quoted sentiment not apply to ZDoom/GZDoom? Its whole history is adding new features without really giving a shit about whether or not other ports can implement them, and its whole history is also not caring about demo intercompatibility.

 

Do you give ZDoom/GZDoom a pass for this?

Dude, yelling at Graf has practically been this forum's national sport for at least a decade, for better or worse. I don't think they've "gotten away with" anything so much as GZDoom's mutated in such weird ways that it's now effectively a separate creature from every other port. Hence all these attempts at modern standards that try to make vanilla/Boom mapping "ZDoomier" without fully absorbing the ooze.

Share this post


Link to post
4 minutes ago, LexiMax said:

Not just id software - it was a pain in the neck in most other ports, because it requires a reworking of how you allocate frames, and left no room for anybody else to iterate on or have a reserved block. 

I can corroborate this was the case for EE. No consideration for existing port-specific extensions seemed to have been made (unlike dehextra) which made support far more painful than it otherwise would have been.

 

Anyway that's a very small portion of the text of that post, and relatively insubstantial compared to the rest, most of which is much more worthwhile in engaging with.

Share this post


Link to post
Posted (edited)
3 minutes ago, Kinsie said:

Dude, yelling at Graf has practically been this forum's national sport for at least a decade, for better or worse. I don't think they've "gotten away with" anything so much as GZDoom's mutated in such weird ways that it's now effectively a separate creature from every other port. Hence all these attempts at modern standards that try to make vanilla/Boom mapping "ZDoomier" without fully absorbing the ooze.

I'm not talking about this forum's temperature on Z/GZDoom in general, I'm specifically asking about DSDA adding specifically ZDoom map features, not Boom/MBF21-esque DEHACKED features that seek to emulate their functionality.

Share this post


Link to post
Posted (edited)
56 minutes ago, Ravendesk said:

I don't think it's meaningful to discuss all scenarios here until the spec is updated. Because how the spec currently describes this (failing to find id24res will fail to load id24-compatible wad) is not how Xaser said it should look (will not fail to load), and depending on how it is described, the problematic scenarios are different.

Again: if it's not needed -> no problem; if it's found -> no problem. The only scenario that needs solving is "needed but not found". All others are moot. No matter what specs you write, "found but not needed" will never be a problem.

56 minutes ago, Ravendesk said:

So the catch here is that source port doesn't know if resource is needed or not until it encounters the usage of this thing in runtime. Which makes it ugly for wads that actually used id24 resources and then crashed in runtime because the warning that id24 wasn't found was ignored.

Make an E1M1 map. Plop down a mancubus in it. Use DEHACKED to change its editor number to do so. Load the map in Ultimate Doom.

 

This is the same scenario.

 

In a situation like this, ZDoom will just spawn an error marker instead of crashing. I don't see how this approach would be ugly.

 

Also based on descriptions in the specs, the way the D+D2 port works for determining the featurelevel of a map is by scanning it first to see if it uses specific line types, things types, sector types, etc. so this too is an approach that can be used if you're afraid that "the port doesn't know if resource is needed" until it actually loads the map.

2 minutes ago, Trov said:

I'm not talking about this forum's temperature on Z/GZDoom in general, I'm specifically asking about DSDA adding specifically ZDoom features, not Boom/MBF21/DEHACKED mapping features that seek to emulate their functionality.

Reinventing the wheel is always better, I agree. It's also nice to not be compatible with an existing corpus of work and instead require people to generate a new corpus of work that uses your new wheel model; that's always a big help when you want to test your implementation.

Share this post


Link to post
Posted (edited)
2 minutes ago, Gez said:

Reinventing the wheel is always better, I agree. It's also nice to not be compatible with an existing corpus of work and instead require people to generate a new corpus of work that uses your new wheel model.

I don't think you're really responding to my argument here.

GZDoom/DSDA doom isnt really the only case here. Just about every port (lets just say Eternity now for the sake of argument) has a bunch of features that are not made in consideration of what other ports do, or can do, or plan to implement, can implement, or even want to implement.

Why should specific ports or releases be singled out for this?

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
×