akkadius scripts + static zones

[Akkadius]

Originally Posted by Shiny151

The disadvantage to dynamic zones is this:

If you have a named mob you want to kill that has a minimum chance to spawn every four hours that also has a placeholder with a zone shutdown delay of one hour, you could essentially check the zone every hour in the hopes that the named is up without having to kill the placeholder. Granted, the zone has very little foot traffic to prevent the zone from staying open/active.

With a static zone, let's say the placeholder is up. It will STAY up indefinitely until someone kills it. Thus not allowing lazy players to cycle-check the zone.

The solution? You'd want the dynamic zone shutdown delay to match or exceed the longest timed mob that has a placeholder in the zone in order to behave more static and live-like. I know it was an example, but an hour shutdown delay won't always do it for the crafty loot-seeker. Which basically means you'll need a custom shutdown delay for every zone you don't want this happening in.

Not really a disadvantage of shutdown delay functionality itself than it is configuration of your own server

[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

[NostalgiaEQ]

Originally Posted by Akkadius

Not really a disadvantage of shutdown delay functionality itself than it is configuration of your own server

That's very cryptic but what I think your saying is a server should be designed to not have unused zones. But with a live like or classic like server this could be a problem. Also it isn't very classy when you zone into a place with a boat and the boat is always waiting at the dock. For me I feel a good solution is dynamic zones and an 8 hr blanket zone reset time which should prevent any mob cycling but would still have the boat issue. I'll survive.

[Akkadius]

Apparently no one read or understood anything I said in my first post about how dynamics operate with a delayed shutdown.

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

[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



___________

[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

[creakin]

Originally Posted by Akkadius

Dear god



___________

This makes me chuckle

[dburg30]

So if I change the zones="xx" in the bat file, after a certain point in the one server launcher window, the zones will continue to count up.. ie: if I put 100 in the zones=. It will count up to 100 in the windows server launcher, but will then start counting again, but not from 0/100, somewhere higher, but when it gets to 100/100 it will restart again.. Is there a limit to how many zones it will load? my memory is not running out. Does there need to be a delay somewhere that it loads them?