"Added infobox, but cannot add latest release in said. I suspect this is due to editing rights."   — Please see documentation here and here.  The version and date for the latest release are stored on their own tiny pages.  Thanks!  Ryan W (living fossil) 15:30, 27 December 2019 (CST)

It seems i reached the end of what i picked up automatically, so thank you for providing these pages. I never would have found them otherwise. Ive applied this to the ggiDoom page and that came out succesful. Thanks again for linking these and ill incorporate these from here on out (and ill change it for Linux Heretic obviously.) -- Redneckerz

Welcome to DoomWiki![edit]

Belated welcome to DoomWiki! I noticed you're manually keeping a list of edits in your User page. You are of course welcome to do so, but you might find this automatic page easier: Special:Contributions/Redneckerz -- Shambler (talk) 07:43, 27 February 2020 (CST)

Hello! I have been here for a few months already ;) I was aware of the page, but never thought of this. It surely provides a more detailed log of what i did, so ill be putting this in somewhere. Thank you, Shambler, and nice to meet you! -- Redneckerz 16:05, 27 February 2020 (CET)

Server times[edit]

Hi, I think you mixed up the HTTP headers in this comment a bit: "Last-Modified: Wed, 12 Sep 2018" is indeed the last edit (or merely file system change, like a copy), but "Date: Mon, 25 May 2020" is simply the current server date/time. There's no 25 May 1998 there, nor in the article (source) itself. --Xymph (talk) 14:53, 25 May 2020 (CDT)

Yeah i actually don't know what happened. It added the 25 May 1998 timestamp automatically, which does not make sense to me if i retrieved it on 25 May 2020. I actually added that time (25 May 2020) in, the 1998 date was automatic. I should have gone with the September 2018 one (Which i saw) but i was not sure about this in regards to the term retrieved. If its September 12 2018, then lets just stick to that. Thanks for notifying. --Redneckerz (talk) 15:38, 25 May 2020 (CDT)

Catacomb 3D[edit]

Hi, I appreciate your addition of the CatacombGL section to this page. However, if you don't mind, I would like to make it a bit more maintenance friendly. I'm thinking of replacing it by a more general section about the Catacomb 3D source code release, with just a brief overview of Reflection Keen and CatacombGL. For a Doom centric wiki, I think that's sufficient. If you have any objections, please let me know. Regards, Arno (talk) 16:11, 1 January 2021 (CST)

No minds were given. A brief overview is equally sufficient. Thanks for reaching out! --Redneckerz (talk) 15:10, 2 January 2021 (CST)
Thank you! I've just updated Catacomb 3D. Arno (talk) 14:59, 3 January 2021 (CST)

Texture/palette automation?[edit]

Regarding these comments: my bot scripts don't parse WAD files, only Omgifol ( and DMMPST do. And I've done little texture/palette related work, only DMTXLS long ago, and a small script more recently. But new automation adventures are possible. :) Your comments are however to terse to understand what kind. Could you explain what you have in mind?

