Zone Instancing

[Rocker8956]

This was probably already asked, if so can someone point me to the correct post?
When a dynamic zone is first loaded is everything loaded into memory? Or does the server need to reference the zone’s database entry for pathing, spawns, loot table, etc?

I am asking because I think I may have a way to deal with zone instancing, such as LDoNs. But it I think for it to work all of the zone info would need to be loaded into memory.

Here is a summary of my initial thoughts for LDoN zone instancing. Sorry if it is hard to follow.

Database setup
LDoN Table fields - AccessFlagNum, MapName, uniqueZoneName, Timer, GroupID, FlagCount
Group LDoN Table fields - GroupID, AccessFlagNum, Char1ID, Char2ID, Char3ID,
Char4ID, Char5ID, Char6ID
(could add adventure objective fields later)

Player Requests LDoN
Server checks if player is leader
If No, rejects request
If Yes, server checks if group has 3 or more members
If No, rejects request
If Yes, server checks if any group member already has an access flag
If Yes, rejects request
If No,LDoN is offered

Group Leader accepts LDoN
AccessFlagNum created
Search LDoN.AccessFlagNum for first available flag number
Start at 01,
If 01 exists move to 02, etc…
If 01 does not exist, create 01
Entry made in LDoN Table and Group LDoN Table
Server checks which zone map to load for that LDoN
Server loads unique zone from map and access flag number
Zone is named by map name plus access flag number (mmca23)
Access flag given to leader and group for that zone


Player tries to zone into instance
Server checks flag to determine which zone to place player in
If no access flag exists it boots player back to previous zone, or a defualt zone
If access flag exists player is sent to zone based on access flag #

Player successfully zones into instance
Start timer

Player completes LDoN objectives
Zone timer set to 115 minutes

Player leaves adventure
Remove one from FlagCount

Zone stays active until
It has been active for 130 minutes or greater

Zone deactivates
Remove access flag from any marked with it
Remove LDoN Table and Group LDoN Table entry
Reset/remove timer

[trevius]

That sounds pretty good for how LDoN should work. But, zone instancing still doesn't work and there would need to be a way to get that working first.

I think you would need a separate timers table just for LDoN zones since you would have multiple instances running and each would need separate respawn timers unique to the instance. So you would probably need a way to track each instance. Maybe something like "zonesn##" or something, so the first instance of mira would be "mira01" and the second instance of guka would be "guka02" etc and it would be entered in the table. This name could be used to track which groups are in which instance number and also which spawn timers are being used for which instance as well.

There would need to be a way to boot multiple instances, which might be nice if it could be done with a quest command. Maybe something like "quest::bootinstance(zonesn,charid,timer,timeo ut)" could be used and an exampe of it being used might be "quest::bootinstance(mira,$userid,7200,120)" which would boot mira for the user who initialized the quest and the timer for the zone would be set for 2 hours to complete it and the timeout is 2 minutes, which is how long they have to enter the zone before it shuts itself down. Then, as long as the the leader of the group is the one that started the instance, everyone else in his/her group/raid should gain access to the zone. I imagine that some of the new group and raid tables could probably be used to help keep track of group members.

Another option for instancing might be to just adjust the the zones table to add in another field that will check if a zone is instance-able or not. If the zone is set for instances, then when a group zones into it, an instance is created just for their group/raid ID.

I am sure people would love to see LDoN implemented. I know there are plenty of things in it that still need work. Maybe with enough ideas some work can be started. At least with a rough outline on how to make them work, it gives something to go by.

[ChaosSlayer]

i want to point out that LDON has NEVER been instanced

at no point in time the same LDON zone was running at the same time for 2 different groups. The groups were simply sent to diffirent ldon zones

the only true instancing are sewer trials added in GoD and from there on

if you want to implement ldon like feature all you need is to set aside few zones which cannot be entered wihout help of quest npc, and a npc outside the zone which will hold a timer and prevent others from entering

[MNWatchdog]

You sure about that ChaosSlayer? I dont remember people lining up outside to get into a LDON which is what would certainly happen on a server with 3k people rushing to new content if multiple copies of LDONs werent instanced.

If things were not instanced, only like 5 groups would be able to do any particular LDON at a time and with them taking up to an hour each, there would certainly have been HUGE lines of people waiting to get in.

[trevius]

Ya, I am almost 100% sure that LDoN was instanced. I did quite a few LDoNs after it first came out and I never remember having to wait even though tons of people were going in all of the time. I think they only had multiple versions of the zones so that there would be more variety so it didn't get quite as boring doing them over and over and over again.

I think PoTimeB was instanced too, at least for a while. But then I think they changed PoTimeB to just work as an event that was reset after X amount of time.

[Flare83]

