Mmmmm simulated patch day

[Juevento]

Well thanks for ruining this self congratulatory post with your brogramming chatter.

Anyways thanks to the server staff for the unexpected bit of fun yesterday. It was great to see all the different guilds knocking down targets.

[kotton05]

Thanks for repop and the brogramming talk look like Chinese to me

[Messianic]

Have you tried turning it off and on again?

[heazels]

So I was thinking about, you could potentially code in scheduled patch dates or have a macro that triggered it when you logged in game(ie have a command /Schedulerepop for January 15, 2014 and update that date to DB). However you have to set the date out after the next mob repop. I have never looked at the code for this game but here is a rough idea.

PHP Code:

TimeOfSpawn = Random(7days whatever)
ForcedDayReset = CheckDBforRepopDate(whereveritsstored)

if(TimeOfSpawn >  ForcedDayReset) Then
    SetSpawnTime(ForcedDayReset)
Else
    SetSpawnTime(TimeOfSpawn)
EndIf 


And Do this whenever the intial /random is called when the mob dies. so make the /scheduledrepop command in game have a requirement of being 1-2 weeks out.

[Splorf22]

This is actually a very clever idea. There is no reason the server cannot compute the next 5000 simulated patch days or whatever and stick them table somewhere. It's not quite as nice as the GMs having the ability to trigger things, but it should be pretty straightforward to implement - probably only one or two places to change.

[Vandy]

From my understanding they want it coded in for Random weekly repops. Where they can implement it and let it run with no need for staff to do anything.

[Rogean]

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:

[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).

[Elmarnieh]

If you don't want it to be intrusive to existing camps for xp groups and stuff for named (so that casuals can enjoy it to which I totally get) you could change it from an instant spawn to something else like "You hear something powerful in the distance approaching" to give like a 1-2 minute of warning to regular camps.

[August]

Originally Posted by Rogean [You must be logged in to view images. Log in or Register.]

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.

You could do batch spawns, with a warning trigger on the first one and a slightly smaller batch.

"All of Norrath shakes as an earthquake rocks the earth"

Then split mobs up into a batches - static or run-time chosen (for instance, no need to spawn mobs that already are up). Space the waves about 2 minutes apart. Gives people time to get to a safe zone, let's everyone know that it's happening, and people will have to choose targets quickly.

Just my 2c.

-august

[baalzy]

Originally Posted by Rogean [You must be logged in to view images. Log in or Register.]

SNIP

Just to offer my suggestion on a possible solution. When repop occurs grant everyone a temporary immunity shield (say 10 seconds total immunity and then up to 10 minutes immunity if they don't move, incase they were afk) and spawn an instant-click, 1 use, lore, no rent/expires in 10 minutes item on their cursor that succors them. Could code this only for zones where it might be dramatic to have everything repop on them instantly. This would give people the option to either:

1) Attempt to reclear their camp and if they get overwhelmed they have a temporary safety net.
2) Clear out immediately
3) Wait a couple minutes for some backup

Not the most elegant, but if you truly want to respawn every mob in the game I don't know how you could do this in a way that guarantees someone won't have a pile of mobs dropped on their heads unexpectedly. At least you're giving them a safety net if they can't handle the sudden repop and a huge leg-up if they just happen to be in the right place at the right time and are capable. The other solution would be to have some kind of proximity check on all of those high-value targets and delay their repops and give warning. That sounds expensive on CPU usage.

Could maybe couple it with a game-wide full heal/mana refresh.