ZDoom

Well unless Blutz3 has anything to add -- well then it's fixed all right - just have a look at [url=http://forum.zdoom.org/viewtopic.php?f=15&t=16612]this[/url] Feature Suggestions thread :wink: (especially the last screenshot, taken with DOOM style weaponry in a rather un-Doom-like map :) )

Done. I trust this is all fixed now?

Yeah, nullimage is a carry over from before I switched to the token parser.

That's what I thought.

Graf, please would you apply the informal patch I gave above and close this thread? It's all that's needed for this problem. Of course, when Mancubus is back up (so that it can be committed) it is anybody's guess :(

"" should always be a placeholder for 'nothing'.

I think that "" should be accepted in addition to "nullimage" to draw nothing - since it's already got a precedent (in Decorate, something like [b]Inventory.Icon ""[/b] would clear an existing inventory icon for an item that inherits from another, etc).

OK, the problem is that 'Weasel is using "" instead of "nullimage" when he wants no image displayed. This either means changing the parser to treat "" as equivalent to "nullimage", which is kinda consistent with the rest of ZDoom, or else documenting in the Wiki that "" isn't acceptable and rejecting an empty string as an error.

Opinions?

EDIT:

I patched sbarinfo_parser.cpp line 1077 of my working copy
from [b][color=#0000FF]if((stricmp(patchname, "nullimage") == 0)[/color] [/b] to [b][color=#0000FF]if[/color][color=#BF0000] ([/color][color=#0000FF](stricmp(patchname, "nullimage") == 0)[/color][color=#FF0000] || (patchname[0]==0))[/color][/b]
for the moment, but [i]should[/i] it be allowed, that's the question... :?

In case Blutz3 is reading this, I have narrowed down the [b]drawswitchableimage [/b]crash - it happens when you do not possess the corresponding weapon. Commenting out all but 1 and 2 works, because you start with fist and pistol. Uncommenting 3 crashes, but if you do [b]+give supershotgun[/b] on the command-line starting zdoom, it doesn't crash. I shall investigate further -- when I have the time... :)

Added the diff.

Bug left open for the crash.

OK, I have found a fix for the STF thing - basically all skin faces are entered into the image list with their own namespaces during the statusbar display initialisation; I'll post a cleaned-up diff of this later. Cuttys CUT status face works with a fullscreen weasel HUD, yee-haa!

Now I have to find out why it crashes in drawswitchableimage :(

EDIT: Posted STF fix diff. Still have to find out why drawswitchableimage crashes zdoom!

I'm posting here to say that I have read this and will get to fixing it as soon as possible. However, as soon as possible might not be until Thursday or later.

No. The textures for skin faces don't exist normally - they have to be created when used for the first time. That's where FTextureManager::AddPatch comes into play. It gets passed a WAD namespace identifier which is retrieved from the skin.

You mean the "usetype" argument should be the skin's namespace (presumably 0 is ns_global, which is why it works for STF)?

No, this one's Blzut's baby. ;)

The Doom status bar does find the face textures because it explicitly looks for them (See FDoomStatusBar::SetFace.) But from what I gathered from the SBARINFO code it doesn't set the texture namespace for this case properly.

And BTW, the fix in the other thread is not temporary. The code should have never been removed and was the direct cause of the face not working anymore.

Please refer to [url=http://forum.zdoom.org/viewtopic.php?f=7&t=16715]this[/url] thread, for which Graf provided a temporary fix by reverting the change; I have also experienced crashes when using SKINs and SBARINFO at the same time.

The underlying cause is that the texture manager includes a search algorithm at line 105 of texturemanager.cpp and this fails to find a graphic if it is a face image provided by a skin. In the case of SBARINFO, DrawMugShot calls the texture manager, which cannot find the status face in the texure collection and returns a null pointer -- which gets returned into the "face" variable at line 1244 of sbarinfo_display.cpp and the rest of the mugshot code duly tries to dereference :evil:

This problem does NOT occur if the skin is not in force and the DOOM2 IWAD STFs are thus used.

To reproduce:
1) Download [url=http://www.martinsobservationpost.net/system/cutman.zip]this[/url] SKIN wad.
2) Download [url=http://forum.zdoom.org/download/file.php?id=4968]this[/url] SBARINFO wad.
3) Start ZDoom without the HUD wad, and set the player to use the CUTMANMIKE skin then quit ZDoom.
4) Start ZDoom again but with the HUD wad.
5) Result = access violation in GetScaledWidth() on line 817 of r_defs.h

I don't know the heck about the internals of the texture manager, so sorry Graf/Randy - this one's your baby :)