Bug(?) involving missing sprites, SisterWeapon and 3D models

Tue Oct 16, 2018 11:21 pm

I'm not 100% sure this is a bug, but at the very least it's a very odd behavior that left me baffled for a few hours, and it doesn't seem to be documented.

It's known that when a weapon is missing a sprite, you can't pick it up or use it with Give/Use commands or anything else (this could be better documented as well). But there is an exception: when you obtain that weapon via another weapon with Weapon.SisterWeapon, you can use the weapon with the missing sprite. It will be invisible, but you can use it normally. Another thing is that SisterWeapon will allow the 3D model to appear even though the sprite file that is referenced in MODELDEF is missing.

edit: I should probably clarify that I'm not using the WEAPON.POWERED_UP flag. I use SisterWeapon solely as a means to obtain another weapon automatically, without having to replace something, randomize, or having it drop from a monster.

Sharing my tale in detail in case someone else has a similar problem:
It took a long time for me to figure out what was wrong, because the weapon was a sisterweapon of another for the longest time, so I had never had to "pick it up". The weapon uses a 3d model, which needs a sprite to replace (or something) even though the sprite itself can be anything and is not shown. A long time ago I had renamed the sprite which is referenced in MODELDEF, to see what would happen. Nothing happened, and I forgot I had renamed it. Now that I have new methods to obtain my custom weapons, I removed the SisterWeapon property from the related weapon (among other things), and some time later I noticed I could no longer pickup or use this weapon in particular. After trying dozens of different things, I put it back as a SisterWeapon on another weapon and voila, I could use it again. Convinced that there was nothing wrong with the weapon itself, the MODELDEF definitions and the model files, I went to take a look at the sprite files, even though I was sure that the sprite name didn't matter because of the 3d model. I noticed the sprite name had been renamed, and sure enough renaming it to be the same as the one in MODELDEF solved it.