Feature: There should be a min and max for respawn instead of a static number

[neifion-00000000]

Describe your feature request or suggestion in detail

Note: This is a separate issue from the dynamic spawning system which has to do with spawning more to make up for population.

I have proven fairly extensively spawn timers should not be static and there is always a range by finding an adequately fast enough spawning one and hammering it to some length (I also used to farm lotus on retail, it also follows this behavior). This is something I've experienced everywhere in my sniffing In my opinion the system is weighted to pick faster respawns less often but that is less proven.

imo respawn should be changed to min and max should be added (if 0 then max=min)

Nyeriah mentioned it and I cofirmed vmangos has this feature already

Describe a possible solution to your feature or suggestion in detail

No response

Additional context

No response

[Ovahlord]

What you observed is called dynamic respawning. The respawn timer scales with the amount of triggered respawn timers. In some other cases Blizzard just uses pools with a min-pool size, meaning that they enforce respawns to maintain a minimum number of active objects.

dynamic respawning is already implemented in TC.

[neifion-00000000]

What you observed is called dynamic respawning. The respawn timer scales with the amount of triggered respawn timers. In some other cases Blizzard just uses pools with a min-pool size, meaning that they enforce respawns to maintain a minimum number of active objects.

dynamic respawning is already implemented in TC.

this is simply not the case and I addressed this in the note

I have done this on the both live and the PTR, when I am often the only active player on the entire server, you can test it on a single spawn and notice every respawn timer will be different (except in cases where they actually do have a static min/max)

The easiest way to prove this is to find something with an already fast respawn timer and camp it and check, you will not see static results.

Often the variance will be relatively small, but I have at least one example where the range is 5 to 90 seconds min/max. This is also the correct way to address rare mobs and world bosses that have variant timers imo.

Another way you can tell intuitively is if you loot static objects (not all quest objects are staticly spawned, but some are) in a specific order they will not respawn in any set order or pattern twice in a row.

Some npcs have quicker respawn timers, like quest bosses. This can be handled in SAI. Most have the same unless properly pooled to lessen respawn time.

[neifion-00000000]

I mean I already have a concrete example of this, the snapper quest in Draenei start zone has this behavior, and its fairly widespread in general.

https://www.youtube.com/watch?v=1cNUYTV_Ss4 56:05, respawn 56:35 (30 seconds)
57:38, respawns at 58:03 (25 seconds)
00:32, respawns at 01:00 (28 seconds)
01:31, respawns at some point in the low :50s (under 25 seconds)
02:06, respawns at 02:36 (30 seconds)
02:36, respawns at 03:00 (24 seconds)

Chest spawns have this behavior and you can tell pretty clearly from my old sniffs where I was determining pooling because I also estimated respawn timers, but there was drastic variation (due to the nature of pooling I was able to create an approximation of this mechanic in that case, but a better way would be min/max values).
Black Lotus spawns before they were changed were on timers ranging from 45m to 1hr15m (my personal estimate from farming several hundred)

creatures also show this behavior but I have a lot less data on them due to the length it takes on them to respawn, but one thing I remember is that wildlife mobs in Teldrassil had a decent sized variation and before I decided it was impossible to account for properly I was tracking it

Also, further info regarding creatures, creatures that in our emulator belong in formations would share the same value timer, but that almost belongs in its own issue.

[heyitsbench]

Might be a duplicate of #7592 as well as #5751.

[Gultask]

Closing due to duplicate