Natuurlijk ;) I think DMTXLS does a lot of what i try to say but ill try to explain more clearly. See Otex for an example. It provides exact numbers for textures, patches and flats in a manner that that reads like it either is automated or could be automated. For texture pack pages, such details will be instantly useful to have. As more authors are making use of custom texture packs, having documented details and numbers would be beneficial for the Wiki. This is suggestion 1.
The other comment i mentioned is regarding textures/palettes but they have an overlap with texture packs in the sense that more and more mapsets are making use of custom palettes, COLORMAP's, TINTTAB's and even TRANMAP's. Of the latter, i am preparing a compilation from Esselfortium (She has given permission) to put on /idgames that serves as a demonstrator of what is possible using them. But back to my point: I wonder if it is possible to extract these custom palette's and colormap's (Such as Eviternity's) and process them to a .gif or PNG, similarly to how maps are now drawn. For COLORMAP's it makes direct visual comparison with the stock palette more prominent and can serve as inspiration for others to experiment more with these lumps aswell. After all, we are a text heavy wiki: Visual examples are a good addition to this, provided extraction of such resources is considered okay by the author. This is suggestion 2.
Hopefully this sheds some light of what i tried to say in short in the commentary. Highlighting such lumps in visual representation is totally something that would be part of a wiki that wants to share encyclopedic level knowledge. Read it as some kind of visual autopsy of a mapset, much in the same vein drawmaps is used now. --Redneckerz (talk) 13:21, 2 May 2021 (CDT)
Well, DMTXLS just looks at textures/flats usage in one map, quite different from pack stats. It took a bit as I'm not really familiar with the TEXTUREx/PNAMES/SWITCHES/etc lumps, but I now understand where most of the OTEX numbers come from. Only the total textures (2624) are puzzling, as TEXTURE2 starts with 0x0BEC (3052). Have you asked Gez how the stats were collected, manually or (partly) automated? Is there a tool that decompiles TEXTUREx? Whether other tables of prefixes are feasible also depends on other packs being just as organized as OTEX.
SLADE already can extract PLAYPAL, TINTTAB, XLATAB, COLORMAP, FOGMAP into PNG images. Since that's just a one-time action per pack, I'm not sure automation is useful, unless you'd want to export all 14 (28 in Hexen) palettes - but I doubt that a full gallery of those is desirable on the wiki (and ZDoom uses only palette 0 anyway).
SLADE's exports only need to be rescaled to 200% or 400% to match the size of existing images here. The one thing I'm not sure about is orientation: SLADE creates PLAYPAL images in the same order as most specimen, but this wiki's main image and the COLORMAP sample are mirrored across the top-left/bottom-right diagonal. What is the proper orientation? And of course, the numbered palette variants with grid lines require a tool to draw, but that must exist somewhere already. --Xymph (talk) 05:48, 3 May 2021 (CDT)
I haven't yet asked Gez about the stats; ill make sure ill do so starting next week or so when i have a week of holiday because these are good questions to ask.
Regarding Slade: I believe the correct orientation is the one that SLADE uses as my example TRANMAPs from Essel are in this orientation. Obviously, not all palettes/TRANMAPs need to be extracted: Just the default palette of a WAD (Doom's Palette is also only displayed as one file rather than every single one of them). I agree that a full gallery of those is not desirable: The general palette (for lack of a better word) should be sufficient. Maybe such a thing can be automated using existing toolings, i wouldn't know (That's your domain) ;) --Redneckerz (talk) 14:25, 5 May 2021 (CDT)
Also ask about tooling, and how to render a palette with numbers and grid lines. Or invite Gez to this thread. :)
I had a look at the other two packs that already have an article (cc4-tex & GothicTX) but they use different naming schemes and there's no easy way to automate a grouped list in all variants. While scripting may still be of use to determine some stats, I think the majority of that stuff can just as easily be collected via SLADE. That certainly goes for extracting one or two lumps as PNG images, no point in automating that. Of the PWADs covered on the wiki, none use TINTTAB, XLATAB or FOGMAP; and only six use TRANMAP (sometimes named HTRANMAP): Reconstruction / Decomposition, Mapgame, Phobos: Anomaly Reborn, Stardate 20X7, Sunlust, and Super MAYhem 17. You may want to list these, and explain the alternate HTRANMAP naming.
So, should those palette (nevermind, PLAYPAL caption explains it is intended by columns) and colormap images be flipped? For the colormap it would make it fit into the article more awkwardly though, and the uploader explicitly stated the upright orientation to be "better", so I dunno... --Xymph (talk) 03:46, 6 May 2021 (CDT)
Seems like Gez found this out already :) If Slade can be a worthwhile collector instead of going through the effort of scripting this out, then all the better. Thanks for that list of projects. I did find out about HTRANMAP aswell but as of yet had little clue what the changes are. I know there are more projects out there that much around with TRANMAPS (Vela Pax comes to mind). Its just that author's do not make this immediately obvious :P
As for the orientation: From every COLORMAP posted on DW, it is exported as-is from SLADE. So if you were to ask me, i would take SLADE (or XWE) output as the norm if there is any kind of standardrization in how a COLORMAP needs to be viewed as.--Redneckerz (talk) 16:07, 6 May 2021 (CDT)
For the forums that's logical given how inline images work there. For the colormap/fogmap articles here, I've grown to like the upright orientation, but for texture pack articles with several illustrative images (perhaps in a gallery) the horizontal default from SLADE probably works best. --Xymph (talk) 07:43, 7 May 2021 (CDT)
If we stick to the default SLADE export here if there is a modified xMAP (COLORMAP, TRANMAP) available, then i see no issues along the way. If, ofcourse, is a modified xMAP to be found. For textures themselves, i'll have to think what could work for a gallery. This is thus also a answer on your comment to Gez, below. :) --Redneckerz (talk) 15:28, 7 May 2021 (CDT)

Just for reference, that was manual counting for the OTEX stats. Well, manual in that I exported all textures to lumps, and then selected all the new lumps so that SLADE would tell me how many were selected. A stat tool could certainly be written, but for just one texture pack that got an article at the time, it felt like less work to do it that way than to write a single-use tool. --Gez (talk) 04:54, 6 May 2021 (CDT)

