ZDaemon Forum Index ZDaemon
Client/Server DOOM
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

[DeHackEd] Item effects are not linked to their sprite names

 
Post new topic   Reply to topic    ZDaemon Forum Index -> Rejected Bugs
View previous topic :: View next topic  
Author Message
EarthQuake
Spamming!


Joined: 02 Apr 2004
Location: Athens, Ohio. Dieblieber gonna getcha!

PostPosted: Sat Feb 19, 2011 5:22 am    Post subject: [DeHackEd] Item effects are not linked to their sprite names Reply with quote

Okay, this is an ancient bug, and one I was just reminded of recently. It's so ancient, that not even ZDoom is still affected by it.

Basically it works like this: in vanilla Doom, the effects of items (ammo, weapons, armor, health, powerups) were granted to the player not because of the actor type, but because of the sprite name of the frame when touched.

Here are some quotes from the ZDoom forums explaining it more:

Anakin S. wrote:
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 wrote:
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...


Items could be duplicated by copying the data from a pickup thing to another thing (even if it is not a pickup item). For example, if I made the blur sphere use frame 802 (first green armor frame), the blur sphere would be an clone of the green armor (except it would count towards the item percentage because I didn't change the bit flags, only the frame). In ZDaemon, however, what this does is make the blur sphere look like green armor, but still give the partial invisibility effect. This is wrong.

Furthermore, attempting to duplicate an item using an actor that is not an item, will spit out a message once at the top (off-topic: which should have a newline character at the end) and do nothing.

This breaks some older patches, even one that had a "random powerup item", and also prevents us from doing anything with items dropped from monsters, since they can't be cloned!

Unfortunately, this bug has gone untouched for so long, there might be some wads that take advantage of it. Still, I think this is a very worthwhile vanilla DeHackEd feature to preserve. If anyone knows of any ZDaemon wads that might break because of this, please mention them.

Attached is a patch demonstrating the bug. This patch is described in Lummox JR's DeHackEd Grabbag, found on Enjay's site. The patch modifies clips dropped by zombies into a clone of the zombie (except in shadow form), and any placed ammo clips are swapped out with archviles that have had the properties copied from the ammo clip. In ZDaemon, you'll notice the placed clip in the starting room of MAP01 is treated as an archvile (it prints the message I mentioned), and not an ammo clip as it should be. In everything else, it works as it should.

Here is the transcribed patch (just plop it into a .deh file and load with Chocolate Doom, ZDaemon, and ZDoom):

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

Thing 4 (Archvile)
ID # = 2007
Initial frame = 870
Hit points = 1000
First moving frame = 0
Alert sound = 0
Injury frame = 0
Pain chance = 0
Pain sound = 0
Far attack frame = 0
Death frame = 0
Death sound = 0
Speed = 0
Height = 1048576
Mass = 100
Action sound = 0
Bits = 1

Thing 64 (Ammo Clip)
ID # = -1
Initial frame = 174
Hit points = 20
First moving frame = 176
Injury frame = 187
Pain chance = 200
Far attack frame = 184
Death frame = 189
Exploding frame = 194
Speed = 8
Height = 3670016
Bits = 266246
Respawn frame = 203
Back to top
View user's profile Send private message Send e-mail
some_random_guy
has entered the game!


Joined: 04 Mar 2011
Location: Planet Earth (specifically Southeast USA)

PostPosted: Tue Mar 08, 2011 10:01 am    Post subject: Reply with quote

I do see why this is unconfirmed. I ran ZDaemon, but the glitch didn't work for me.
I think that that among predefined variables in the engine, there are numbers that identify what DeHacked item number corresponds to a certain behavior, so rather than behavior being part of a sprite, it's part of a thing number.
If this is the case, then if you turn an ammo clip into another actor that can be picked up, it will still give you bullet ammo, but if you give it a different flag that shows that it can't be picked up (like a monster) it would refer to the actor's states and still shouldn't refer to the sprite...

That sounded more complicated than it was supposed to. Very Happy In short, Thing numbers are assigned pickup actions only if they can be picked up.
Back to top
View user's profile Send private message
EarthQuake
Spamming!


Joined: 02 Apr 2004
Location: Athens, Ohio. Dieblieber gonna getcha!

PostPosted: Wed Mar 09, 2011 3:31 am    Post subject: Reply with quote

I don't know what ZDoom did/ZDaemon does to break this, but it seems that currently sprite names aren't tied to the item effects. Any number of things can be going wrong here, and I can only guess at what needs to be done to fix it.

With the patch I posted, yes, ZDaemon tries to pick up an archvile. And because an archvile isn't a pickupable thing, it's going to display the message atop the screen. But that is only the side-effect of this hack not working. Modifying pickup items to use another sprite name will not change what effect you receive.

In vanilla, if you tried to pick up a non-pickupable item, the game would crash with a similar error message. However, because in vanilla, when picking up the item, it checks not what the actor is, but what sprite name it uses. So if running the patch in Chocolate, for example, it would not even get to the point of crashing. The archvile would be treated as a clip, because it's sprite name (upon pickup) is CLIPA0. If the actor used the archvile sprites, it would crash.

I guess what ZDaemon does is check the actor type, not the current frame's sprite name of the actor.
Back to top
View user's profile Send private message Send e-mail
EarthQuake
Spamming!


Joined: 02 Apr 2004
Location: Athens, Ohio. Dieblieber gonna getcha!

PostPosted: Wed Mar 09, 2011 3:47 am    Post subject: Reply with quote

Here's a super-simple patch:

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

Thing 55 (Medical Kit)
Initial frame = 842


Play MAP02 in ZDaemon and observe how the medikit at the start looks like a soulsphere. Now try to pick it up (make sure you've taken some damage first). Oh hey, it's a medikit that looks like a soul sphere!

Now play in Chocolate-Doom. Holy cow, it's a soul sphere now!
Back to top
View user's profile Send private message Send e-mail
Krawa
Spamming!


Joined: 23 Nov 2008
Location: #SDA

PostPosted: Sat Jan 27, 2018 7:49 pm    Post subject: Reply with quote

Problem is still there.

ZDoom: looks like a soulsphere and works like a soulsphere.
ZDaemon SP and online: looks like a soulsphere and works like a medikit.

Demo wad with medikit and soulphere: medikit_soulsphere_demo.wad
Back to top
View user's profile Send private message Send e-mail
Aeyesx
Spamming!


Joined: 13 Oct 2012
Location: Czech Republic

PostPosted: Mon Apr 30, 2018 11:21 pm    Post subject: Reply with quote

Why is this an issue?

There is absolutely no way for linking spritenames with actor properties they belonged to.
It would cause mess. There are more zdaemon wads using this mechanics that would break rather than those super-old wads using this behaviour.

I understand that old doom wads could utilize this buggy behaviour but it makes sense for it to be the way it is from my point of view.
By any means you can always achieve such effect just by making a frame using specific sprite.

Just think about it. You're coding an actor and you define some properities. Now you need some sprites for it, so you take some from hexen and boom! youre actor is acting tottaly unpredictably because of some linking issues?

So as Graf Zahl said. Yes, it is stupid. If ZDaemon was forked when this was "fixed" let it be the way it is. The way it is now I mean.
Back to top
View user's profile Send private message Send e-mail
Body-Guard
Spamming!


Joined: 08 Jan 2006
Location: Hungary

PostPosted: Thu May 03, 2018 11:30 am    Post subject: Reply with quote

Despite what the old doom behavior might have been, item effects SHOULD NOT be linked to their sprite names in my opinion. There are mods out there using various item sprites out of their original context (eg. for other items or actors for whatever reason) which of course relies on current behavior. I might add, current behavior makes more sense. If I want a soulsphere, I use the soulsphere actor, no matter what sprite it happens to use.

Either way, if it is decided to be 'fixed', make it as a dmflag and let the default behavior stay as it is now.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Krawa
Spamming!


Joined: 23 Nov 2008
Location: #SDA

PostPosted: Sun Jul 29, 2018 6:55 pm    Post subject: Reply with quote

So better no change and leave everything as it is.
Back to top
View user's profile Send private message Send e-mail
Aeyesx
Spamming!


Joined: 13 Oct 2012
Location: Czech Republic

PostPosted: Sun Jul 29, 2018 7:07 pm    Post subject: Reply with quote

preciesly
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ZDaemon Forum Index -> Rejected Bugs All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group