Ravendesk Posted August 13 (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 August 13 by Ravendesk 10 Share this post Link to post
LuciferSam86 Posted August 13 @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. 1 Share this post Link to post
LexiMax Posted August 13 (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. 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 August 13 by LexiMax 6 Share this post Link to post
dpJudas Posted August 13 Since everyone is sharing their greater opinion about ID24 I guess I might as well share my thoughts as well. I don't mind the concept of adding more features on top of boom in the form MBF21 and so on, even if it isn't an area of particular interest myself. Giving modders more tools and increasing compatibility is a good thing. However, with ID24 two things did not happen: First, there was no consensus built among source port contributors that this is the set of features wanted. Instead it was assumed that everyone else would naturally implement everything R&R found important to add. If the spec was called R&R24 it would have been more honest IMHO. That it couldn't be discussed with the greater community because some people had signed NDA's is not anyone else's problem than those that signed the NDA. Secondly, who is exactly supposed to code this in all the other source ports? Due to #1 you just can't expect everyone to fall in line and implement a spec. That's not how things work. With regard to GZDoom, this kind of work has been traditionally done by Graf. Maybe he'll implement all in ID24? Or maybe he'll think some of it is stupid since GZDoom already offers some of the features? Who knows exactly what he will do. But that's exactly my point of what I think has been wrong with the ID24 initiative. I really feel sorry for the Nightdive folks behind the ID24 initiative as I really don't think they had any ill intents. This oooh Id software is a company thus eeeeevilll stuff is quite frankly just silly. By the end of the day the fact remains that for a standard to work implementors need to have been persuaded enough to invest their personal time in it and ID24 is anything but that. That said, I personally won't reject pull requests adding the features, provided it is done in non-hacky ways to the GZDoom codebase. Will anyone actually step up and do that? Who knows... 20 Share this post Link to post
Ravendesk Posted August 13 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. 2 Share this post Link to post
Gez Posted August 13 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: Not needed and not found. No problem. Not needed and found. No problem. Needed and found. No problem. 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". 4 Share this post Link to post
Trov Posted August 13 (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." 3 Share this post Link to post
Antkibo Posted August 13 (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. 0 Share this post Link to post
bofu Posted August 13 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. 9 Share this post Link to post
Ravendesk Posted August 13 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. 0 Share this post Link to post
Cacodemon345 Posted August 13 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. 3 Share this post Link to post
Daniel, the NCR Veteran Posted August 13 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. 4 Share this post Link to post
roadworx Posted August 13 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. 13 Share this post Link to post
GooberMan Posted August 13 Well, people from Nightdive and other prominent community members have had their say, and yet we’re still confronted with the reality of a thread where a prominent community member wants to control the narrative completely. So here I am, as a private individual who just happened to have his code licenced for an official release and who has had some outright disgusting fabrications directed at by said community member ready to talk shop. Strap in. kraflab, you do not get to hide behind an alt account and pretend you can be detached from what you said. You cannot shift blame on the shitstorm you’ve created here. You put on your sheeps clothing and say you have nothing against anyone, but come right out of the gate with personal attacks. Is the contradiction intentional or are you just that bad at saving face? You claim impartiality but you don’t need to scroll back far to find that this is patently false. Another truth bomb for you all - kraflab knew the most about what was coming before the announcement at QuakeCon and this thread. I know for a fact that he was being consulted on various matters in a way that didn’t break NDA. I had him and a few others on a shortlist of people that these specs needed to get in front of before the release. That didn’t happen for a number of reasons that cannot be disclosed. And dataminers meant that holding off on linking the spec for a while was downright impossible, the community would run away with the data and implement things without knowing what we had planned. So the possibilities here are that kraflab didn’t put two and two together, or that it’s yet another disingenuous rant in an attempt to drum up popular support in his favor. Especially being called a GPL launderer that’s in it for the money. Do any of you understand how hard it has been to not do a Luke Skywalker and immediately reply with “Amazing, every word of what you just said is wrong”? So let’s ignore the unassailable fact that I’m not in it for the money. (And no, being able to disclose the details to that is not up to me so don’t attempt to call me out on the matter. You’ll just have to wait until it can be talked about.) Here’s the scoop. There’s a very clear lineage of source from Doom -> Boom -> MBF -> prBoom -> dsda-doom. How many people do you suppose are involved in that chain? Okay, whatever that number is doesn’t matter for the following point - What percentage of them do you think are still alive? What percentage of the deceased have estates that are contactable? What percentage everyone else do you think are on the grid? The plain and simple truth is that it’s effectively impossible to licence the code written by every community member ever for use in a commercial product as required to support widely adopted community standards. To highlight the larger body of work done by the community on a commercial release, the only real option is reverse engineering and implementations from documentation. Which is what I’ve done. I’ve observed behavior by running Boom and MBF in DOSBox. I’ve followed the specs. And what is apparent at every step of the way is that the documentation is grossly incomplete. Ignoring undocumented features, it’s the undocumented behaviors that really kills you. I will never get Boom friction right unless I spend a good chunk of time I don’t have to disassemble the DOS binary and find the right constant in the right code - but I have a suspicion that this in itself won’t be enough since I already use a constant and a multiplication table for it. And that’s just for starters. I’d been planning on doing this from-scratch implementation for years because I wanted to see Eviternity running at 4K 120Hz in a software renderer (and keeping a good clip on those later maps on a Raspberry Pi in particular) but didn’t necessarily have the time to commit to a role on Eternity Engine. And hey, good news for everyone else, it meant that the road was clear for a 4K 120Hz renderer to ship on consoles. The Boom and later support is my work, untainted by being familiar with another implementation. Still, the fact that I was open about wanting to do the work and have a pretty successful career outside of this community with directly applicable experience meant that it solved quite a number of problems for everyone. And because I’ve been burned so hard by documentation, I didn’t want the next person to have the same problem. There’s the spec which describes behaviors as completely as I can (gaps will be filled as identified), and there’s also information on the reference implementation so that you don’t have to go digging for code. For those unfamiliar with software engineering, a reference implementation means it’s the first one but isn’t necessarily something you need to copy to be 100% compatible. It lets you know things that are outside of the spec but important if you’re aiming for compatibility with the new ports. But really, since we’ll never be demo compatible it’s just a guiding light for implementing it in other source ports. Outside of Lee Killough’s moon logic in MBF though, the feature I had the most difficulty with was DSDHacked - specifically, how to let the team ship a commercial product and not have the next people to work on the game face the same problem (and keep that phase in mind - as a contractor, I have no choice but to assume that I will not work on the next major update to the game). So here’s the scoop. kraflab has admitted he made DSDHacked to stir the pot. 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. Honestly, I get it. No limits for the community. My ID24Hacked work on the weapons and ammo was also to remove limits for the community (we only need 2 extra slots for the new weapons in the full spec). But jeez. That meant trying to work out if we could reuse DeHackEd and not need to throw the whole thing out if anyone officially wanted to add content to the game. Which meant getting crazy, adopting how computer science has advanced in the 30 years since Doom’s release, and using associative containers so that we could use the final bit in a 32-bit integer to add our content in a permanent manner that didn’t require users to somehow manage a 60 kilobyte DeHackEd file (or the DecoHack source, thus limiting users to one single toolset). The spec itself claims a range for anyone who works in a professional capacity on Doom in the future to add to the game without conflicting with the community. There’s already a clear user space thanks to the DSDHacked overreach, and there’s also a community space for any future feature work. The spec intentionally does not specify how the community uses that space outside of saying it should be by some kind of agreement. Do you all band together every couple of years to make a new spec? Do you form a committee that hands out a thousand indices at a time to whoever asks (there’s a billion indices, so you won’t run out in our lifetimes with that method)? The spec doesn’t dictate that, it has no need to, it should not need to. And I have no stake in it. Do what the community does best and come together to work out the best way to use it. Look, here’s the deal. I’m as open as possible about all this, and yet there’s still a bunch of people spreading FUD. Prominent members of the community should absolutely know better at this point. And yeah, it’s been a hectic few days. QuakeCon was nuts as always, and on a personal note a friend of mine is on his deathbed on the other side of the planet so there are absolutely more important things for me right now than a conversation like this which could have literally waited had people not decided to blow things out of proportion. But I could do nothing about the release date, and nothing about getting in contact with people before the release. But the fact that kraflab didn’t even return the common courtesy of reach out to the people he was speaking to and ask “Hey, what’s the deal?” and then carry on like this? No. It’s not on. Clean your act up. I want to make it clear here before I go so I can leave things on a positive note: My intention was to never leave the community in the lurch. Anyone needing to ask me questions or assistance for various things when it comes to ID24 support (port integration, tooling) then by all means reach out. I’m here to help. Always have been, always will. From Doom: The Arcade Game onwards I’ve been pretty explicitly open with my work and have helped community members from day one understand what I’m doing. I’m not about to stop now because of the response here. 56 Share this post Link to post
Trov Posted August 13 (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? 4 Share this post Link to post
Cacodemon345 Posted August 13 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. 3 Share this post Link to post
Trov Posted August 13 (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 August 13 by Trov 0 Share this post Link to post
Spicy tacodemon Posted August 13 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. 7 Share this post Link to post
Ravendesk Posted August 13 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. 8 Share this post Link to post
Trov Posted August 13 (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? 4 Share this post Link to post
LexiMax Posted August 13 (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 August 13 by LexiMax 5 Share this post Link to post
LadyMistDragon Posted August 13 (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. 8 Share this post Link to post
Dynamo Posted August 13 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. 8 Share this post Link to post
Kinsie Posted August 13 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. 2 Share this post Link to post
Quasar Posted August 13 If I wanted to test any waters I'd just return to developing Eternity and do so without regard to community standards, like what seems to be the modus operandi of most other ports these days. That would be a far more effective method of being potentially disruptive than a one-time development on the official version would ever be, at least if people actually started using said features. The conspiratorial thinking required to go from the ACTUAL motivation of folks at id Software, which was "we should do a 30-year anniversary version of Doom, here's what it would be cool to have in it: ..." to "they are scheming to take over the modding community and control everything" is dumbfounding. 29 Share this post Link to post
Altazimuth Posted August 13 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. 8 Share this post Link to post
Trov Posted August 13 (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. 1 Share this post Link to post
Gez Posted August 13 (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. 4 Share this post Link to post
Trov Posted August 13 (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? 0 Share this post Link to post
Ravendesk Posted August 13 8 minutes ago, Dynamo said: 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. I'm at a loss of words that gooberman sincerely believes that we need to ask id's permission before we mod the game, because god forbid they want to create new commercial assets for a 25 y.o. game and this creates problems for them. And after that people tell me there is no financial incentive behind the spec. We don't need more iwads, more commercial assets and more closed-source. Gooberman so openly admits that he is against everything I value in this modding community, that I'm at a loss of words, yes. I'm glad kraflab made it more difficult for id to monetise years of community work and it's a shame dsdhacked didn't use unsigned value for the range to make it completely impossible. 16 Share this post Link to post