Mmmmm simulated patch day

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

[Estu]

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

there is no indication that weekly repops are even being considered.

http://www.project1999.com/forums/sh...99&postcount=9

Also, just send a PM to Nilbog. I've seen him post many times about simulated patch day repops and have talked to him in IRC about it and he has always said that he wants it to happen. I can't overstate how good these would be for the server and the community, or how much the players would appreciate it. The recent raid scene agreements and the new VP policy have been amazing but it would be equally amazing to have the greater amount of boss monster pops and consistency that would be offered by simulated patch days.

[quido]

I finally got power back at 1am today, so after a little research, I see now why this is a somewhat difficult process. I figured out how to see if a particular mob is up just by looking at the database, and I learned how to adjust the respawn timer so that the mob will be set to repop whenever, but apparently getting the actual mob to pop requires the invocation of some function within the zone (you can use the #repop GM command while in the zone, or you can use a parallel quest function that is attached to the zone), and as zones are within their own processes, there is no easy way (that I can see) to do this for all the raid zones.

It seems to me that the solution, like Aeolwind said, is to use a hidden spawn and check $qglobals for a repop condition within the quest manager. Questglobals are inefficient as Aeolwind said due to being routed through database queries, but if you had a mob that popped every minute or two or three, checked for the condition, repopped the raid mob if the condition is met, reset the condition (also if condition has been met and the mob repopped), and then despawned the mob, the overhead would be minimal.

I will try to figure out how to setup such a spawn here soon.

[Estu]

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

I finally got power back at 1am today, so after a little research, I see now why this is a somewhat difficult process. I figured out how to see if a particular mob is up just by looking at the database, and I learned how to adjust the respawn timer so that the mob will be set to repop whenever, but apparently getting the actual mob to pop requires the invocation of some function within the zone (you can use the #repop GM command while in the zone, or you can use a parallel quest function that is attached to the zone), and as zones are within their own processes, there is no easy way (that I can see) to do this for all the raid zones.

It seems to me that the solution, like Aeolwind said, is to use a hidden spawn and check $qglobals for a repop condition within the quest manager. Questglobals are inefficient as Aeolwind said due to being routed through database queries, but if you had a mob that popped every minute or two or three, checked for the condition, repopped the raid mob if the condition is met, reset the condition (also if condition has been met and the mob repopped), and then despawned the mob, the overhead would be minimal.

I will try to figure out how to setup such a spawn here soon.

Good stuff, Jeremy!

[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