Real Instancing

[KLS]

I know we have 'instancing' but I'm looking to expand it and not do it in such a hackish way. It's probably going to be a lot of work so I decided to branch it on svn.

Right now I'm just brain storming tables that would be needed (I know it's not in sql but anyone should be able to follow it).


Every time a new instance version was made this would be added to the table with a unique id. For example your raid group accepts their quest to go kill big bad boss and a new raid lockout entry is added to this table with a random unused id the time it was accepted and the duration and the zone and version of zone to use are also stored.
instance_lockout:
id
start_time
duration
zone
version

This table would keep track of players who are assigned to certain instance lockouts.
instance_lockout_player:
id
charid

Respawn timers would be expanded to include instance lockout_id to handle respawning npcs in the dungeons
respawn_timer:
id
start
duration
instance_lockout_id

Spawn2 is pretty crowded as is so I'm thinking to split it off to it's own instance specific table. Basically the same as the current table but there's a version field so creators can create different versions of zones. The two sub tables don't really have anything instance specific but it would be really odd to have cross refs from different tables like that.
spawn2_instance:
id
spawngroupID
zone
version
x
y
z
heading
respawntime
variance
pathgrid
_condition
cond_value

spawngroup_instance:
id
name
spawn_limit

spawnentry_instance:
spawngroup_id
npcID
chance

Also would eventually need to think up solutions for objects, zone points, ground drops, etc etc. If anyone has any ideas or criticism I invite it, still at the very early stages.

[Secrets]

I like the idea of having spawngroups for their own instances, however, the point of instances in EQ at least is to scale NPCs based on their existing info versus the players going into the instance, at least what I think this is for in LDON.

It would be MUCH better to add a field in npc_types that can be enabled to scale that NPC to level of the clients entering the zone when the NPC is loaded from spawn2, rather than having a bunch of multiples of the same NPC for the same zone. This way, we don't have to populate each instance by hand and place them, and do a lot of unnessesary copy & paste. For the instances where we don't need level scaling, the flag can be turned off, but the zone can be flagged as an instance as well. If the zone is *not* flagged as an instance, and the field in npc_types is turned on, they will still scale and this will add another feature for server OPs to use. This eliminates the need for any kind of un-needed tables.

The problem would be basing it off of the client. I suggest using the first client that goes into the instance, just like SOE does.

Lemme know what you think, and if it would be feasable, especially the client part.

[trevius]

NPC level scaling actually wouldn't be too hard to handle with Scripts using the modifynpcstat command that KLS put in a while back. Real instancing would be cool for special events and such. Though, I think their main potential would be for LDoN zones.

[KLS]

Well a lot of raid and adventure dungeons past LDoN are instanced as well. It's a piece of missing functionality that if we don't get we we honestly start hitting a wall with on PEQ soon because PoP was the last real non-instanced expansion(minus potb of course).

I've got a very basic functionality working right now in that the world server is able to track servers by both zone and instance id, it had it's share of annoyances but it was easier than I thought it'd be... still a lot more than that though.

[Andrew80k]

I love the idea for real instancing. I spent a lot of time in both the DoN instances and the DoDH instances on live. It was nice to have scaled content. It would be nice to be able to scale both mobs and loot inside these instances.

[KLS]

I've got creation of basic instancing and loading into an instance working. A lot of the lockout stuff is pretty preliminary atm and I'll try to get that entire system sorted out after I work zoning into instances out next.

It's still a mountain of work ahead but it's actually going a lot more smoothly than I thought it would.

[Rocker8956]

Originally Posted by KLS

I know we have 'instancing' but I'm looking to expand it and not do it in such a hackish way. It's probably going to be a lot of work so I decided to branch it on svn.

Hmm, hackish is a compliment for the way I put some of that code together. If you need help reading any of my crappy code please let me know. Been a bit since I looked at it but I may be able to remeber some of it.

[KLS]

I took it all out pretty much and replaced it cause I wanted a system that was easier to track and that I could easily assign lockout ids to.

I got zoning to work pretty flawlessly yesterday along with respawn timers. Raids and Groups work across instance boundaries now; they only partially worked before. Still working on the verification of various instance actions and the expiration. Hopefully soon I can start to think about the actual implementation of the various systems that go on top of this.

[KLS]

As of my commit tonight I will have what I basically consider the minimum for instancing done, just have to write up some quest commands.

Or tomorrow afternoon rather I'm way too tired to finish tonight.

[KLS]

You can view my table changes on the branch now. There's a lot of them, but most of them are just adding or dropping a field here and there.

CREATE TABLE `instance_lockout` (
  `id` int(11) NOT NULL auto_increment,
  `zone` int(11) unsigned NOT NULL default '0',
  `version` tinyint(4) unsigned NOT NULL default '0',
  `start_time` int(11) unsigned NOT NULL default '0',
  `duration` int(11) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`),
  UNIQUE KEY `id` (`id`),
  KEY `id_2` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `instance_lockout_player` (
  `id` int(11) unsigned NOT NULL default '0',
  `charid` int(11) unsigned NOT NULL default '0',
  PRIMARY KEY  (`charid`,`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Are the two entirely instance related ones, but they're anything but final. Right now it's a very workable system but far from done. If anyone feels like checking it out though it's what I'd say is "beta" quality.

[drakelord]

So, just out of curiosity, are you going to change the current perl commands for instance flags and such to be compatible with this, or are they already so?

[provocating]

Just want to thank KimmySprite for working on this. I have been following your changes on SVN and you are making incredible progress on this in short amount of time. I am afraid I can only been a cheerleader since you code 100 lines to my one line, and my one line still will not work, well not that bad but you get the idea. Anyway I just wanted to drop in and say thanks and keep up the outstanding work.

By the way do you guys sleep at all ? That is a hell of a lot of coding.

[KLS]

Despite cavedude's claims: yes I sleep. It's not as much code when you consider I'm doing this in bits and pieces. I'm working on adventures now but I got a little ahead of myself on design by not planning ahead enough and had to backtrack a bit.

[provocating]

Aren't we all guilty of that though.

[provocating]

I was curious on something. I see you are daily working on the LDoN instances as far as the C++ code getting the game mechanics going. My question is are we going to be able to have a match with the live instances without the packet analyzer going or are we going to try to go from pure memory ? It has been a really long time since I have been on live.