Lol it's funny watching you guys try to learn the mysterious workings of the server
[You must be logged in to view images. Log in or Register.].
Anyways, one of you mentioned QuestManager::UpdateSpawnTimer, and you would be correct:
Quote:
[Sun Dec 22 21:23:47 2013] You say, '#screenshake global 5000 6'
[Sun Dec 22 21:23:48 2013] You say, '#emote world 15 A mysterious tremor has awakened some powerful creatures! (Simulated Patch Respawn)'
[Sun Dec 22 21:23:48 2013] A mysterious tremor has awakened some powerful creatures! (Simulated Patch Respawn)
[Sun Dec 22 21:23:49 2013] You say, '#peval quest::updatespawntimer(250195, 1);'
[Sun Dec 22 21:23:49 2013] You say, '#peval quest::updatespawntimer(250194, 1);'
[Sun Dec 22 21:23:49 2013] You say, '#peval quest::updatespawntimer(227817, 1);'
[Sun Dec 22 21:23:49 2013] You say, '#peval quest::updatespawntimer(227818, 1);'
[Sun Dec 22 21:23:50 2013] You say, '#peval quest::updatespawntimer(250443, 1);'
[Sun Dec 22 21:23:51 2013] You say, '#peval quest::updatespawntimer(246905, 1);'
[Sun Dec 22 21:23:51 2013] You say, '#peval quest::updatespawntimer(250442, 1);'
[Sun Dec 22 21:23:51 2013] You say, '#peval quest::updatespawntimer(250440, 1);'
[Sun Dec 22 21:23:52 2013] You say, '#peval quest::updatespawntimer(221906, 1);'
[Sun Dec 22 21:23:52 2013] You say, '#peval quest::updatespawntimer(223959, 1);'
[Sun Dec 22 21:23:53 2013] You say, '#peval quest::updatespawntimer(228429, 1);'
[Sun Dec 22 21:23:53 2013] You say, '#peval quest::updatespawntimer(227815, 1);'
[Sun Dec 22 21:23:53 2013] You say, '#peval quest::updatespawntimer(227816, 1);'
|
#peval is a command that lets me run perl straight on the zone at runtime. It can also run the embedded classes from perspective of my PC and any NPC I have targetted.
As far as mob spawns go, the spawn time is stored in memory of each zone. The only time the database is touched is when the zone is booted up to load it, and when a mob dies to set it.
Coding a respawn system is not difficult, the problem is coming to an agreement with how we want it to be handled. We want to respawn every mob, not just raid mobs, but we want a way to do that without being intrusive to people who are already sitting in a split camp room. Don't want to respawn 5 mobs on top of them for surprise buttsecks.
So someone suggested "Just give a warning then".. but then if we have a warning, we have 100+ raid players poopsocked on the raid mobs before they even spawn. We have camps being stolen when people leave to get to safety, etc.
There's a lot more to consider than how the actual mechanics work.
Concering QuestGlobals, we don't use them. They were an inefficient system that we phased out, like mostly anything else that required consistent database checks. There are many systems we've changed/overhauled/removed from the base EQEmu code, and many custom implementations. We prefer as much caching as possible, offloading as much as possible (All logging goes through packets to a backend service instead of being inserted directly). Our Entity ID tracking system was recoded by Haynar to use an array of pointers instead of a linked list iterator.
A linked list iterator is fine if the base code used it correctly, but there are so many examples of horrible redundant loops occuring the base code that it's extremely inefficient.
For example, any type of EntityList->GetMob. Let's use a derivitive of that, which is something like GetOwner(), which is how a pet references it's master. It would store it by EntityID instead of Pointer, and every time it needed to access it, it would iterate every mob in the zone until it finds it.
And THEN you'd have situations like:
if (GetOwner()) { // Yep I have an owner
GetOwner()->DoStuff();
GetOwner()->DoMoreStuff();
}
You just iterated through the entity list three times for the same pointer. /facepalm.
So.. Haynar and I worked over several years to do many changes...
First, storing pointers so that something like GetOwner() is a direct inline return, instead of a function call to an iterator.
Second, we recoded our entity storage to use an array of pointers instead of a linked list.
This means more memory usage overall, but we have lots of memory, and not as much CPU. So storing an array of 3k 32 bit pointers is a better trade off for the saved CPU of iterating the entire entity list thousands of times a second.
So, I got a bit off topic.. but I'll let you guys jog your memory with that info for a while
[You must be logged in to view images. Log in or Register.]
(I also worked to get rid of as many sql queries during runtime as possible.. as stopping the zone to wait for a query response is a huge performance hit.. but I've already rambled on too much).