Death system fixes / corpse decay

[AcadiusLost]

1. Are we changing weapon drop on death to end up in corpse inventory?


2. I did a bit of testing with the corpse decay system- two PC corpses (from the same GSID) worked fine over several module resets, in terms of persistent inventory and location. However, when I shut down the server and advanced the server timestamp manually by editing the DB (to simulate time passing beyond the "decay" threshold), strangeness takes hold.

On initial module reset (and subsequent ones) the bodies are still present, and still retain most of their persistent inventories. The exception, in both cases, was the "body" item- all-important for moving/carrying/disposing of the bodies. They became, in effect, permanent non-decaying corpses.

However, when I then logged back in with one of the dead/decayed PCs, and tried to use the rez lever, it failed, and the ACR renamed/reset the corresponding corpse as Decayed. A subsequent module reset removed both corpses.

Any idea what's going on here? Seems like we have several potential bugs present:

1. The PC corpses are only being successfully tested for decay OnEnter of the corresponding PC, rather than during RestoreCorpsesOnModuleLoad().

2. Seems like some clause that doesn't involve DB access (didn't see anything in xp_mysql.txt associated with the switch) is deleting the "body" item from the inventory after the "decay time" has lapsed, at least after a server reset.

3. Update of the "decayed" status of one corpse seems to be also affecting a second corpse, which was associated with the same Player (GSID), though the character was separate.

Cipher, any thoughts on this? I was testing with essentially the same code on the SVN for acr_death_i, with only the removal of the ACR_PreLoadStorageObject() call in RestoreCorposesOnModuleLoad() - I was worried that it was calling another DB function from inside RestoreCorpses' SQL loop- which I expect you remember can terminate it before completion.

[ç i p h é r]

You experience that behavior because the corpses have inventories. If the items are removed, the corpses should go away. As long as items remain however, a corpse will be created to serve as a container for them. This is handled in the RestoreCorpses function, I believe.

With respect to the rez lever, looks to me like that tool (and quite possibly a rez/raise attempt on the corpse) circumvents this behavior, so there does appear to be at least one bug. Probably not doing the necessary checks in the rez/raise function.

p.s. If we can store these items in the SQL database, I think we can abandon the corpse containers entirely and just spawn in remaining "inventory" items into the game world.

[AcadiusLost]

Got some fixes debugged and tested to my satisfaction. Committed, and rolled into the new alfa_acr.hak on the worldgate:

1) Instakill limiting. No single attack will be able to push a PC below -6 HP. Any damage above and beyond this threshold will be skipped, allowing all PCs some chance of stabilization or healing by others, even in case of massive critical hit damage. Bleeding proceeds at 1 hp/rnd therafter, so death will occur in 24 seconds if no stabilization checks are made (checks are 10%, success slows bleeding to 1 hp/min, and allows 10% chance for "consciousness").

2) Stabilization resolution. PCs who stabilize on their own used to get checks every game-hour (7 minutes RL), which was quite tedious. This has been changed to every turn (60 RL seconds).

3) Recovery. Natural Healing checks were previously made 1/game day (3.5 hours RL), now will fire (during dying only) once every 2 minutes - each has a 10% chance of starting the PC on the road to recovery at 1 hp / 2 min, until they reach 1hp-consciousness. The other 90% of the time, it will dump the PC one point further into the negatives.

4) Corpse Decay - this will now be checked OnBash and OnDisturbed, should help permanently clear up bugged corpses.

The net intention of these changes is to 1) mitigate player frustration with straight-to-morgue hits, and 2) speed up resolution of the bleeding/dying/stabililzed state- so players aren't left wondering what they're supposed to do when stuck "stable" in negatives. This allows for a small chance for survival of a solo brush with dying- but should usually end with death.

oh, got the weapons and shields dropping to corpse inventory as well. Long day.

[Teric neDhalir]

Long day.

And very appreciated.

[darrenhfx]

Wow those are great changes, what Teric said.

[Wynna]

Thank you, AL. Very important changes to improve the game and player experience of the game.

[ç i p h é r]

About 2 & 3. Those changes mean that players will sit and wait in the morgue rather than where they were felled and, if raised, suffer XP penalties. Are you certain that this will be less frustrating? It's not as if they can get back to playing any sooner to try and recoup their lost XP.

I would think that if players understood their choices, it would be vastly preferable to stay out of the morgue for as long as possible to give themselves the best chance of being revived without the need for resurrection. But that's my opinion.

[AcadiusLost]

For Live play, DM tech rezes of PCs who die out wandering on their own should be fairly rare. The problem we have with the previous (PnP) system, is that it's written with tabletop gaming in mind, where the DM can say "a day passes, roll percentile dice". When the waits between checks are seven minutes each for stabilized consciousness versus bleeding, and 2.8 hours apart for natural healing, it's unreasonable to expect the player to sit at his or her computer for many hours, just to see whether their character survives.

The temptation would be very strong to metagame the location of the stabilized PC, passing it to others who would be put in the difficult position of risking upsetting the player versus metagaming themselves to seek out the body.

Or, the player could log out and check back later- but right now, since bleeding/dying picks back up where it left off, that represents something of an exploit as well, and gets marked as suspicious by the logging scripts. It's basically the player presuming nothing unfortunate happens to the helpless and defenseless PC over however many game-days they are offline.

Finally, they can contact a DM to try to resolve the stabilization condition with an encounter of some sort (could be good, could be bad). Though some DMs will vary on this- I expect most would rather not be urgently called in for "on-demand" arbitrary ruling on life/death of PCs.

We don't really change the odds one way or another with this setup, just speed up the resolution- if anything, it increases the chance of recovery, because very few players would have the 16.8 hours it would take to recover from -6 HP after an extremely lucky set of rolls by the PnP time frame. Heaven forbid they stabilize at -9, that would take more than 28 actual hours (not in-game ones!)

I worked this one out in discussion with Rusty and Wynna via IRC, I think it represents a good balance of our needs.

[Runestaff]

I worked this one out in discussion with Rusty and Wynna via IRC, I think it represents a good balance of our needs.

This sounds like a welcome improvement. The old system, quite frankly, was a real PITA during beta testing (particularly before the XP gong was added).

One issue this doesn't seem to resolve: what behavior should be expected of monsters that put PCs into the negative hp range? Currently, they essentially just stand over the PC doing nothing (assuming no other PCs are in the area), meaning a recovered PC stands a good chance of getting nailed as soon as they stand back up.

So you may want to consider having them wander around after a short time, despawn, or attempt a killing blow. Could this perhaps be made dependent on creature type (e.g., a lion might try to eat the unfortunate PC)?