Implementing: Instancing

[Jabantiz]

Yea that is a bug then. Both clients should have ended up in the base zone and not create a separate instance.

[John Adams]

Okay, I feel progressive today. Thanks for the feedback. For my next ramble, let's identify the "rules" of instancing, so maybe we can add some code to make this system a little smarter.

From Image's original post I just want to make sure SOE hasn't changed things, that these rules still apply.


NONE

• Rule: Anyone, anytime, up to max-players.

SOLO_LOCKOUT_INSTANCE, GROUP_LOCKOUT_INSTANCE, RAID_LOCKOUT_INSTANCE

• Rule: You enter the Lockout instance, if you leave you cannot come back? Or, when you FINISH you cannot do it again until {timer}?
• Also assuming Solo (1) Group (6) and Raid (12-24) are the same rule, just different group sizes.

SOLO_PERSIST_INSTANCE, GROUP_PERSIST_INSTANCE, RAID_PERSIST_INSTANCE

• Rule: You enter and do whatever you want, can leave, and come back any time - until {timer}?
• Also assuming Solo (1) Group (6) and Raid (12-24) are the same rule, just different group sizes.

TRADESKILL_INSTANCE

• Rule: Public instance with no spawn tracking (no combat - not even rats!)
• Anyone can enter, up to the max-player, zone closes down when last player exists after {timer}

PUBLIC_INSTANCE

• Rule: Public instances where dead spawns are tracked
• The only possible thing I can think of are zones like Frostfang max-players 100, the 101st player would spawn a new instance of Frostfang

PERSONAL_HOUSE_INSTANCE

