* Hooks are no longer a mess of lua boiler plate. Helper functions reduce hooks
to, at the most basic level, only two calls.
* Lua tables (the array part) are used to index hooks. Such tables contain only
hooks of the same type.
* Hook types are defined in one place so you no longer need to sync up the enum
and name array.
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.
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.
* 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."
