[Not a bug] Dehacked: Blur spheres give me green armor

[EarthQuake]

Before anyone says anything, I don't care if dehacked is outdated, the fact is, that this should work. So please spare the dehacked bashing and decorate pimping.

I'm taking the blur sphere and making it use the green armor frames. I'm also applying the gray translation and translucency flags to the blur sphere. The problem isn't that it doesn't look like what I wanted it to, but that when i pick up the blur sphere, I get a green armor! It doesnt matter if I rereference the framesto the green armor, or completely change the blur sphere states, I still get a green armor...

It's as if the sprite itself is connected to the green armor... I suspect it might have something to do with the new inventory system.
Trying this in doom2.exe or ZDaemon yields my desired results. I'm not sure when it stopped working in ZDoom though...

Here's the patch:

Code: Select all

Patch File for DeHackEd v3.0
Doom version = 21
Patch format = 6

Thing 59 (Blur Sphere)
Initial frame = 802
Bits = SPECIAL + COUNTITEM + TRANSLATION + TRANSLUCENT

It works in ZDaemon, and ZDoom 1.22, but not 2.0.96. It also works in doom2.exe with the old patch format. This one obviously uses BEX flags.

[Kate]

Actually it's always been like this since the days of the original dehacked. The armor is tied to the sprite. Some patches use this to create the effect of random powerups and items by flipping through the frames of each item, and other things like replacing non-pickup objects with pickup items which would otherwise be unusable so changing this would obviously cause problems.

[Anakin S.]

Could we see the dehacked patch? Are you using the actual armor sprites (arm1a0, arm1b0) in the animation? If you pick up the item when one of these sprites is displayed, you'll get green armor. Same goes if you use some other item sprite. For example, if you use frames that cycle between ammoa0 and sboxa0, you'll get an ammo box or a shell box depending on which sprite is displayed when you pick it up.

EDIT: According to your dehacked patch, you don't change the sprites of frames 802 and 803, which means arm1a0 and arm1b0 are displayed. This gives you the green armor, not the blur powerup.

[EarthQuake]

Seriously, is this a joke?
Because what you have all explained goes against what I've learned with dehacked. I've never seen or heard of such a patch in classic doom that did what you described. You're claiming that the mere sprite number is what ties an item to its behavior. No, I don't think so, thats what the thing number is for. I've done this before in previous versions of ZDoom and it worked exactly as I expected it to. How can you explain how this works in EVERYTHING else except ZDoom 2.0.9x?

Here's another patch using another method that should produce the same result:

Code: Select all

Patch File for DeHackEd v3.0 
Doom version = 21 
Patch format = 6 

Thing 59 (Blur Sphere)
Bits = SPECIAL + COUNTITEM + TRANSLATION + TRANSLUCENT

Frame 853
Sprite number = 55

Frame 854
Sprite number = 55
Sprite subnumber = 1

Frame 855
Sprite number = 55
Sprite subnumber = 32768

Frame 856
Sprite number = 55
Sprite subnumber = 1

In this one instead of referencing to the armor states, I changed the actual blur sphere states to use the armor sprite. Its a totally different approach.
This one also doesn't work...

Picking up thing 59 should give me a blur sphere regardless of what sprite it uses. It's nonsense...

[Enjay]

