<3 <3 <3

Always interested in hearing from potential developers.. but it's not an easy job. I believe Rogean would want to personally deal with this particular implementation because it heavily involves the raid scene.

For people interested in development, talk to me in IRC. As a quick note: C++/mysql/perl.

killing the quest npc will clear it.

Why isn't it a one-liner? Something like

if(patch-day-random-check)
GMCommand(initiate-reboot, 5 minutes)

or something like that? Or does the server not have some kind of watchdog?

Well, for one.. a server reboot doesn't clear respawn timers. We do that manually after a patch. Assuming that is part of the function, there are still other considerations.

Do you reset the whole server? Is there a need? Wouldn't it be just as beneficial to not disconnect everyone.. yet have the npcs repop?

If this is in addition to the normal respawns per week, a simple repop wouldn't achieve the same goal. Many 3 or 7 day npcs would still only pop once that week.

On a per-npc basis, how about the mechanical specifics? Nagafen dies.. that's a Ragefire spawn? Interfering with existing? .. etc.

Not a one-liner to achieve desired results.

You just got schooled by Nilbog, son.

Not likely. The case for a classic patch day schedule would probably look something like:

1. Define a simulated lifecycle by evaluating the timetable of updates (and associated downtime) that resulted in a server-down scenario in classic EQ. You would want to pay attention to updates that don't follow an update pattern and the frequency of skipped updates and adjust your lifecycle accordingly. Example: updates every three weeks +/- three days, plus six updates a year that fall out of cycle, minus four updates that are in cycle but don't occur. Generate downtime randomly between, say, 30 minutes and 360 minutes. Manually override an undefined number of updates a year to fall outside of the window of downtime.

2. Evaluate the percentage of updates that resulted in a full repop of value targets, and apply that to the defined cycle.

3. Construct a table of value targets that would require attention given a patch day - raid mobs, quest mobs and the like. This would be worth doing anyway (especially for Velious), and could benefit from crowd-sourced input.

4. Develop a method of spawn timer reset for such a table that would result in a majority of user acceptance given the variance inherent to the raid scene on P99. For example, if a mob has a variance of +/- 72 hours for spawn time N, any -N value would result in the spawn being available when the server comes up and any +N value would result in the spawn being delayed according to that value.

5. Identify any exceptions to the above variance; i.e. a high-value target that is always available when server uptime begins. Example: Trakanon is +/-X hours during server uptime, but is always available when the server comes up after a simulated patch day.

6. Identify any exceptions to the high-value target table where a game mechanic is affected by a simulated patch - i.e. mobs that require game input to spawn - and either remove those from the update table or independently develop code that restores continuity to the environment given a simulated patch. Examples: Ragefire, Avatar of War.


Benefits: "classic" patch day environment and scheduled downtime that would allow for actual patches and modifications to be implemented without negative feedback from the player base

Detriments: hard commitment for the administration to manually oversee each simulated patch instance, whether or not an update actually takes place, potential for exploitation of simulated patch days if the root timetable is leaked or otherwise discovered through independent evaluation of update frequency/characteristics

TLDR: 50+ hours of environment evaluation and coding pre-implementation, plus time each cycle to monitor the conditions of the environment post-patch (i.e. ensuring mobs actually spawn appropriately, and service time that will inherently be required to address raid scene issues due entirely to the fact that a host of raid spawns will suddenly be available or will be due upon server reset)

I mean I'm sure you can do something better than what I said if you put more time into it, but considering that it's been almost a year since the original repop thread maybe it's time for something quick and dirty.

As a developer myself... those are some famous last words right there.

FWIW: nilbog and crew don't do anything unless its done right.