(oddly enough, this actually revealed some secret file dependencies previously included via r_things.h! I also needed to include d_player.h in r_skins.h itself it seems)
The extra argument is the music name, as passed into
P_PlayJingleMusic(player, musname), to run the hook for, optional.
Arguments are (player, musname) - the latter to allow global hooks
that still differentiate between different tracks.
Makes more logical sense, as if you have a custom follow item for a custom skin, you probably want your new thinker to only run for your new MT_ and not the vanilla ones.
This is accomplished by simply preserving
the player's body after disconnecting.
Bodies will despawn after the number of minutes
specified by the "rejointimeout" console variable (float).
A value of 0 disables the feature completely.
Clients rejoining are identified by their IP address,
and may rejoin even if the server is full or joins are disabled,
for as long as their body remains.
From a technical standpoint, when the user disconnects,
the player they were controlling does not leave,
the underlying player_t just keeps working normally,
except it does not receive any input anymore.
When the user reconnects, they are simply "relinked"
to their player_t.
Those "soulless" players can be identified through
their "quittime" field, which is the number of tics
elapsed since the user disconnected, or zero
if still connected. "quittime" is exposed to Lua.
The above issue occured only if you had both a generic hook and a type specific hook for a particular hook type. This way, the stack is never updated to include damagetype at the start, and all pushes of the variables get offsetted by 1 compared to what they should be, once the code *expects* damagetype to be included in it.
* Takes function(player, mo) input.
* Return TRUE for stating that yes, the player is in a state that can cause contact damage, do with that what you will.
* Return FALSE for stating that no, the player is weak and vulnerable and cannot cause contact damage, do with that what you will.
* Return NIL for allowing the function to continue regular operation.
Fills a different ideological niche than ShouldDamage - that's for determining whether damage dished between two objects should happen, this is for determining which way around damage should be dished when considering a player-object interaction.
Or, in other words, think of it as "ShouldDamage is whether damage that has been requested should be granted, for object-object interaction, while PlayerCanDamage is for whether global player properties should cause damage to enemies and monitors in the first place, like spinning, hammering or stomping."
