New sprites in addons do not work
If a sprite doesn't have the same name as one of the original games sprites, Dday doesn't render it in game (it displays a mobj shadow as if it is rendered though).
The 'listtextures' console command shows the sprites as being loaded/read by Dday.
I attach three files, for Heretic E1M1, as a test. The single room example map features a simple custom bad guy and the original games barrel mobj.
The bad guy uses sprites with a new name while the barrel uses one of the same sprites as a replacement of the barrels original sprite. The bad guy is invisible in game while the barrel displays.
#2 Updated by vermil about 8 years ago
Well, I was testing in the latest unstable.
I actually pulled the graphics from one of my old pk3 based mods; when I run said mod with Dday, the sprites display fine. But if I extract the wad from my pk3 and use it by it'self (edited or not), Dday seems to no longer displays the sprites.
#4 Updated by vermil about 8 years ago
One thing I have noticed though, is that when the (suitable) new sprites are used on hud weapons, Dday doen't simply not render them, rather it actually crashes with this error message, when a hud weapon tries to display a sprite in question.
Loop: Uncaught exception during loop iteration:
[MissingResourceError] (ResourceSystem::spriteSet) Invalid sprite id -1
^ : Application terminated due to exception:
#5 Updated by vermil about 8 years ago
I've now given my mod files a kludged go in Doom (my files are for a Heretic mod) and the same issues occur; sprites that are named the same as original sprites in the loaded game are fine.
But sprites with new names either don't display (mobj) or crash Doomsday (new weapons) with the above error.
I've tried Doom format lumps and in wad PNG's also.
#7 Updated by danij about 8 years ago
It would appear this is a game startup order issue. The reason the sprite does not appear is because it is missing in the DED sprite names database at the time the sprite numbers are assigned to state_ts in Def_Read().
This works fine for sprite names which are already known because they are defined by the old Sprite (name) definition mechanism (which the built-in definitions use).
However, "extra" sprites in addons don't automatically receive an entry in the DED sprite name database. ResourceSystem::initSprites() tries to account for this by automatically assigning an unused index to any extra sprites it encounters. This happens too late for the state_t setup which happens after Def_Read()
Note that there are several further issues with the sprite names database, particularly regarding DEHACKED. This whole mechanism needs rethinking.