• Rule: Owned by a player who can set access rights on their instance. Persistent even through shutdowns.
• Depending on Access, Visitors can come see my house.
• Take a Tour option shows empty, solo instance of the house (I don't think 2 players can Tour the same house?)

GUILD_HOUSE_INSTANCE

• Rule: Owned by a Guild. Persistent even through shutdowns. Always public?
• Take a Tour option shows empty, solo instance of the hall (I don't think 2 players can Tour the same hall?)

QUEST_INSTANCE

• Not Implemented Yet, but what are these rules?

Rules should also govern the timers and shutdown of Instances, but first we need to get into them before worrying about shutting them down or locking them out


Thanks in advance for your input.

[thefoof]

QUEST_INSTANCE

• Not Implemented Yet, but what are these rules?

No lockout, no respawns, generally they are either solo or group.

[Jabantiz]

SOLO_LOCKOUT_INSTANCE, GROUP_LOCKOUT_INSTANCE, RAID_LOCKOUT_INSTANCE

• Rule: You enter the Lockout instance, if you leave you cannot come back? Or, when you FINISH you cannot do it again until {timer}?
• Also assuming Solo (1) Group (6) and Raid (12-24) are the same rule, just different group sizes.

When you kill a named mob the lockout timer starts and you can't reenter, some even have a failure lockout timer that starts as soon as you zone in so you can't reenter. Don't think we need to track mobs in these as once the zone shuts down if you are locked out you can't reenter and if you aren't locked out the zone resets.

SOLO_PERSIST_INSTANCE, GROUP_PERSIST_INSTANCE, RAID_PERSIST_INSTANCE

• Rule: You enter and do whatever you want, can leave, and come back any time - until {timer}?
• Also assuming Solo (1) Group (6) and Raid (12-24) are the same rule, just different group sizes.

This is correct

TRADESKILL_INSTANCE

• Rule: Public instance with no spawn tracking (no combat - not even rats!)
• Anyone can enter, up to the max-player, zone closes down when last player exists after {timer}

Really nothing special just a new instance pops after a set limit.

PUBLIC_INSTANCE

• Rule: Public instances where dead spawns are tracked
• The only possible thing I can think of are zones like Frostfang max-players 100, the 101st player would spawn a new instance of Frostfang

Think it is identical to the tradeskill instance, just pops a new instance after a certain player limit is reached. Also I don't think spawns need to be tracked on these or the tradeskill instances.

PERSONAL_HOUSE_INSTANCE

• Rule: Owned by a player who can set access rights on their instance. Persistent even through shutdowns.
• Depending on Access, Visitors can come see my house.
• Take a Tour option shows empty, solo instance of the house (I don't think 2 players can Tour the same house?)

Not sure about the tour spawning a new instance for every one, thought it was just the base zone you went into but no clue, never ran into another player while touring a house so it is possible it is temp instances.

GUILD_HOUSE_INSTANCE

• Rule: Owned by a Guild. Persistent even through shutdowns. Always public?
• Take a Tour option shows empty, solo instance of the hall (I don't think 2 players can Tour the same hall?)

Same thing for tour here as the player house. Also a guild can make the hall private, not sure if it defaults to public or private though.

QUEST_INSTANCE

• Not Implemented Yet, but what are these rules?

This, in my head at least, would be identical to lockout instances just no lockout timers. The only real difference is these will not display on the instance window like lockout and prestige will.


After typing this all out it looks like we would only need to save spawns in the db for persistent instances, none of the others should need spawn info saved after the zone shuts down.

[John Adams]

Excellent, thanks guys. I built out the switch, but haven't committed it yet because it still does nothing lol but here it is if you wanted to add something.

Code: Select all

			switch(instanceType)
			{
				case SOLO_LOCKOUT_INSTANCE:
 					{
						break;
					}

				case SOLO_PERSIST_INSTANCE: 
					{
						break;
 					}

				case GROUP_LOCKOUT_INSTANCE:
					{
						break;
					}

				case GROUP_PERSIST_INSTANCE:
 					{
						break;
 					}

				case RAID_LOCKOUT_INSTANCE:
					{
						break;
					}

				case RAID_PERSIST_INSTANCE:
					{
						break;
					}

				// if its public/tradeskill, look for a public already setup
				// otherwise find one in the database and use its instance id
				case PUBLIC_INSTANCE:
					{
						break;
					}

				case TRADESKILL_INSTANCE:
					{
						break;
					}

				case PERSONAL_HOUSE_INSTANCE:
					{
						break;
					}

				case GUILD_HOUSE_INSTANCE:
					{
						break;
					}

				default:
					{
						// NONE
					}

			}

Dunno about you, but I hate typing stuff over and over

I tried my hand at moving some of this code around in this function, but discovered 1) I broke everything, and 2) even with it as-is, this code doesn't seem to get hit all the time. Ie., set zone 2 as instanced, camped while in it, then relogged in after a world start and it just tossed me into zone 2. I think. I'll try messing with it more this week, but maybe not til the weekend again.

[Jabantiz]

When a char logs in it will use the instance_id in the characters table, so if you set the instance type while the zone was running and a player was in it then it wouldn't stick as they are already in the zone and the instance id and type wasn't set up when the zone started.

In short the instance stuff needs to be set up before the zone starts.

[John Adams]

Jab, I will attempt to follow the code through a zone startup (but threading always gets in my way heh). What i need to figure out is what constitutes a `character_instances` entry vs not.

What threw me yesterday (and caused a ton of crashes) was that the `characters`.`instance_id` value got set, but I purged the `instances` table and I think World doesn't like that. Going to need some self-healing in cases like that I suppose.

I thought a `character_instance` would only be added when it was a solo, group, and maybe even raid? and again, maybe only persistent? I do not fully understand that code yet, so i'll toss it out there until I get a chance to dive back in.

Lastly, do you know if this is the ONLY place for calculating instance access? I think there was the other spot I showed that the if/else was empty. I think that was on the removal success, which as you know currently doesn't work.

[Jabantiz]

Jab, I will attempt to follow the code through a zone startup (but threading always gets in my way heh). What i need to figure out is what constitutes a `character_instances` entry vs not.

An entry should be put into character_instances for every lockout or persistant instance they enter, this table would be used to populate the instance window in game (alt + z)

What threw me yesterday (and caused a ton of crashes) was that the `characters`.`instance_id` value got set, but I purged the `instances` table and I think World doesn't like that. Going to need some self-healing in cases like that I suppose.

`characters`.`instance_id` should probably only be set on persistant instances, when the player logs in it will try to enter a zone with that instance, it gets what zone that is by looking up the id in the `instances` table. It might be best to move the char to the entrance of the instance in the parent zone upon logging out if the instance is not persistant.

I thought a `character_instance` would only be added when it was a solo, group, and maybe even raid? and again, maybe only persistent? I do not fully understand that code yet, so i'll toss it out there until I get a chance to dive back in.

It should be added for all versions of persistent and lockout I believe

Lastly, do you know if this is the ONLY place for calculating instance access? I think there was the other spot I showed that the if/else was empty. I think that was on the removal success, which as you know currently doesn't work.

Honestly, I am not sure. I will have to follow the code again to see.

[John Adams]

Cool, thanks for the continued details. One more thought...

Since the switch(instance_type) just falls through, I assume the part about adding character.instances is moot for now, since it seems the code is a little out of order now, testing group stuff way up top and character stuff at the bottom... it was this stuff I moved around into the switch() trying to get it to work, and ended up blowing up all over the place.

Regarding the `characters`.`instance_id`, I think I get ya. If i CAMP inside an instanced zone, this value should get the instance_id. So when I come back, it knows to repop that instance_id and read the removed spawns. I agree if it is a locked_out scenario, we probably need to pop them outside. Maybe we need an additional value in the instances table to show who that parent is? In cases of zone doors, that's easy. But what about clickies or other means to get in -- we may not know where they came from (unless there is ALWAYS an adjoining zone?)

[Jabantiz]

Regarding the `characters`.`instance_id`, I think I get ya. If i CAMP inside an instanced zone, this value should get the instance_id. So when I come back, it knows to repop that instance_id and read the removed spawns. I agree if it is a locked_out scenario, we probably need to pop them outside. Maybe we need an additional value in the instances table to show who that parent is? In cases of zone doors, that's easy. But what about clickies or other means to get in -- we may not know where they came from (unless there is ALWAYS an adjoining zone?)

We could add some more values to player to hold x, y, z, heading and zone_id of the parent zone, just set it when the player zones into an instance. I have not thought about this issue until my last post and that is just the first idea that popped into my head, there may be a better way to do it.

[Jabantiz]

Added min level, max level, quest completed, and quest and step requirements to the transporter code. This will allow for the destination to only show up if they meet the requirements. I am posting in the instance thread as I had the instance cave of illboding in frost fang sea in mind for this.

There is an issue that instances are not loaded through this code, I am looking into that now.

Here is sample sql demonstrating how to set up the transport list for the cave, I used quest 1 step 1for the first version and quest 2 step 1 for the second

Code: Select all

INSERT INTO `transporters` (`id`, `transport_id`, `transport_type`, `display_name`, `destination_zone_id`, `destination_x`, `destination_y`, `destination_z`, `destination_heading`, `trigger_location_zone_id`, `trigger_location_x`, `trigger_location_y`, `trigger_location_z`, `trigger_radius`, `cost`, `message`, `min_level`, `max_level`, `quest_req`, `quest_step_req`, `quest_completed`) VALUES (1, 1, 'Zone', 'Cave of Illboding Dark', 516, 738.774, 41.9821, 133.181, 0, 470, -1, -1, -1, -1, 0, NULL, 0, 0, 1, 1, 0);
INSERT INTO `transporters` (`id`, `transport_id`, `transport_type`, `display_name`, `destination_zone_id`, `destination_x`, `destination_y`, `destination_z`, `destination_heading`, `trigger_location_zone_id`, `trigger_location_x`, `trigger_location_y`, `trigger_location_z`, `trigger_radius`, `cost`, `message`, `min_level`, `max_level`, `quest_req`, `quest_step_req`, `quest_completed`) VALUES (4, 1, 'Zone', 'Cave of Illboding Dark: The Source', 517, 738.774, 41.9821, 133.181, 0, 470, -1, -1, -1, -1, 0, NULL, 0, 0, 2, 1, 0);

You would then assign transport id 1 to the spawn in the `spawns` table.

[thefoof]

Added min level, max level, quest completed, and quest and step requirements to the transporter code. This will allow for the destination to only show up if they meet the requirements. I am posting in the instance thread as I had the instance cave of illboding in frost fang sea in mind for this.

Woot nice.

[Jabantiz]

There is an issue that instances are not loaded through this code, I am looking into that now.

Fixed this and now all transporters have the capability to load the player into an instance. Also fixed a display issue with the window when you have multiple destinations and at least one is not displayed.

[Zcoretri]

Very nice Jabantiz

[Jabantiz]

After going through and trying to figure out the packet for WS_InstanceCreated, which displays lockout and persistent instance data, I have come to the conclusion that the table `character_instances` is going to need to be reworked as well the code to support it. As it is now there are multiple loops that will need to call the database to get the zone name and the instance type, I would like to eliminate the need to call the database so many time just to create a packet.

There is also data missing needed to make the packet complete. The updated struct for WS_InstanceCreated is on dev svn