Zone Instancing

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

[AndMetal]

Spawn conditions would take care of what LDoN dungeons do, which is to spawn a certain set of mobs (levels) based on certain conditions. The only real hard part is creating copies of all the mobs needed, including different levels, stats, etc, then interconnecting all of it. I think that's the main reason there isn't much happening with them. However, once you have the spawn conditions configured, you can trigger them using quest::spawn_condition(). Example:

sub EVENT_SAY {
	if ($text~=/Hail/i) {
		quest::say("Do you want to start a [task]?");
	}
	elsif ($text~=/task/i) {
		quest::spawn_condition("raja", 1, $Group->GetHighestLevel()); # spawn condition id of 1 equals whatever the highest member's level is in the group, which is what level range everything should be tuned for
		quest::say("Have fun!");
		quest::zone("raja");
	}
}

One of the nice things about the spawn2 table is that the respawn timers use the spawn conditions. For example, the max level character in the group is level 50 and every mob in the instance (minus some roamers?) have a respawn time of 2 hours (how long the instance stays opened?). If you enter the zone with a max level of 49, all of the mobs spawned for 49 would spawn on their own timers. If you rezoned with max level of 50, they would still be carrying the respawn timers (the remainder of the 2 hours).

I have a feeling that zone instancing can be done using something like spawn conditions. I know for a fact you can run 2 of the same zone by zoning into a dynamic version, then booting up a static version without zoning. The problem then becomes determining what should or shouldn't be done in an instance vs a regular version, how do you create entry to an instanced zone, and what is the best way to make any zone instanced if you want to (for custom servers).

Kinda rambling & thinking out loud, I would think that instances could be based on groups, raids, and guilds. The type could then be defined in the zone table as an additional column, possibly inst_type (0 = normal, 1 = group instance, 2 = raid instance, 3 = guild instance). Then, if someone attempts to zone into one of those zones, and they meet the requirements (are in a group/raid/guild, have X amount of people in the group/raid), they zone successfully. If not, return false.

Anyway, just some thoughts...

[trevius]

Just to make a note about it, since it was mentioned; the reason that people had to wait to get the kind of adventure type they wanted was because SOE set a minimum time between how often you could request adventures. This is so people would either have to do the random adventure they gave them, or they would be forced to wait until they were lucky enough to get the one that they wanted. Otherwise, people would all just be doing the same ones over and over again. Having a minimum time to wait meant that each type they had created would be used instead of just the favorite or easiest/quickest ones.

Those are the only times I ever remember waiting at all for LDoNs. Of course, for the emulator, I think that we could potentially set it up to be done without any instancing and not have to worry much about running out of room for players. If we did that, then all we would need to do is get the adventure system working and set it to chose the first available zone in the zone list for that particular theme. We wouldn't need to worry about spawn timers or anything, because everything would still work like normal zones.

I think the progress towards getting the task system done could probably have most of it applied towards getting LDoN adventures working.

[Rocker8956]

Well I think I have a starting point for the code portion
Zone\zone.cpp
Zone\zonedb.cpp

and maybe

Zone\zoning.cpp

I am still trying to understand alot of the code in here but it is late so I am headed to bed.
Just thought I would post the code location incase someone else was looking for it.

If I am off on where the code needs editing please let me know.

[Rocker8956]

Well after looking through the code this is definitely out of my league. Though here is what I think needs to occur for zone instancing to work.

Add a UniqueID to field to the zone table that increments for every zone, including ones that are added.

Add a InstanceZoneType field to the zone table.
0 = Not a instance capable of being instanced
1 = A zone capable of being instanced that is for only one player
2 = A zone capable of being instanced that is for a group
3 = A zone capable of being instanced that is for a raid

Add a InstanceZoneFlag field to the character_ table

When the players InstanceZoneFlag field is set the server will need to create a new entry in the Zone table by copying all of the information from the zone’s entry that matches the short_name.

When a zone is started the server checks to see if that zone’s InstanceZoneType is greater then zero
If not the server goes about the zone loading as normal
If it is the server gets the zoning players character_.InstanceZoneFlag
The server then checks to see if a Zone.UniqueID matches that player’s InstanceZoneFlag
If it does then the zone is loaded and the player is sent to that zone based on the Zone.UniqueID

Sorry, if this post makes no sense. I was up all night looking through the source code trying to figure it out.