This isn’t the same as the pooling, which I will get back to. But, this is something that will I think go hand-in-hand with it.
Provided the local guids PR is merged, I think it gives us the chance to get correct (or at least more correct) respawns, for those creatures not in pools. Here’s how I think it can work.
[ul][li]Creature table updates with new columns for override_despawn and override_loot_despawn. These will default to 0.[/li][li]New configuration option for default corpse despawn (with loot and without loot)[/li][/ul]
When a creature dies, instead of hiding the corpse after a set time and then respawning the same guid. The following will happen:
[ul][li]At the point of creature death, the creature DB guid will be added to a respawn list, with a respawn time. The creature despawn event will be set to happen at the despawn time (for non looted creature)[/li][li]If the creature is fully looted, the corpse despawn time will be reset to the timer for looted creature.[/li][li]Regardless of the above, if the respawn timer is up, the creature will be respawned with a new guid.[/li][/ul]
This doesn’t replace the pooling changes, since they bring other useful features. However, it will ensure that the rest of the creatures behave in a consistent way. It also disconnects the despawn time with the respawn time. I think adding the override to the DB allows for some fine tuning where some creatures should have a faster respawn time.
Another change, not directly associated by this, but certainly it will be aggravated by this. The guid pool on 3.3.5 at least has the chance to be exhausted. So, I think some configuration options and courses of action need to be considered. Here’s my proposal.
[ul][li]New configuration options for warning guid threshold (default 12million). Panic threshold (default 16million), and quiet time.[/li][li]When the warning threshold is passed in any map, a server restart will be scheduled at the next upcoming “quiet time”[/li][li]If in the meantime the panic threshold is met, the server will immediately perform a restart (with a 15 or 30min timer)[/li][/ul]
This is just to ensure that an overflow event is avoided.
Questions, comments, suggestions I’d like to hear them all.
They’re time in seconds just like normal respawn columns. The idea that 0 will mean use the global config for the creature rank and otherwise the value in the DB will be used. So it allows an override of sorts.
For the timers I got the info from here http://gaming.stackexchange.com/questions/78923/how-long-do-corpses-remain second large post. I used it as the basis for default settings on the pooling change too. There’s no proof other than that and in 6.x I’m fairly sure at least that this changed. In new zones at least corpse despawn is damn fast and respawn definitely quicker than before.
“Looting a boss while a player is outside of the instance will no longer cause the corpse to despawn in 2 minutes if the player still has loot on the corpse.” which makes it clear at least that the despawn for looted corpses is 2 minutes and that there is a difference between the two. This was obviously a problem caused by the system not considering the loot for that player as loot while they weren’t inside the instance and dropping the timer…
Something else I am considering adding, depending on how how much load it is likely to add (I think it won’t be a great deal, but time will tell) is some similar solution to the minimum spawns in the pooling system.
The only static solution I could think of, that would likely not add too much load is to reduce respawn times (for new deaths) based on the number of players in the grid square. Options are
[ul][li]Basic gradient (not sure this will scale so well as it will start too slow I reckon).[/li][li]Curve, I think it might be overkill but will solve the problem in point 1.[/li][li]Logarithmic. Well, to an extent. I think maybe, we deduce 30% or so (configurable) from the spawn time for each player in the same grid with a minimum time set too. So with a 15 minute respawn time, the time would be 15s at 10 players in the grid, and will drop quickly towards it with less players in.[/li][/ul]
I think grid is convenient since it should already be possible to get this information.
However, to me this also seems counter-intuitive. Players in the area doesn’t mean you need to raise the spawn speed. Ideally I think it should be based on creatures alive in the area. However, I’m not so sure there’s currently a low cost way to know how many alive creatures there are within a grid square or radius or even by area. If that is possible (I’ve not looked much yet) then I think it would give the more smooth result. As more creatures are killed the spawn time gets faster until more become spawned, it’d slow down gradually until there are a certain number and then the normal speed would resume.
I don’t think it would make them active. It just needs to know how many out of the valid “spawns” in that area, are alive. Based on a percentage working on a curve or some other algorithm it would decrease the respawn time based on that percentage. Of course it needs checking how much extra load this would produce and how viable a solution it is. For pooling it was easy to make a cheap solution based on upkeeping a minimum per pool. Doing something for creatures outside of this system is a bit more tricky.
For the pathed creatures, I think the solution lies not in making the area active, but some low cost option of ensuring the creature moves (or at least appears) to move along its path if a player is anywhere near that path. That’s another story though. Not forgotten but, aside from this issue I think.
Yes, but this is dealing explicitly with the respawn and it includes creatures in cells that might not be active. They don’t need to be active to be counted. TC can know if a creature is dead, or alive or at least the ratio of dead//alive can be collated and compared. So nothing needs to be activated that isn’t already.