PoTimeB was semi instanced at first, meaning only 1 time raid per server at a time. I remember setting up rotations with other guilds so we could all get a chance to raid.

After DoN was released i think they changed it to be fully instanced.

[rojadruid]

I would have to agree witht he LDONs not being instanced on live in the beginning. Thats why they created all the copies of the ldons with a "a", "b" and so forth. I also remember not being able to get an adventure at times on the live server that I used to play on. I also think that the way that Rocker8956 is looking to implement it, as thats looking pretty much like the way that it was on live.

[Rocker8956]

If I recall correctly when LDoNs first came out there were lines to get into them. I think this had to do with Sony putting a cap on how many instanced zones could be running at the same time. This may be a good idea for us to implement after we get instance zones running. Since having 50 instance zones running at one time could really hinder what most of us are using for a server.

On a different note,

I must be blind, can someone point me to the section of code that deals with loading zones?

Hopefully after looking at it I can answer my question below.

Using the current code for loading zones and assuming we could get two instances of a zone running at once.

If PlayerA is in BoThunder and kills a mob a respawn timer starts?
So if PlayerB then zones into a different instance of BoThunder that mob would not be up?

Basically I am wondering if the server writes any information to the database when a mob is killed or is it all handled in memory? Mobs being up or down are my main concern here.

Hopefully that made sense.

[So_1337]

Check the spawn2 table. Respawntime and timeleft are the things you're looking for.

For any given spawn point, there can be different mobs that spawn at it, but only ever one at a time. When whichever is up is killed, a value is written to timeleft equal to the respawntime value. It'll look different, since it's in milliseconds. It'll count down until it reaches 0, at which point a new mob will spawn.

[ChaosSlayer]

yeah I am prety sure. note that its more like 10 groups per Theme rather than 5.
which means total of 300 peopel could be in ldon at same time, and whiel servers did had rathly 2k-3k people, you need consider hwo many were on line at the same time (no more than 1k), drop all under 20s, skip all who did not had the expansion ( i didn't until like 6 month later for exmaple), and how many were actualy inetersted in ldon, and you will see that 300 players is PLENTY of room, except very ocasinal times

[Congdar]

As I remember the LDON's it was set up with the Wayfarers such that there would be limited types of adventures you could choose from.

Collect 30 of these
Kill the Boss
Kill 30 of those
Rescue the victims

And they were level based and had timers as well. I remember waiting with my group until a Collection adventure was offered. This makes me think that they weren't instanced at all. Just that say the collection adventures would use say zone ruja, rujb, rujc and the victim adventure would use rujd, ruje etc.

[Rocker8956]

Hmm, it looks like the easiest way to handle zone instancing would be to have multiple database entries for the same zone. By easiest I mean least code and least server intensive.

Using the RajA zone as an example, we could do something like this in the database.
(I am at work so the table, field, and map names are made up)

ZoneName, MapName
RajA01, RajA
RajA02, RajA
RajA03, RajA

We would also need to setup the spawns, along with other things, for each zone - RajA01, RajA02, RajA03
The spawns would essentially be the same for each zone excluding uniqueIDs, respawntime, timeleft, etc.
This would take a lot of database entries but most of it would be copy and paste.
This method puts a cap on the number of times a zone can be instanced but I highly doubt any of our servers will hit that cap. If one ever does we would just need to add another database entry.
Any thoughts?

[Rocker8956]

The other method I can think of is for the server code to create database tables for each instance as needed. It would need to copy/paste static zone info, mainly spawn timers, into the newly created table. This seems overly complicated and probably not necessary for the population of most servers.

[Rocker8956]

Ok, now I feel stupid. I finally get what Trevius was saying in his first post. His method would require the least work to implement.

So if I understand, initially we need to
1. Add a table to track instance zones’ spawntimers
2. Add a field to track if a zone is instance enabled.
3. Add a table to track temporary access flags based on characterIDs
4. Write code so if a zone is instance enabled the server checks how many instances are open and uses the next available number to name the zone but still bases its information on the original zone’s information.
5. Write code that checks to see if a player has the required access flag to enter the zone. Then places the player in the correct zone based on that flag.
6. Implement a way for quest commands to boot an instance zone.

Did I miss anything?

If this is already our method for zones please let me know as it will probably be this weekend before I have a chance to look into the emu code since I crashed my server at lunch time. By crashed I mean BSOD.

[MNWatchdog]

Im sure LDONs were instanced. Werent limited to 5 or 10. The suffix of A, B, C, etc reflected the map layout of the dungeon you were running. You could start in several spots in each of the various layouts.

Reason people were standng around waiting for a instance was you were limited on how fast you could do the next instance, but it had nothing to do with people waiting for an instance to be available after successfully doing an instance. If you failed, you could start right back in.