Real Instancing
 

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

Aren't we all guilty of that though.

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.

I am building the LDoN zones using ShowEQ logs as KLS is adding the code support. If all goes well, I hope to have mmc ready to go around the time the adventure code is ready to be fully tested out.

I have not used ShowEq in forever, so I have an ignorant question.

When you say "using showeq logs", these are log captures from years ago or recently? I know the time does not really matters as I doubt things have changed. I am more asking is there an archive somewhere of ShowEq logs of zones ? I really need to setup ShowEq, I have not used it in years.

They are brand new logs from within the past month. Our log repo is here: http://www.projecteq.net/logs/ (must be logged into the PEQ forums first) All but the new LDoN logs are in EQExtractor/EQBuilder format, and can be built using those tools. I'll be adding the SEQ LDoN logs shortly. Also, KLS wrote at my request a basic parser for SEQ logs that creates the spawn table data, and inserts the npcid of any existing NPC found with the same name as the one in the log into spawnentry. It can't create the NPC because ShowEQ logs don't provide enough information like EQBuilder logs do. I'll post that somewhere soon as well.

I think I am currently around r589 from SVN.

I was going to try out instancing tonight. I tried the commands to create an instance, add myself to the instance, then list to make sure I was in the instance. All of that worked. Now from that point am I supposed to zone myself as GM into the instance or zone out to the normal LDoN zone point ?

I also clicked the adventure recruiter and surprisingly some of that worked. I guess BOTS do not count as a real group though, said something about me not being the leader of my group.

Meh, not a big deal though I was just going to give feedback, I know without feedback it makes it difficult. At this point though, you are probably working so fast and hard on this that you may not be at the point to even want feedback.

Great Job!
 

Is there a place where I can download the updates you have been making for the instances? do i use MySQL or is it SVN? some of my zones like Tacvi the monsters are there they have no loot on them anyone know where I can download the updates i need to get my server working? How can I learn to do what everyone here does?

I love everyones work I wish I could help.

The instance branch of SVN is here.

http://code.google.com/p/projecteqem...nches/instance

I curious if the requirement to be in a group to request an adventure is a limitation of the client or if that is something that is determined server-side. If it is serverside, it might be nice to add a setting for min group size to one of the tables. It would be cool to be able to make solo adventures an option for custom servers. Mainly though, I would like the option so I could test out making adventures without having to log in half a group :P If the min group size setting is server-side, we could probably just add an Admin check and allow anyone with admin status to request adventures with a single character.

I have a feeling that this requirement is probably being set client-side, but if not, it would definitely be a big bonus to allow the option to try them out with a single character.

The group requirement is client side. However, once you have a group of 2, you can configure the min and max required group/raid members in rule_values. So, if you want adventures to be full groups only, you can.

I have another quick question for you, will the client see a group of one human player and 4 bots as a group? or will it just be seen as 1 human player?

You have to actually have people in your group or raid windows to be counted as "in a group" for the client.

I realize we're not using the SoD client, but Sony allows mercs to count towards requesting an instance/task on Live now. Too bad for client limitations :(

I Agree wish the bots could count as group members.
This almost seems to be a has to fix for players.

At Least a option to not have to have a group /raid unless custom server demands it.

This isn't something I can change. The bot code would have to change to show up in group/raid windows properly.

I was able to accept a Mistmoore Adventure with Me and 5 bots today after a few code tweaks. I'm not finished with all the testing and code tweaks needed, but I am working on it.

See he's on it!

There's really no limitation on adventuring once you are accepted into the adventure. The client just dislikes letting ungrouped/unraided people in.

Yeah having OFFICIAL Mercs supported by client would be nice, but unfortunately they were only added with SoD which is even beyond our newest retail package we moving towards to. (SoF)

See you guys, I told you he was on it !

Go, go, go !

I don't know how complicated it would be, but since some things like Adventures and Group Leadership AAs require the client to think it has real group members, I am wondering how hard it would be to code something in to handle that without having bots enabled. Basically, I wouldn't want players to be able to use them, but for testing purposes it would be nice to be able to just run a command that will spawn a group of NPCs. They wouldn't need any AI or special code for them other than that they can join your group. Like an extremely trimmed down bot just for code testing group related code only.

You could enable bots but then limit the bot commands to 250 status.

from what I remember LDOn requres at least 3 people in group to get an adventure. AFTER you got a mission you can disband the other 2 and enter on your own - I seen this done on LIVE back in the day. This is posible cuase othewise if a player on LDON mission dies and gets disconected he needs some way to get back in- hence entering ldon while NOT in the group is OK as long as you stil have adventure assigned to you

So simplest solution for you Trev would simply log in 2 boxes, group with them get adventure and then go check it ut wihout actualy having to drag the boxes along.

What about making a bot client? Something that would connect as another account and just run in the background on your computer. Take commands via monitoring /tells. We already know exactly how the client interacts with the server and vice versa so it should be easy to make a client 'simulator'.

It would also shift the burden of AI processing from the server to the client.

So in the long run though, the end result would be to allow the bots into LDoN or not ?

See MQ2 + good macros

If bot commands can be set to GM status only, what reason is there to not have bots enabled by default? I had always assumed there were separate builds/options for a reason. If there isn't any other reason, then wouldn't there just be 1 build and it would include bots, but just give the option to have the bot commands set to high for anyone to use? This is why I haven't enabled bots, because I think there has to be something other than just the commands that come into play when bots are enabled.

It really don't make sense to not have bots count as a group. I mean you set it up to add bot to group. So why can't they count?

Or least be able to enter the instance with just yourself. then you can add or spawn bots.

Either way it's still forcing people to group. One thing i hated about EQlive before i quit.

Freedom to solo was run short after awhile.