SphereServer BugTracker - SphereServer
View Issue Details
0002211SphereServerexecutable - windows buildpublic30-09-13 02:0902-10-13 00:22
Coruja 
Ben 
normalminoralways
resolvedfixed 
 
0.56c Nightly 
Automated (specify build number)
None
None
0002211: NPCs applying wrong properties on t_corpse when die
On my server I use a custom corpse carving that uses the corpse MOREZ to get the NPC chardef on dead corpse, and then use <SERV.CHARDEF.<MOREZ>.RESOURCES> to create the corpse resources on carving.

But I found a strange behavior, MOREZ will set the correct chardef value if I kill a 'monster' (ettin, zombie, etc). But killing animals (horse, chicken, etc) the MOREZ will become a negative value which totally mismatch the chardef.

I can't find the related property (fame/karma/notoriety/brain/etc) to reproduce this problem, but owner/tamed has no relation, I tested on tamed and untamed horses and both has wrong MOREZ.


I dont know, but it could be related with this:
04-09-2013, RanXerox
-Fixed a bug in @kill trigger where, if enabled, a killer would not get credit
 (karma, fame, experience) for the kill.
-Killing c_horse_tan I got MOREZ=-56 (correct value: 200 / chardef 0c8)
-Killing c_chicken I got MOREZ=-48 (correct value: 208 / chardef 0d0)
-Killing c_titan I got MOREZ=76 (fine, titan uses chardef 76 / 04c)
-Killing c_gargoyle I got MOREZ=4 (fine, gargoyle uses chardef 4 / 04)

PS: I'm not using @Death or @DeathCorpse triggers
PS: Anyone can check if t_corpse on wiki is updated? :D
http://wiki.sphere.torfo.org/index.php/TYPEDEF [^]
No tags attached.
Issue History
30-09-13 02:09CorujaNew Issue
30-09-13 23:10RanXeroxNote Added: 0001696
01-10-13 01:34BenNote Added: 0001697
01-10-13 02:22CorujaNote Added: 0001698
01-10-13 16:44darksun84Note Added: 0001699
01-10-13 17:09darksun84Note Edited: 0001699bug_revision_view_page.php?bugnote_id=0001699#r532
02-10-13 00:22BenNote Added: 0001700
02-10-13 00:22BenStatusnew => resolved
02-10-13 00:22BenFixed in Version => 0.56c Nightly
02-10-13 00:22BenResolutionopen => fixed
02-10-13 00:22BenAssigned To => Ben

Notes
(0001696)
RanXerox   
30-09-13 23:10   
Which client version does your sphereserver use? Are any of those mul/uop files modified?
(0001697)
Ben   
01-10-13 01:34   
you do realize that MOREZ is suppose to contain the direction it is facing... where did you get the idea that it's the chardef?
(0001698)
Coruja   
01-10-13 02:22   
the server is AOS, but support client 4.0.0 up to 7.0.24 (I'm using 5.0.2, resdisp 5). Using same AOS mul files that I use since 2007 (without any mod)

I always used MOREY to get the chardef without problems. But this month after update the nightly build, the MOREY doesnt point to the chardef anymore. Then I changed MOREY to MOREZ, it works with some problems and also doesnt match the wiki

I made a quick debug again (.add + .xhits 0) and got this:

c_llama corpse facing NW (chardef 0dc [220]):
-morex: -1
-morey: -1
-morez: -36 <- wrong value

c_llama corpse facing SW (chardef 0dc [220]):
-morex: -1
-morey: -1
-morez: -36 <- wrong value

c_rabbit corpse facing S (chardef 0cd [205]):
-morex: -1
-morey: -1
-morez: -51 <- wrong value


c_gargoyle corpse facing SW (chardef 04 [4]):
-morex: -1
-morey: -1
-morez: 4 <- correct value

c_orc corpse facing S (chardef 011 [17]):
-morex: -1
-morey: -1
-morez: 17 <- correct value

c_orc corpse facing SW (chardef 011 [17]):
-morex: -1
-morey: -1
-morez: 17 <- correct value
(0001699)
darksun84   
01-10-13 16:44   
(edited on: 01-10-13 17:09)
Yes, imho the t_corpse properties "get shifted" in some way, in fact

MOREX now holds the uid of the killer(it's supposed to be in more2).

MOREM instead holds the facing position(instead of morez)(if humanoid)

And MOREZ holds the creature id(instead of morex+morey)

Actually it' possible to get some correct ID from MOREZ :
The rabbit gives -51, if you convert it in hex you will get FFFFFFFFFFFFFFCD, 0CD(205) is the rabbit id.
Same the lama FFFFFFFFFFFFFFDC (-36), 0DC(220)
Anyway you can't get the ID in this way from NPC that have morez values > 255


So well i think they got shifted in some way :P

(0001700)
Ben   
02-10-13 00:22   
Prety sure I found the problem (yes they were getting shifted because of a change I had done to the size of server time value... oops :D)
Will be in next build as I didn't get it in time for tonight