Have you seen the UDS copyright info? Are you sure we can derive from it for the wiki? - Jdowland 11:36, 25 Mar 2005 (EST)
- I don't see any text lifted from the UDS. As long as we're just using it for reference purposes and not copying anything, then there is no issue. Bloodshedder 11:48, 25 Mar 2005 (EST)
UNIX 'file' command
Here's the entry the UNIX file command uses to identify WADs:
# Thomas M. Ott (ThMO) 1 string =WAD DOOM data, >0 string =I main wad >0 string =P patch wad >0 byte x unknown junk
This could easily be elaborated on if someone wanted to :) - Jdowland 07:46, 7 Apr 2005 (EDT)
Cinder colour blazing eyes
Is WAD officially an acronym of "Where's All the Data", as the article states? And if so, could someone put a reference in the article? I always assumed that WAD was supposed to be the word 'wad',  nothing more complex than that.-Ashley Pomeroy 14:31, 10 Jul 2005 (UTC)
- Doom Bible, page 67. Fredrik 16:26, 10 Jul 2005 (UTC)
The wikipedia article mentions the expansion "War Allocation Daemon". Not sure how that would be verified (although we have no reason to believe it is the official expansion, as that article claims). Ryan W 17:46, 25 April 2007 (UTC)
I understood "Where's All the Data" is a backronym, as there was an interview or something with Romereo, I need to find the video, not sure if it was a GDC video or something else, but he said that WAD came about because Carmack asked a question to the effect of, "What do you call a lot of chunks?" to which someone replied, "Wad, a wad of chunks." If I can find the video I heard this from, I will share it. --18.104.22.168 23:47, 27 August 2017 (CDT)
- it was Tom Hall who said it at the GDC 2011 Post Mortem for Doom. And it was regarding a "wad of lumps".--22.214.171.124 14:05, 28 August 2017 (CDT)
restriction on lump names
Only the characters A-Z (uppercase), 0-9, and [ ] - _ should be used in lump names (an exception has to be made for some of the Arch-Vile sprites, which use "\").. Is this true, or badly-phrased? A reference to the limitation in the code would be nice. I thought anything which passed
isascii() was OK. -- Jdowland 22:29, 16 March 2006 (UTC)
offset and directories
I was speaking to florian schulze on #doom-tech a while ago, we were talking about the directory and lump offsets. He stated that the directory offset to the entry information table (which contains offset, size and the name) has an unsigned 32bit value. this is the same for the lump offset.
Can anyone confirm this?
- They're just declared as "int" in the doom source, which means "signed 32bit little-endian", in the context of a 32bit compiler on x86. -- Jdowland 13:18, 22 October 2006 (UTC)
An integer specifying the number of lumps in the WAD. This thread at Doomworld claims that the number of lumps in a WAD can cause overflow problems without being anywhere near 231 - 1. Ryan W 18:21, 26 January 2008 (UTC)
Directory section TODO
"[Lump names] exceeding 8 bytes are forbidden." Okay, the editing tool should enforce this, but what if it doesn't? When creating a lump called MYLUMPROX, I can only assume (from precedent) that doom2.exe will not validate the directory entry at all, and all succeeding entries become "displaced to the right" by one byte, so the WAD will be unplayable as every pointer points to a different range of data than intended.
"When a modder imports lumps into a WAD from other files, file extensions are not included . . . " This paragraph is merely a guess at the original editor's intent, because their statement seemed misleading: the engine does one thing, and the editing tool does another, but that doesn't imply causation. As long as the tool didn't replace the standard IWAD naming, extra information could be preserved somewhere without affecting gameplay (as we know from the PLATFORM lumps, way back when).
Is Voros correct to imply that similarities to ZIP files are unimportant? Given the ubiquity of compressed data in modern ports and recurring newbie confusion about how to deal with it, surely it deserves a passing mention under "Compression".
Not saying anyone needs to research any of these things now, just acknowledging that some old unreferenced statements were moved into this article without testing. Ryan W (living fossil) 17:43, 10 November 2017 (CST)
- Partial reply from IRC:
- <Quasar``> the physical space is 8 bytes; it doesn't look for a terminating null to stop reading
- <Quasar``> every directory entry is assumed to be the same size as the lumpinfo_t struct
- <Quasar``> so indeed if one were to put in a 9-char long lump name, every directory entry after that will be corrupted.
- --Quasar (talk) 09:05, 12 November 2017 (CST)