Implementing: Instancing
Moderator: Team Members
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
You can change the table if you want, would probably make things easier. However I would wait a bit until we are sure the enum in the code is right, I had already added a value to it thanks to alfa poining out the raid_lockout and now I got 2 more to add (house and guild hall) that you noticed are missing.
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
I had to fix this table as (the fk_constraint) and code as it wan't all pointing to the same thing, right now it all point to spawn_location_id in the spawn_location_entry (wich now that i look in the db spawn_location_id has a fk to id in spawn_location_name so I probably set up the fk wrong) so right now it is by location of the spawn and not the spawn id.John Adams wrote:There is only one problem I see immediately with the instance_spawn_remove table; it is based on spawn_id, not spawn_location_placement.id. Meaning, if I zone into an instance that has 10 "a rat" spawns with an id of 1000, and I kill 1 rat, spawn_id 1000 gets put into the table and none of the other 9 placements will ever spawn should I reload the instance, for whatever reason.
Correct?
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
Ok, we'll rename the field then to be more accurate (spawn_location_id) when we do the ENUM stuff. Whenever you are ready.
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
This is the current instance_type enum I have, does any one know of a missing instance type?
Code: Select all
enum Instance_Type {
NONE,
GROUP_LOCKOUT_INSTANCE,
GROUP_PERSIST_INSTANCE,
RAID_LOCKOUT_INSTANCE,
RAID_PERSIST_INSTANCE,
SOLO_LOCKOUT_INSTANCE,
SOLO_PERSIST_INSTANCE,
TRADESKILL_INSTANCE, // allows anyone to enter, server searches for the first instance that is available
PUBLIC_INSTANCE, // same as tradeskill, except dead spawns are tracked
PERSONAL_HOUSE_INSTANCE,
GUILD_HOUSE_INSTANCE
};- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
/bump
I have committed this change to the Zones table. The enums are indexed in the order seen in Jab's latest post, so if the switch needs to be fixed, it can be done any time.
I needed to get this done in order to (attempt) to spawn a 2nd instance of our starter zones based on client version, because Darklight terrain will not work for Pre-SF, DoV+, and CoE clients as 1 single zone
I have committed this change to the Zones table. The enums are indexed in the order seen in Jab's latest post, so if the switch needs to be fixed, it can be done any time.
I needed to get this done in order to (attempt) to spawn a 2nd instance of our starter zones based on client version, because Darklight terrain will not work for Pre-SF, DoV+, and CoE clients as 1 single zone
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
Just some info on the code that I learned while working with housing, mainly for future reference for me but others might find this info useful.
zone_list.GetByInstanceID(int32, int32);
This function is what you want to call when you need a pointer to the ZoneServer.
The first parameter is instance ID, if set above 0 it will go through the list of active zones and look for one with a matching instance ID, if found it will return a pointer to that zone.
The second parameter is the zone ID, in the event that instance ID = 0 or the instance isn't active it will startup a new ZoneServer for the given zone ID. If instance ID is 0 then it will create a new instance ID (assuming the zone has an instance type set in the db). If instance ID is set then it will assign that ID to the new zone and load up any instance info.
Examples:
bool Client::TryZoneInstance(int32 zoneID, bool zone_coords_valid)
This function will try and zone the client into an instance of the given zone, if the player is in a group and a group member is in an instance of this zone already it will zone the player into that instance. If the player already has this instance saved it will load up that saved instance and zone the player into it. If neither of those it will create a new instance and save it for the player and zone the player into the new instance. The second parameter is if we need to change the players position to that zones safe cords, if set to false make sure to set the new x,y,z values before calling this function.
Examples:
(This function makes use of zone_list.GetByInstanceID() )
zone_list.GetByInstanceID(int32, int32);
This function is what you want to call when you need a pointer to the ZoneServer.
Code: Select all
ZoneServer* instance_zone = zone_list.GetByInstanceID(instance_id, zone_id);The second parameter is the zone ID, in the event that instance ID = 0 or the instance isn't active it will startup a new ZoneServer for the given zone ID. If instance ID is 0 then it will create a new instance ID (assuming the zone has an instance type set in the db). If instance ID is set then it will assign that ID to the new zone and load up any instance info.
Examples:
Code: Select all
// Attempt to get an active zone that has an instance id of 5
// You will have to check to see if instance_zone is valid before using it
ZoneServer* instance_zone = zone_list.GetByInstanceID(5,0);
if (instance_zone) {
// Valid pointer, means the instance was already up and running
}
Code: Select all
// This will look for an active instance, if none are found it will start up the instance using 253 (Queen's Colony) as the base
ZoneServer* instance_zone = zone_list.GetByInstanceID(5,253);
Code: Select all
// This creates a new instance of 253 (Queen's Colony, assuming it is set up as an instance in the DB)
ZoneServer* instance_zone = zone_list.GetByInstanceID(0,253);
// If you need the instance ID for whatever reason it is stored in the ZoneServer
int32 instance_id = instance_zone->GetInstanceID();
bool Client::TryZoneInstance(int32 zoneID, bool zone_coords_valid)
This function will try and zone the client into an instance of the given zone, if the player is in a group and a group member is in an instance of this zone already it will zone the player into that instance. If the player already has this instance saved it will load up that saved instance and zone the player into it. If neither of those it will create a new instance and save it for the player and zone the player into the new instance. The second parameter is if we need to change the players position to that zones safe cords, if set to false make sure to set the new x,y,z values before calling this function.
Examples:
Code: Select all
// This will zone the player into an instance of 253 (Queen's Colony) at the zones safe coord's
client->TryZoneInstance(253, true);
Code: Select all
// This will zone the player into the instance at a location of 5, 5, 5, you could also set the heading if you want
client->GetPlayer()->SetX(5.0f);
client->GetPlayer()->SetY(5.0f);
client->GetPlayer()->SetZ(5.0f);
client->TryZoneInstance(253, false);
- thefoof
- Retired
- Posts: 630
- Joined: Wed Nov 07, 2012 7:36 pm
- Location: Florida
Re: Implementing: Instancing
Question: what type of instance would be appropriate for a quest zone? I was thinking personal_house would work but not sure all the details of instances, basically when the player zones out the instance should be deleted at that point.
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
Wouldn't Solo Persist work? Not that it actually "works" now but I think that's the purpose.
If there isn't already a shutdown/delete timer for instances, maybe we can add that to ensure it gets destroyed after exiting.
If there isn't already a shutdown/delete timer for instances, maybe we can add that to ensure it gets destroyed after exiting.
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
The code currently doesn't delete instances from the db.
As for what type to use I would vote solo_lockout as the killed spawns shouldn't be recorded, however not sure that would fit either. The instance in frostfang, the one I assume you are referring to, does not show up in the instance list and a lockout and persist type will show up in that window. A new generic type may need to be created for instance like this. Also still need to figure out a way to have the "door" to the instance point to multiple instances.
As for what type to use I would vote solo_lockout as the killed spawns shouldn't be recorded, however not sure that would fit either. The instance in frostfang, the one I assume you are referring to, does not show up in the instance list and a lockout and persist type will show up in that window. A new generic type may need to be created for instance like this. Also still need to figure out a way to have the "door" to the instance point to multiple instances.
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
FYI, I have refactored most (if not all) of the Instance-related WorldDatabase functions to use DatabaseNew, and in doing so found a couple bugs, one being a bad WHERE clause. Hopefully that will fix the removal bug.
Also, I will be committing a change to the `instance_spawn_removed` table we discussed earlier in this thread. That task is now done woot.
Running some instancing tests before I commit these large changes, so beware if you are working in WorldDatabase.cpp this weekend.
Edit: And Jab, this code simply means there is no actual difference between what instance type is set, correct? any will do?
since it just falls through this switch unaffected?
Also, I will be committing a change to the `instance_spawn_removed` table we discussed earlier in this thread. That task is now done woot.
Running some instancing tests before I commit these large changes, so beware if you are working in WorldDatabase.cpp this weekend.
Edit: And Jab, this code simply means there is no actual difference between what instance type is set, correct? any will do?
Code: Select all
switch(instanceType)
{
// if its public/tradeskill, look for a public already setup
// otherwise find one in the database and use its instance id
case PUBLIC_INSTANCE:
case TRADESKILL_INSTANCE:
{
break;
}
}-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
That is correct, most instance types aren't any different from each other. That switch is to find those public instance that are already started up so we can dump the player into one of those, at least that is what I assume it was meant to do.
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
I'll assume because there is no code in the switch, that it does nothing at all 
I'm walking through instances now, just so I have a better understanding. I logged out one of the players assuming his instance would be deleted - it was not. After looking into why, I believe it is because the only call to DeleteInstance() is inside DeleteCharacterFromInstance() - and the only time that is called is if the lockout_timer > 0 over in ProcessInstanceTimers().
In fact, respawned 'removed' spawns are never respawned either far as I can tell. Or maybe this is intended to do something different?
So from what I can tell, nothing ever gets cleaned out of these tables yet. At least now I know why.
I'm walking through instances now, just so I have a better understanding. I logged out one of the players assuming his instance would be deleted - it was not. After looking into why, I believe it is because the only call to DeleteInstance() is inside DeleteCharacterFromInstance() - and the only time that is called is if the lockout_timer > 0 over in ProcessInstanceTimers().
In fact, respawned 'removed' spawns are never respawned either far as I can tell. Or maybe this is intended to do something different?
Code: Select all
if ( database.DeleteInstanceSpawnRemoved(GetInstanceID(),tmp_respawn_list[i]) )
{
}
else
{
}So from what I can tell, nothing ever gets cleaned out of these tables yet. At least now I know why.
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
In my continued quest to just see Instancing working (more than just 1 player per zone), I made 2 toons, grouped them together, set Splitpaw as an instance, set some values in the zone instance fields for reenter, lockout, etc. And even set the `force_group_to_zone`, but alas that value (while loaded into zone->) does nothing yet.
I then zoned one guy into Splitpaw, and when I /zone my other guy, he created a 2nd instance.
Is this because I need to use /zone instance {id} when doing things manually? That would make sense.
But reading your post about using teleports to show me a list of instancing, I'm not comprehending how that will work for demo purposes.Yet.
edit: btw, the reason I am babbling so much about Instancing today is that I really wanted to test all the features that I feel my code changes affected, but... I cannot. So, committing with a prayer. Let me know if anything is broken
DING! I got it. Using clicky doorways or whatever, my group mates follow me into my instance. So I guess I broke nothing.
I then zoned one guy into Splitpaw, and when I /zone my other guy, he created a 2nd instance.
Is this because I need to use /zone instance {id} when doing things manually? That would make sense.
edit: btw, the reason I am babbling so much about Instancing today is that I really wanted to test all the features that I feel my code changes affected, but... I cannot. So, committing with a prayer. Let me know if anything is broken
DING! I got it. Using clicky doorways or whatever, my group mates follow me into my instance. So I guess I broke nothing.
-
Jabantiz
- Lead Developer
- Posts: 2912
- Joined: Wed Jul 25, 2007 2:52 pm
- Location: California
Re: Implementing: Instancing
Just using /zone id will zone you to the base zone that the instances are created from you need to use the /zone instance id to zone into an instance.
- John Adams
- Retired
- Posts: 9684
- Joined: Thu Jul 26, 2007 6:27 am
- EQ2Emu Server: EQ2Emulator Test Center
- Characters: John
- Location: Arizona
- Contact:
Re: Implementing: Instancing
Hmm, you would think then that if both toons just did /zone 2, they would both end up in the base zone 2 together. No? Cuz that's not what's happening... though the /zone instance 1 (instance_id 1 of zone_id 2) did work, as did the spawn_sign (mariner bell) approach.Jabantiz wrote:Just using /zone id will zone you to the base zone that the instances are created from you need to use the /zone instance id to zone into an instance.
Who is online
Users browsing this forum: No registered users and 1 guest