[ignore this post, it's bollocks]
For clarity:

Pick up behaviour should be tied to the frames numbers for the item. If you make armour use the soul sphere frames, for example, then it should act as a soul sphere. If you make a clip use mega sphere frames clips should act as a mega sphere (thus you can make a trooper effectively drop a mega sphere for example). This behaviour may seem illogical and there is nothing obvious about the frames in dehacked to tell you this will happen, but it does and it has been like this since the original exe. There was a version of Zdoom (one of the Zdoom 1.23 betas I believe) which broke this, but it was intentionally restored. The problem had been flagged up by one of LilWhiteMouse's mods where she had used this behaviour and it had become broken.

If, however, you make a pickup item use a "normal" frame (ie one that is not normally associated with a pickup) then it should behave like the original pickup item.

I *think* the sprite being used by a frame is irrelevant - it is the frame number that is important AFAIK. If this hasn't been fully explained by the time I get home, I'll be able to check my notes and stuff and confirm.[/ignore this post, it's bollocks]

[Anakin S.]

I *think* the sprite being used by a frame is irrelevant - it is the frame number that is important AFAIK. If this hasn't been fully explained by the time I get home, I'll be able to check my notes and stuff and confirm.

I think the sprite family is what matters, not the sprite number or the frame number. So you could have arm1c0 and arm1d0 and they would still give you green armor. They don't have to be restricted to arm1a0 and arm1b0. There's a file in the source code (forgot what it's called) that lists all the sprite families and the items they are mapped to.

If you're making a blur artifact that looks like a gray armor vest, then use wintex or XWE to replace the actual images for pinsa0, pinsb0, pinsc0, and pinsd0 with the images for the green armor vest.

[Graf Zahl]

Sorry, Enjay but that is wrong!

Doom really used the sprite name to determine a pickup's type! Yes, it is stupid and I have no idea why they did it but that's the way it was. Of course ZDoom corrected this particular mistake (AKAIK it's the only source port that ever did!) but for Dehacked it has to preserve the old behavior. And for that some truly awful hacks are necessary...

[Enjay]

Heh, so all this time my mods have worked but for the wrong reason. In that case, disregard my earlier post as it only serves to muddy the water (post edited to indicate as much).

I assumed my mods were working because I had used the item's frame rather than the sprite but because I hadn't actually changed the sprite in that frame it was actually the sprite dictating what happened rather than the frame number being used.

OK, so if I make a pickup, say the soul sphere, use the pain elemental respawn frames (final frame altered to go back to the sequence start), but then allocate the blue armour sprite to those frames, the soul sphere will now behave as a blue armour pickup despite the fact that the frames being used are neither from the soul sphere or the blue armour? Is that correct?

And what would happen if I didn't change the sprites for those frames? - ie I made the soul sphere use the PE respawn frames, but left those frames using the PE sprites. Would the item behave as a soul sphere?

[Graf Zahl]

OK, so if I make a pickup, say the soul sphere, use the pain elemental respawn frames (final frame altered to go back to the sequence start), but then allocate the blue armour sprite to those frames, the soul sphere will now behave as a blue armour pickup despite the fact that the frames being used are neither from the soul sphere or the blue armour? Is that correct?

correct

And what would happen if I didn't change the sprites for those frames? - ie I made the soul sphere use the PE respawn frames, but left those frames using the PE sprites. Would the item behave as a soul sphere?

Doom would abort with an error message. I have no idea what ZDoom would do in such a case.

[Enjay]

OK, thanks. I'll check the second thing out when I get a chance and report back.

[EarthQuake]

Okay, I've accepted this, but IMO it's probably the stupidest thing I've ever heard. Thanks and sorry, this may have been a blow to me, but at least I'll know now. Still, one thing is unanswered:

Why do my patches behave exactly the way I wanted them to in ZDaemon adn older versions of ZDoom?

[randi]

Why do my patches behave exactly the way I wanted them to in ZDaemon adn older versions of ZDoom?

Because 1.22 is wrong. It changed item handling to be class-based instead of sprite-based, but it did not have any compatibility code in Dehacked to make it look like it was still sprite-based. If you go even older than 1.22 (like 1.17c), your patch would behave as it does with 2.0.96.

[Graf Zahl]

Okay, I've accepted this, but IMO it's probably the stupidest thing I've ever heard.

Don't worry. You are not alone. This totally smells like development garbage that was never changed in the later stages. And for a game that is released commercially without any serious plans to allow this kind of modification it makes sense to leave it in. Don't forget that back then nobody could even imagine DEHACKED.
It's regrettable that ZDoom has to emulate this crap but then, DEHACKED should be obsolete soon (hopefully) so it will only remain as a backwards compatibility option.

[Enjay]

OK, for a final update on what happens with my 2 scenarios:

1. Graf was quite correct. Mapping the soul sphere to the pain elemental respawn frames and leaving them using PE sprites causes Doom2.exe to crash with this message:

P_SpecialThing: Unknown gettable thing

In Zdoom, you just walk through the object, as if it wasn't there. No crash, but no pickup either.

2. Doing the above, but then getting the PE frames to use the soul sphere sprites (any of them) makes the item work normally in both doom2.exe and zdoom.


In addition, changing the PE frames to use the blue armour frames does indeed make the pickup behave like a blue armour object.

I'm glad this came up because it cleared up something that I had obviously assumed incorrectly about how Doom/Zdoom works. I'm just amazed that, despite having done loads of hacks to Doom pickups, I've never actually caused this problem or done anything to make me realise it wasn't working as I had assumed.

[Killo Zapit]

What you can do in DEHACKED is edit the text for the associated sprite number to point to another graphic though. I did that once a long time ago to remap the blue armor sprite (ARM2) to the green armor sprite (ARM1) (that way I could translate it and the green armor into brown leather armor and the blue armor into gray metal armor instead). You could do that to turn the blur sphere spite (PINS) to any sprite you want, just go in the sprites menu in dehacked and change the text offset, or failing that, the text menu and change the text that references the sprite it’s self. I have no idea how well this works with ZDoom, but it worked in vanilla doom great. It may be easier to use decorate subclass the blur sphere and replace it’s frames though.