I hadn't looked at SLADE's texture editor before, but could reproduce those steps to arrive at the same 2624 total. Thanks. But it's a bit convoluted, so for Redneckerz's planned 30-or-so texture pack articles, tooling would be useful. Do you know if a TEXTUREx decompile tool (preferably command-line based) exists? I looked in idgames/utils/graphics_edit/ but nothing obvious jumped out. I'm still learning to understand that lump's structure, but it appears to include IWAD texture definitions in addition to the pack's new textures. How are the latter distinguished if not by a naming scheme as obvious as OTEX's?
Any idea how those numbered palette images were generated? And what do you think about that Colormap.gif orientation? --Xymph (talk) 11:39, 6 May 2021 (CDT)
DeuTex can turn TEXTUREx lumps into text files, if that's what you mean by decompiling. Andrew Apted's JeuTool can most likely do that too. I'm afraid the only way I can see of distinguishing the original IWAD textures is to compare them with the IWAD textures... As for the numbered palettes, IIRC it was done by using a grid + number overlay... --Gez (talk) 13:08, 6 May 2021 (CDT)
It is my idea that those texture pack articles contain some simple stats on how many textures there are, and if there is a modified COLORMAP/TRANMAP/WHATEVERMAP, that it gets exported from SLADE and uploaded, like the TINTTAB page. Users can then compare that to the stock resource for visual clarity. As for the numbered palette images, that is a big unknown to me. My primary intent is getting A: pages up for the texture packs (Don't have to be hugely extensive, just enough to get the idea) and B: some way to get a picture snap of any modified COLOR or TRANMAP. AA-tex, for one, has such a modifed resource, so a visual example of it will make things more attractive for users.--Redneckerz (talk) 16:07, 6 May 2021 (CDT)
The grid/numbered images look nice to illustrate the principle of palettes, but to illustrate texture packs that isn't really necessary. So here too, let's just stick to the default SLADE export for consistency and simplicity. --Xymph (talk) 07:43, 7 May 2021 (CDT)

← ← ← ←
I created an Omgifol script to collect statistics for texture packs (or any WAD with textures/flats/etc.). For OTEX, produces the same numbers as Gez's manual compilation:

Loading /data/data/Wads/OTEX/otex_1.1.wad...
Textures: 2624
Patches:  4042
Flats:    1309
Skies:    51
Switches: 26
Animated: 77
AniTexts: 48
AniFlats: 29

And for GothicTX:

Loading /data/data/Wads/GothicTX/gothictx.wad...
Textures: 311
Patches:  303
Flats:    100 and this script represent the extent of my Python experience, so I make no claim to it being "proper" or efficient Python, but it gets the job done. It also optionally dumps lists of the skies, switches and animated textures/flags. For cc4-tex:

Loading /data/data/Wads/CC4Tex/cc4-tex.wad...
Textures: 1229
Patches:  1195
Flats:    406
Skies:    6
['SKY1', 'SKY1B', 'SKY1C', 'SKY1D', 'SKY2', 'SKY3']
Switches: 14
   Off:        On:
[ ['SW1BRN2', 'SW2BRN2'],
  ['SW1COMP', 'SW2COMP'],
  ['SW1GRAY1', 'SW2GRAY1'],
  ['SW1STON1', 'SW2STON1'],
  ['SW1STON2', 'SW2STON2'],
  ['SW1VINE', 'SW2VINE'],
  ['SW1MET2', 'SW2MET2'],
  ['SW1MOD1', 'SW2MOD1'],
  ['SW1TEK', 'SW2TEK'],
  ['SW1MEGA', 'SW2MEGA'],
  ['SW1GOTH', 'SW2GOTH']]
Animated: 10
AniTexts: 9
   First:      Last:
[ ['BLODGR1', 'BLODGR4', 8],
  ['SLADRIP1', 'SLADRIP3', 8],
  ['WFALL1', 'WFALL4', 8],
  ['LAVFALL1', 'LAVFALL4', 8],
  ['SLMFALL1', 'SLMFALL4', 8],
  ['GRYFALL1', 'GRYFALL4', 8],
  ['COMPFUZ1', 'COMPFUZ4', 5],
  ['FFIELDR1', 'FFIELDRA', 2],
  ['FFIELDG1', 'FFIELDGA', 2]]
AniFlats: 1
   First:      Last:
[['GRAYSLM1', 'GRAYSLM4', 8]]

That's just the built-in pretty printing, which doesn't align columns of variable width, but for debugging it's good enough. Suggestions, improvements, bug reports welcome.

The one thing I'm not sure about already is that skies are simply counted by having "SKY" in their names, but there are probably WADs out there with different names for skies. How can those be distinguished from regular patches? --Xymph (talk) 12:52, 10 May 2021 (CDT)

There's no way to automate this AFAIK. In fact, whether with some flavor of MAPINFO or through MBF's sky transfer line effects (or even with console commands like ZDoom's testsky), it's possible to set any wall texture to be a sky texture. FIREBLU2 sky? Possible. SP_FACE1 sky? Possible. DOORTRACK sky? Of course! CRATELIT sky? Don't mind if I do! Failing any sort of technical restriction, using the presence of the substring "SKY" is as good as any other method... —The preceding unsigned comment was added by Gez (talkcontribs) .
Ok thanks for confirming my vague understanding of that part. Well Redneckerz, when you are creating more articles for packs, I can supply the stats if you can't/don't want to run Omgifol stuff yourself. --Xymph (talk) 15:20, 10 May 2021 (CDT)
The listing of textures, patches, flats and skies is useful enough as is. I appreciate your offer to generate these stats whenever a texture pack article is made. In addition to that, i think its time ill delve into the Python tools myself and get the statistics in there myself. Thanks for everything thusfar. --Redneckerz (talk) 13:48, 12 May 2021 (CDT)
YW. I added another dump flag, for the sorted list of textures. --Xymph (talk) 04:24, 13 May 2021 (CDT)
Impressive, thanks for this. The more stats the merrier. --Redneckerz (talk) 06:25, 16 May 2021 (CDT)

Decorate comment[edit]

Did you intentionally delete a comment or was it lost in your own cross-revision cross-fire? :) --Xymph (talk) 13:41, 9 January 2022 (CST)

Didn't delete anything, but i guess the whitespace gave rise to that impression? EDIT: Huh. It seems like i did delete something? It was not on purpose at the very least. --Redneckerz (talk) 13:59, 9 January 2022 (CST)

Doom 2D release date[edit]

Hi, and greetings from the community!

We've noticed that you specified the release date for the original Doom 2D as July 19, 1996.

But this is earlier than all our observations!

So, could you please tell us where you got that date from? And provide a material evidence, if any (e.g. distribution with such a date, etc.).

Thanks anyway.

Sincerely, BlackDoomer. —Preceding unsigned comment added by (talk)

Only now do i see this, apologies. It may very well be i got the naming convention wrong considering the standard here is US-based rather than EU-based. For verification, what is, according to the Doom2D community, the official established release date according to the community's observations? Please let me know. --Redneckerz (talk) 17:41, 18 March 2023 (CDT)
I doubt that you had got something wrong because in any combination of 7, 19 and 96, the latter is clearly an year and 19 is clearly a day. The earliest Doom2D release date we had confirmed is September 6, 1996, when files were modified for infamously known partial English translation of version 1.30, which you may remember as "PSGDOOM" by the SODOM release group and the PRESTIGE team. They released it on September 21, 1996, which is the date claimed in PRESTIGE.NFO that was attached and also the modification date of it. Here's a copy of this file for your convenience: hastebin(DOT)com/share/emadigaxep.sql
The problem is that first installation of RUSSIAN version we know (from "Classic-Fond" CD collection) took place only on October 1, 1996. —Preceding unsigned comment added by (talk)
I managed to find back the exact file. I got it from a drive dump by Fabian (Crispy Doom author) and indeed with the folder PSGDOOM and a September 6, 1996 release date. I honestly can't remember why i made that such a specific date other than that i saw that somewhere, but as i can't back that up, ill just change it to September 6, 1996. Thanks for the callback! - --Redneckerz (talk) 09:54, 19 March 2023 (CDT)

TBSP and DeePBSP[edit]

Here's the citation from README.DOC supplied with DeeP 6.13 ( DeePbsp formerly was called TBSP. TBSP does clear the reject map. So that's why I reverted your edit and why I wrote it in the first place. If you got any other info - please share. --Nockson (talk) 12:50, 22 March 2024 (CDT)

Here's another citation, this time from README.1ST supplied in the same archive: DeePbsp is included. DeePbsp is a DPMI version of TbsP, itself an improved node builder that was derived from BSP 1.2. --Nockson (talk) 12:54, 22 March 2024 (CDT)
Ah, i just realized added that bit in - And i have no reason to doubt it. I don't really like Deep's history all that much: Because other comments from deep himself make it out that DeepBSP is directly derived from BSP 1.2 (And thus there was no TBSP). That, plus the fact that deep released so many versions of deep/deepsea/deepbsp/TBSP (And wasn't it also called BSP16/DeepBSP16 at some point), i was under the impression (From the TBSP archive) that it was a separate program. It also stands for TurboBSP. And when i look back at my own notes, i realized i made a mistake. Maybe interesting: I got all that from RGDMED 2.85, February 22, 1995 - Derived from BSP12X. Nevertheless, i will likely make a seperate page for it at some point. --Redneckerz (talk) 15:57, 22 March 2024 (CDT)
I understand that, for some reason Jack Vermeulen removed that line in later versions of DeeP documentation. TBSP is just a redirect to DeePBSP for now. --Nockson (talk) 16:04, 22 March 2024 (CDT)