|
|
Post by ketmar on Aug 15, 2024 5:48:10 GMT -5
yep, Carmack wanted to make the game moddable from the day one. as far as i remember (this may be incorrect, though), he was planning to release the tools later. the editor was written for NeXT, bsp builder too (afair), and it required some time to port them. and there was never such thing as Teh Official Specs, because nobody at id needs them.
so while Carmack was preparing for tools release (and he thought that he'll have a plenty of time to do that), the community cracked most formats. BSP took the longest, but people finally did it too. as far as i remember, the first node builder was in DEU, and it was written without using id sources.
but i might be wrong on NODES info here: maybe idbsp was released before the public release of DEU. still, people cracked the formats on their own, because hey, who wouldn't want to mod such a marvelous game right now?! ;-)
p.s.: actually, if i remember right, some later Doom versions were distributed with The Unofficial Doom Specs, because they were so good that id didn't feel they need to write their own.
|
|
|
|
Post by hex11 on Aug 15, 2024 10:01:51 GMT -5
> some later Doom versions were distributed with The Unofficial Doom Specs
The Doom 1.9 shareware just has a copy of the Unofficial Doom and Doom II FAQ, but in there it does mention node builders:
[6-4]: How can I get the DOOM Specs for creating add-on utilities?
==================================================================
id has made the decision not to release their own DOOM specs.
The Unofficial DOOM Specs, however, written by Matt Fell and
distributed by myself, are available. See Chapter [15-24] for more
information.
And actually that reference number is wrong, they forgot to update it or something:
*15-36*: Unofficial DOOM Specs v1.666
=====================================
DESCRIPTION:
Technical information about the DOOM .WAD file for programmers.
Includes complete explanation of all components of the .WAD file,
including nodes. v1.666 of the specs may not be available until the
first quarter of 1995.
CREATED BY:
Matt Burnett (matt.fell@acebbs.com)
Hank Leukart (Distribution: ap641@cleveland.freenet.edu)
AVAILABLE AT:
Site (1): wad_edit/text/dmspec16.txt
Site (2): dmspec16.txt
Site (3): dmspec16.zip
|
|
Lobo
Doomer
Posts: 594 
|
Post by Lobo on Aug 15, 2024 11:42:11 GMT -5
Graf Zahl has opined: forum.zdoom.org/viewtopic.php?p=1253908#p1253908"For me the entire spec dies with its deep roots in Dehacked mess. It's like taking the worst parts of DSDHACKED and building some convoluted setup around them to allow new extensions. This will be a nightmare to support for virtually everybody and I find it very telling that aside from Kraflab no other developer has posted their opinion on the Doomworld thread yet." |
|
|
|
Post by JadingTsunami on Aug 15, 2024 12:24:46 GMT -5
Graf Zahl has opined: forum.zdoom.org/viewtopic.php?p=1253908#p1253908"For me the entire spec dies with its deep roots in Dehacked mess. It's like taking the worst parts of DSDHACKED and building some convoluted setup around them to allow new extensions. This will be a nightmare to support for virtually everybody and I find it very telling that aside from Kraflab no other developer has posted their opinion on the Doomworld thread yet." Thanks for sharing. His summary of the technical points, both in that post and the follow-up post immediately below, matches my opinions pretty closely also. |
|
|
|
Post by gije on Aug 15, 2024 13:55:20 GMT -5
"...so I suppose that if you want to play LOR in GZDoom, make a copy of your ID24 wads and modify LOR to use DECORATE instead AND DO NOT SHARE IT."
This would be kind of funny, ports instead adopting the easiest-to-implement milestone of DECORATE and converting relevant portions of ID24 on the spot, however much sense that would make (I am entirely ignorant.)
There's kind of the question though if the closed-source KEX port will last more than 5 years, and what that would mean for the standard, at which point such a fixture may as well be an external utility.
|
|
|
|
Post by camper on Aug 15, 2024 14:26:23 GMT -5
It does create a lot of uncertainty for many people, I think. This is a bifurcation fork. There are already people who don't adhere to this standard, which means that Doom is no longer Doom. If Freed∞m adheres to the new official standard, it will no longer be free. |
|
40oz
diRTbAg
Posts: 6,105
|
Post by 40oz on Aug 15, 2024 14:42:29 GMT -5
graf zahl banned in 3.... 2.... 1....
|
|
|
|
Post by camper on Aug 15, 2024 15:08:41 GMT -5
Honestly no idea; I think it's a grey area which has never truly been tested. "Covering" a song in MIDI or tracker format in my opinion is a transformative work, especially if you are using standard synthesis/OPL emulation/samples to mimic the original instruments in question. This is probably true, otherwise this resource would have closed long ago |
|
nnn✓ork
Doomer
Dr. Noisystein
Posts: 719
|
Post by nnn✓ork on Aug 15, 2024 15:25:17 GMT -5
This would be kind of funny, ports instead adopting the easiest-to-implement milestone of DECORATE and converting relevant portions of ID24 on the spot, however much sense that would make (I am entirely ignorant.) There's kind of the question though if the closed-source KEX port will last more than 5 years, and what that would mean for the standard, at which point such a fixture may as well be an external utility. I've raised similar questions. These questions kinda make me want to build a source port myself, if there weren't cooler things to do with my time, just to see what happens. We might not actually be entirely ignorant, but who knows... -There's one narrative where the clunky id24 design looks like it's built to intentionally marble commercial stuff into it (lol it's just 'optional' tho, bro), to "take space" (for copra) in Overwatch and MOBA terms, to push and encourage said commercial stuff, or that all of this is a convenient side-effect of it - which those involved incidentally benefit from turning a blind eye to... -But there's also the other very likely narrative that they all just kinda designed themselves into a corner due to innocent circumstances and things that made sense at the time, things that simply accrued over time, and it was "just how the cookie crumbled". And now they just are where they are. We've all been there, and I think this is a bigger factor than the former points. |
|
|
|
Post by Moonsweeper on Aug 15, 2024 15:49:08 GMT -5
It does create a lot of uncertainty for many people, I think. This is a bifurcation fork. There are already people who don't adhere to this standard, which means that Doom is no longer Doom. If Freed∞m adheres to the new official standard, it will no longer be free. Freedoom already adhered to the new standard, look at the subforum, they are calling it FD24.wad. Although it's called Freedoom, everytime someone has suggested forking it there were members of the main Freedoom branch attacking and disencouraging them. But as it's licensed in CC and BSP they can't reallly do anything pratical to stop it. |
|
|
|
Post by gije on Aug 15, 2024 15:51:10 GMT -5
I've raised similar questions. These questions kinda make me want to build a source port myself, if there weren't cooler things to do with my time, just to see what happens. We might not actually be entirely ignorant, but who knows... -There's one narrative where the clunky id24 design looks like it's built to intentionally marble commercial stuff into it (lol it's just 'optional' tho, bro), to "take space" (for copra) in Overwatch and MOBA terms, to push and encourage said commercial stuff, or that all of this is a convenient side-effect of it - which those involved incidentally benefit from turning a blind eye to... -But there's also the other very likely narrative that they all just kinda designed themselves into a corner due to innocent circumstances and things that made sense at the time, things that simply accrued over time, and it was "just how the cookie crumbled". And now they just are where they are. We've all been there, and I think this is a bigger factor than the former points. I could see it being a bit of everything rolled together: nuIdBethSoft wanting to repackage Doom with frills, possibly with a hopeful future goal of 'obsoleting' original IWAD support, or relegating it to historical curiosity in favor of a proprietary upgrade treadmill; devs working on it wanting dehacked/boom/mbf21 compat in the proprietary engine and having to sell it to execs with some semi-exclusivity baked in (testing the waters...?); possible designs for clout farming and/or community shaping and control baked into the above (the controversy and fallout may even have been intended.) Could be wrong about some bits, but part of what I'm getting at is there are likely mixed motivations among the different layers involved with different layers thinking they're using the other. All this for a port with a limited shelf-life, for consoles. |
|
nnn✓ork
Doomer
Dr. Noisystein
Posts: 719
|
Post by nnn✓ork on Aug 15, 2024 15:56:26 GMT -5
Yup
|
|
|
|
Post by camper on Aug 15, 2024 16:25:39 GMT -5
Freedoom already adhered to the new standard, look at the subforum, they are calling it FD24.wad. Fraggle, one of the main developers, worked in the Unity port, and by extension, the new release, but he has had "friends" from inside Id and Nightdive ever since the early 2010s at least, he's also a Doomworld moderator, just like any others. He might have been the one responsible for the downgrade in Freedoom's art. In a way FD has always been about limiting Id's profit in a legal way, he might have changed the goal to not compromise Id's "future commercial viability of Doom and Doom II". Seriously, it's impressive that with so many talented mappers in the community, nobody has ever been able to make two megawads with a level of quality above "90s shovelware disk" Although it's called Freedoom, everytime someone has suggested forking it there were members of the Freedoom Discord attacking and disencouraging them. But as it's licensed in CC and BSP they can't reallly do anything pratical to stop it. I think that we just need to abandon iwad. K8Vavoom or Helion can launch pwad with a minimum set of correctly structured resources without iwad. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 15, 2024 17:34:20 GMT -5
I think that we just need to abandon iwad. K8Vavoom or Helion can launch pwad with a minimum set of correctly structured resources without iwad. In theory, you could just go beyond that and not even require the WAD file format at all, which would make it a lot easier to reason about things like load order, etc. There is nothing stopping, for instance, individual UDMF maps from being stored as separate plaintext files in the /maps directory, and nodes stored as either separate files or encoded into the UDMF file itself. |
|
|
|
Post by ketmar on Aug 15, 2024 19:33:17 GMT -5
This would be kind of funny, ports instead adopting the easiest-to-implement milestone of DECORATE and converting relevant portions of ID24 on the spot, however much sense that would make i don't know how deep in MBF21 LoR is (i don't own gog/steam/etc. Doom, and never bothered to hunt it down by other means; only wanted to get "Common.kpf"), but generally speaking, converting DECOLITE to MBF21 is much easier than converting MBF21 to DECOLITE. that's why i refused to implement MBF21 in the first place. but of course, writing a DECORATE patch for LoR is possible. and by the way, i don't think that redestributing the DECORATE files themselves is copyright infringement. we can "license launder" it just like GooberMan did with MBF (clean room implementation). In theory, you could just go beyond that and not even require the WAD file format at all vwad. k8v has vwads. k8v has a free C library to read and write vwads. all go for vwads! ;-) i even worked on loading maps from subdirectories, without a supplement wad file. don't remember if i finished it, though. p.s.: k8v using vwads even to store saves. |
|
|
|
Post by JadingTsunami on Aug 15, 2024 19:35:24 GMT -5
|
|
|
|
Post by ketmar on Aug 15, 2024 19:40:25 GMT -5
i wonder why people are so happy to help bethesda to sell their crap. "yay, we finally can give that corpos all our work for free, so they could make more money on the game and content they don't have anything to do with!"
i'd have zero (well, almost zero) problems with the original id software doing that stunt. but bethId? no wai. at least until they filful Carmack promise, and release idTech5 source code.
|
|
|
|
Post by ketmar on Aug 15, 2024 20:00:33 GMT -5
also, it is really fun how dpJudas is licking asses on id24 on DW ("We should try get as much as it as possible into all the source ports that we can."), but he is so unenthusiastic on zdf ("I can only speak for myself, but I don't have any plans on implementing ID24. Not because I have anything against the spec - it just isn't something that interests me."). i guess it is hard to maintain personal integrity when in one of the communities you're not The Godlike Port Dev, lol. |
|
|
|
Post by Killer5 on Aug 15, 2024 20:34:04 GMT -5
I might as well post this here because I am curious and it might get a response from someone who knows.
Are people able to copy another author's work, change some minute detail, and then distribute it on this stupid platform?
Edit:
Uunfortunately I have seen enough from people in this community based on past posts to believe that someone would do this. I can't believe thus is happening.
Edit 2:
Also by 'this community' I mean the community at large. Mostly targeted at people who made idiotic generalized statement in last year's cacoward farce on dw.
|
|
|
|
Post by ketmar on Aug 15, 2024 21:58:33 GMT -5
Are people able to copy another author's work, change some minute detail, and then distribute it on this stupid platform? this is actually several questions packed in one. technically speaking, derivative works are not ok unless it is explicitly allowed by the author (and by "explicitly" i mean "in lawyer's language"). yet i don't think that wad authors will sue anybody. then, you are NOT allowed to change authorship, in no case. this is tangential to copyright. the author may assign copyright rights to somebody, but the authorship cannot be reassigned. and then, there is "credits" question. credits (explicit stating of the authorship of the original work, or part of it) may not be required if the author is under contract. "credits not required" is NOT a legal obligation, you are still technically required to credit the original author. it's just the author says that they won't sue you in case you omit the credits. yet even if the author is under contract, nobody else can claim the authorship of the work. it is all mud waters, and there is a lot of confusion between copyright and authorship. now, to the question. uploading other people's work (modified or not) AND claiming the authorship may not violate copyright, but it violates authorship rights. so this is strictly illegal. uploading derivative work, with credits to the original author(s) MAY be legal. it depends of the original license. uploading unmodified work with retained authorship MAY be illegal, if the author(s) explicitly forbid it. yet it's all just a rhetorical speech, because bethesda have enough money to win any legal case. so the short answer is: bethesda will ignore any copyright/authorship issues with uploaded wads unless there will be a big enough public backlash. if enough public noise was made, bethesda may remove the wad in question, but they will never go to enforce the rules, because it requires money investment to actually LOSE more money. |
|
|
|
Post by Moonsweeper on Aug 15, 2024 22:02:58 GMT -5
I think that we just need to abandon iwad. K8Vavoom or Helion can launch pwad with a minimum set of correctly structured resources without iwad. In theory, you could just go beyond that and not even require the WAD file format at all, which would make it a lot easier to reason about things like load order, etc. There is nothing stopping, for instance, individual UDMF maps from being stored as separate plaintext files in the /maps directory, and nodes stored as either separate files or encoded into the UDMF file itself. I don't see the point, for TCs it would work, but for wads that rely on vanilla textures you would need to get the textures from somewhere. The original Id Software said people could use Doom's assets for Doom mods, Freedoom technically breaks some of that agreement, but it's too irrelevant for them to care about it. If people started playing Doom mods without an Iwad some Bethesda fanboy could send it to them, making they actually care enough to take action. Walking on the edge of legality with Freedoom or a fork seems like the way to go for now. This would be kind of funny, ports instead adopting the easiest-to-implement milestone of DECORATE and converting relevant portions of ID24 on the spot, however much sense that would make i don't know how deep in MBF21 LoR is (i don't own gog/steam/etc. Doom, and never bothered to hunt it down by other means; only wanted to get "Common.kpf"), but generally speaking, converting DECOLITE to MBF21 is much easier than converting MBF21 to DECOLITE. that's why i refused to implement MBF21 in the first place. but of course, writing a DECORATE patch for LoR is possible. and by the way, i don't think that redestributing the DECORATE files themselves is copyright infringement. we can "license launder" it just like GooberMan did with MBF (clean room implementation). In theory, you could just go beyond that and not even require the WAD file format at all vwad. k8v has vwads. k8v has a free C library to read and write vwads. all go for vwads! ;-) i even worked on loading maps from subdirectories, without a supplement wad file. don't remember if i finished it, though. p.s.: k8v using vwads even to store saves. The new enemies all seem to be quite simple (Vanilla/Boom Dehacked), the Vassago seems like the only one that's slightly more complex, probably the only true MBF21 enemy. Doing a "clean room implementation" seems like quite an ironic way to turn things around. By the way, right now people are discussing if Kraflab calling Gooberman a "GPL launderer" was an offense or not. Yet again I don't see the point of replacing .wad with .vwad, it's just another file extension with a few extras. i wonder why people are so happy to help bethesda to sell their crap. "yay, we finally can give that corpos all our work for free, so they could make more money on the game and content they don't have anything to do with!" i'd have zero (well, almost zero) problems with the original id software doing that stunt. but bethId? no wai. at least until they filful Carmack promise, and release idTech5 source code. Apparently everyone that contributed to the Unity releases got some kind of compensation and support for it, they just don't talk too much about it, probably wasn't a value relevant enough to say everyone was "bought" by Bethesda. |
|
|
|
Post by Killer5 on Aug 15, 2024 22:16:31 GMT -5
Ketmar: Cool beans. Ty for the info. Sounds like great times ahead of us  . Btw it blows Kraf was banned. I only ever really spoke to him when I used to stream. Seemed like a cool dude at face value (I don't know him outside of that). |
|
|
|
Post by Bob Page on Aug 15, 2024 22:28:49 GMT -5
Graf Zahl has opined: ...and I find it very telling that aside from Kraflab no other developer has posted their opinion on the Doomworld thread yet." Most of the other developers probably can't even post their opinions on Doomworld even if they wanted to, because they are frigging banned. |
|
|
|
Post by Killer5 on Aug 15, 2024 22:42:35 GMT -5
Wow. Yeah. I wonder what the report at the next Quakecon will be.. grats on one year of Doom + Doom 2 and oh btw it caused a lot of peoples' fun to be ruined (but at least it was successful for us)!
|
|
|
|
Post by ketmar on Aug 15, 2024 22:45:09 GMT -5
Yet again I don't see the point of replacing .wad with .vwad, it's just another file extension with a few extras. i was joking, of course. but for the sake of correctnes, vwad is not "just another file extension". it has slightly better compression than zlib, but in the same time you are not required to decompress the whole file (the compressor packs files by independent 64 kb chunks), so non-sequential file reading is very fast. the library automatically creates internal FAT table if necessary, so it is possible to create several files in vwad and write data to them without accumulating that data in some temporary storage. it has proper directories (a-la zip archives), so no 8-chars-by-name limitations. and you can optionally sign vwad with your private key, and distribute the public key, so the vwad can be checked for "authencity" (it uses ECDSA with Curve25519 for digital signatures). the library to read vwad files in one self-contained C source without external dependencies, only ~120 kb. vwad writer is another self-contained C source, ~140 kb. the format also supports explicit "author" and "description" texts, and it has "file group" featire (any files could be tagged with a group name), which might be very useful for various tools, to group files not only by directories, but by some tag too, and keep the tags in vwad itself. sorry for this offtopic wall of text, i just wanted to make it clear that vwad is not "yet another archive format", it was specifially designed to hold game data, and to be better than existing formats, or standard zip archives. |
|
.