I'm just going to accept that my 2 hours of sleep and patience for people who are failing to see the difference are not there.
Run your static zones, run as many as you want. They're completely unnecessary though in today's code.
Or you can fidget with maintaing launch tables, static port nailups, nail up resources on your machine for seriously no difference in end functionality.
In the end how you run your server is mere personal preference, but arguing against delayed shut down dynamics because they don't fulfill keeping proper spawn rotations or grids in tact is flat out wrong and to illustrate false information on the forums like that irritates me because I spend plenty of time making sure people have the right resources, right information, right tools available to them - then to argue with me about something that has zero premise is retarded.
If you need me to write it out on the board for you this is how it goes.
In the main zone process loop you have the zone->Process loop, which is active during an active zone:
https://github.com/EQEmu/Server/blob...pp#L1198-L1205
When this returns false - that means a shutdown timer (dynamic delay) will allow the zone to actually flush spawn timers, npc tables, data that is loaded in the zone. Just because a zone is dynamic doesn't mean it flushes its data until the shutdown delay is fulfilled, this triggers Zone::Shutdown
https://github.com/EQEmu/Server/blob...e.cpp#L672L717
Again - the end goal functionality is no different, except for that fact that you've nailed up unnecessary resources right away, using way more memory than necessary, cpu idling and you're fiddling with over complicating managing something.
Code:
if ( numclients < 1 && zoneupdate_timer.GetDuration() != IDLEZONEUPDATE )
zoneupdate_timer.SetTimer(IDLEZONEUPDATE);
else if ( numclients > 0 && zoneupdate_timer.GetDuration() == IDLEZONEUPDATE )
{
zoneupdate_timer.SetTimer(ZONEUPDATE);
zoneupdate_timer.Trigger();
}
A static zone or dynamic zone are going to go into idle status the same, function the same, serve the same end goal - thus making the argument that dynamics are not live-like bullshit.
Even if you want your fancy boats to not be in the same spot when players zone in. The first player might see that boat at the dock, but that boat is always going to path regardless of idle or non idle after that zone has been booted.
And regardless of cross-zone boating, shits been broke for ages. Boats hardly work in themselves - and it shouldn't rely on both zones being up in order for that to happen otherwise that is poor design.
Code:
update zone set shutdowndelay = 604800000;
Done.
First time a player enters that zone, it's up for a week AFTER the last player exits it, and when they re-enter that timer is replenished - AND that zone never is recycled with another zones scripts/resources.
Also - there's issues with eqlaunch that freak out over extended use and require a server restart to fix.
Your other alternative is to run the zones manually 'zone soldungb', but if that zone crashes you need a way to automatically revive it? What's the easy solution? Run the simple launcher I created with dynamics and it will keep those dynamics nailed up instantly.
If that isn't clear enough for you I don't know what is.