what is the carcass of a player classified as?

I know it is not a player-list object, because member objects of the player list "(players)" are only living players.
In other words: if player is a member of the list "(players)", (unit_get_health (unit player)) returns -1 for all index values of player greater than the max index value of living players. so if there are three living players out of 5 in-game players, (list_get (players) 3), (list_get (players) 4), (list_get (players) 5), (list_get (players) 6), ..., (list_get (players) n) will return -1 for some finite integer n.

My first assumption was that the carcass was some other type of object.

I, then, assumed that the carcass was a generic cyborg_mp object since it possesses the "characters\cyborg_mp\cyborg_mp" object_definition, possessed by all cyborg_mp objects. (tested through the (objects_delete_by_definition <object_definition>) function).

Then I tested the (garbage_collect_now) function on generic cyborg_mp objects and they weren't affected, whereas the carcass and dropped equipment were affected.

This led me to believe that the either 1. the carcass was not an object (meaning (garbage_collect_now) manipulates non-objects, and non-objects can have an object_definition), or 2. the carcass along with the equipment, became special types of objects. (which the garbage_collect_now function can manipulate.)

if 1. is the case, what does the carcass become?
if 2. is the case, what type of special objects are these? (note, that by attaching objects, if one deletes the parent, the child is deleted; so if the equipment was attached to the dead biped, then the biped could be the only special object.)

I searched for "garbage" inside my Halo CE folder and found nothing significant, except some forerunner structure ".garbage" tags.

My brain exploded

Deleting by definition doesn't always work to begin with (in fact, the only situations where I've even attempted to use it, it hasn't. So, either it doesn't work, or I am good at finding special cases. Although, I can explain one of those special cases within reason... but still.)

Continuing on, you can load the players body into a object global variable. You can continue to use that global even after they've died. This means they are objects.

I would have to say, the body still has an association with whomever it was, which is effecting your ability to mess with it. It is actually possible to keep playing as a corpse, I did it once for lawlz. Given what data OS gets about who damaged who, the bodies actually have to be associate with whom they where, otherwise you couldn't get grenade kills after you died.... Although it could get away with just comparing pointers if the body doesnt exist... If you feel like, make the player something like a sentinel where its destroyed after death, and throw a grenade before death. Check how that handles the kill since its different. (I really need to keep fishing through OS' source files, and find where half this stuff is even implemented.. rawr, so many files everywhere. Reading the whole damage tracking part should help you with whatever you want to know though)

I managed to delete by definition. but deleting cyborg_mps is not a good idea for what I am doing, since living players get respawned (without adding a death to their counter).

I loaded the player objects onto a global object variable, but only when triggered by walking into a volume, which failed when the player was killed before entering the volume.
I then attached an indestructible object, to check for that instead, which fixed the trigger-volume checking, but I still could not manipulate the carcass.

I will look into the damage tracking though, thanks. I had forgotten grenade kills get tracked through a player's death.

*carcass sounds cooler.

I don't think that getting grenade kills after death has anything to do with tracking the player's body (dead or alive).

If you think about things from a theoretical perspective, the player is merely a control interface for the biped. The biped, while alive, is classified as an object, whether it is being controlled by something or not. When the player gains control of it, it then becomes part of the unit player list [i.e. (unit (list_get (players) n)) ].

When a player dies, (s)he loses control of the biped, which in turn loses its classification as a game object and plays a death animation. The player never goes away, just the thing being controlled.

All that to say, when you run into glitches where you stay inside a corpse, its probably just the game failing to cut off the player's control of the biped after it is destroyed. The biped itself has lost its classification as a game object and is most likely re-classified as garbage. This would not need its own garbage tag because it just undergoes a re-class from biped to garbage.

Hope that makes sense.


EDIT: Merry Christmoose!

Edited by MoooseGuy on Dec 24, 2013 at 10:54 PM

However its stored, OS gives you access to it in scripts, via the bodies. If you find what part of the code does it, you can check whether its defaultly via object (which would be the bodies in this situation), or whether OS merely converts that data to objects.


Its still a biped, even when its dead; it never stops being a biped. The garbage collection scripts are just set to include dead bipeds, the same way they grab weapons even though those are weapons and not garbage.

Sorry, I kept using the word carcass because I couldn't remember any other word to describe a dead body; although I can see why corpse is a better term for what I am describing.

Anyways... this is probably trivial to you all, but I think I discovered how to manipulate the player's corpse after the player is dead.

It seems, that in a continuous script, non-conditional statements are carried out in a regular order, along with checking conditions in conditional statements. so for example.
(sv_say "1")
(if true (sv_say "2"))
(sv_say "3")
(if true (sv_say "4"))
carries out thee functions in the order of 1, 2, 3, 4.

However, when you have multiple functions bound to a certain condition, they appear to be evaluated altogether, and then their combined output is carried out, within one "iteration" of the script. Note: I use the word iteration (possibly mistaken), because they needn't be carried out on the same tick. I tested this hypothesis.
By binding a sleep function of more that 1 tick with a certain condition, between two functions that could not be carried out in different iterations (because of memory referencing); the two functions were carried out successfully.

To make things clearer: You can use a conditional in which the biped is about to die (to reference the object), bind a sleep function by the same condition, then mess with the player object while it's dead, by binding it with either that same conditional, or using the condition with which you slept the script, if you use sleep_until.

My intuition on why this works is that when you load an object onto a global, you are pointing at the address of that object, and that address remains the same until the next iteration of the script; which is when the functions have been carried out. The reason I think conditionals protect you from referencing non-existent memory is that you can manipulate a certain address under some condition, and set the condition to false after all functions have been carried out, so that the memory you were manipulating is no longer referenced in the next iteration of the script.

Hope that was clear enough.