From DoomWiki.org

Revision as of 14:00, 10 May 2021 by Gez (talk | contribs) (Texture/palette automation?)

GgiDoom

"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!

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

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

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?

Regarding these comments: my bot scripts don't parse WAD files, only Omgifol (drawmaps.py) 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, texpackstats.py 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

drawmaps.py 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'],
  ['SW1BRNGN', 'SW2BRNGN'],
  ['SW1COMP', 'SW2COMP'],
  ['SW1GRAY1', 'SW2GRAY1'],
  ['SW1METAL', 'SW2METAL'],
  ['SW1STARG', 'SW2STARG'],
  ['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...