akkadius scripts + static zones

[N0ctrnl]

I don't understand the militant stance on this one. It's absolutely a limitation of dynamic zones vs. static ones. Sure, it's easily overcome, and not expensive to do so, but to pretend that dynamic zones fit situations like this is just not right.

[Akkadius]

Originally Posted by N0ctrnl

I don't understand the militant stance on this one. It's absolutely a limitation of dynamic zones vs. static ones. Sure, it's easily overcome, and not expensive to do so, but to pretend that dynamic zones fit situations like this is just not right.

What is there to pretend?

It's pretty simple.

And I don't understand why there is even an arugment against it.

Why would you allocate say 80 zones a head of time as statics, memory, usage, and idle CPU utilization that are completely unecessary when essentially the same functionality of a static can be fulfilled on demand via dynamic when a zone request is booted, and then nailed up for as long as you wish (a week if you wish).

It serves the exact same purpose.

But what do I know, I don't run any servers or anything

[N0ctrnl]

As long as that delay is a finite number, the purpose is defeated though. At least if you intend to emulate EverQuest behavior of spawns.

[NostalgiaEQ]

Yes you can make shutdown delay 50 years in seconds but I think some of us are OCD and want a more elegant solution . Its not an issue though there are so many more important things to work on and fix.

[Akkadius]

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.

		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.

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.

[Warkral]

Originally Posted by Akkadius

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.

		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.

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.

Cool thanks, bookmarking this thread as this answered a HUGE question for me regarding keeping a zone up for respawns.

[N0ctrnl]

I completely understand and agree with what you're saying. Though you can leave the ports to dynamic in the launcher and ignore that part. Also, they restart just fine even if static.

If you do set the timeout delay to a week, or a year, or a decade, it's functionally static after the initial launch though, correct? Until the obscenely long timeout is met and it actually flushes the zone?

The idea for my use case has always been like Live - If an NPC spawns, it's going to be up with exactly the same loot table until a) the server gets rebooted, b) he gets killed, or c) the zone crashes. Certainly there's a cost to running a static zone, but to keep that case working for any situation - even one where a zone might not be used for a week - I would just choose static in that case.

Like I said - I get it. But if you use a launcher for the static zones, a lot more of the benefit columns get ticked.

[Akkadius]

Originally Posted by N0ctrnl

I completely understand and agree with what you're saying. Though you can leave the ports to dynamic in the launcher and ignore that part. Also, they restart just fine even if static.

If you do set the timeout delay to a week, or a year, or a decade, it's functionally static after the initial launch though, correct? Until the obscenely long timeout is met and it actually flushes the zone?

The idea for my use case has always been like Live - If an NPC spawns, it's going to be up with exactly the same loot table until a) the server gets rebooted, b) he gets killed, or c) the zone crashes. Certainly there's a cost to running a static zone, but to keep that case working for any situation - even one where a zone might not be used for a week - I would just choose static in that case.

Like I said - I get it. But if you use a launcher for the static zones, a lot more of the benefit columns get ticked.

Dear god



___________

[creakin]

Originally Posted by Akkadius

Dear god



___________

This makes me chuckle

[SCROFT]

Originally Posted by creakin

This makes me chuckle

LOL

They say they understand... but totally missed your point.

[DanCanDo]

Just curious, is it possible to set up individual (player.pl) scripts containing
an enter_zone sub, with a 'randomaction' - 'depop' for specific npcid's?
Just giving it a chance that something might be up (if it isn't already).
I haven't attempted writing one yet, but it's crossed my mind in the past,
as an alternative.

[Maze_EQ]

yes it's possible using sub EVENT_ENTER_ZONE

[DanCanDo]

Yes, I am aware of the sub, I use it a lot my server, I wasn't really asking a question,
I was throwing a "hint" for people to read as an alternative. I don't mean the posters
in the thread, it's for that overwhelming community that likes to (cough) read

[jpyou127]

Which takes precedence the database zone shutdowndelay value or the database rule AutoshutDownDelay value?


Celestial

[Akkadius]

Originally Posted by jpyou127

Which takes precedence the database zone shutdowndelay value or the database rule AutoshutDownDelay value?


Celestial

The zone one, always.