EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)

- Development::Development (https://www.eqemulator.org/forums/forumdisplay.php?f=590)

- - Raids (https://www.eqemulator.org/forums/showthread.php?t=25959)

Some people expressed interest in raids so I thought I'd throw a little progress report out. Currently nothing works and it's still in a figure out how the packets and structures interact kinda stage. But it's getting close to the point where raids could be implemented.

Not quite sure how I want to implement them yet though. I've been going back and forth between keeping existing groups intact and tracked by the raid or having raid overwrite them completely and track members itself.

I've got most the structures involved figured out... some still confuse me... like the bulk member list... no idea what's going on there. The packets in action:

http://i8.photobucket.com/albums/a2/...e/EQ000002.jpg

http://i8.photobucket.com/albums/a2/...e/EQ000003.jpg

Right now just using packets I know how to:
-Invite -> accept invite
-Create the raid
-Disband the raid
-Remove specific members
-Add a grouped member
-Add an ungrouped member
-Toggle the group leader and raid leader flags
-Change the loot type(sorta)
-Lock/Unlock the raid
-Change the group of an existing member
-Send a stringID message in both white and red to the client.

Things I don't know yet:
-Changing leader(think I have an idea of how to do this but haven't taken the time to nail it down)
-Bulk raid send (we can probably do without it but it will get annoying zoning into a new zone and getting 20+ Soandso has joined the raid. messages)
-Changing a person's name (Don't see the purpose of this but it's there...)
-Raid Leadership stuff(not that it's implemented anyway...)
-Raid notes
-Raid MOTD

Here's where I left off last time I was thinking about potential ways to track them.

Code:

CREATE TABLE `raid_ungrouped_members` (

  `raidid` int(4) NOT NULL,

  `charid` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  `ismaintank` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `charid`)

)



CREATE TABLE `raid_groups` (

  `raidid` int(4) NOT NULL,

  `groupid` int(4) NOT NULL,

  `groupindex` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `groupid`)

)



CREATE TABLE `raid_leader` (

  `raidid` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  PRIMARY KEY (`raidid`)

)

The more I think about it though the more I'm leaning toward raids completely negating groups for their own structure simply because having to cross reference the groups in the DB while tracking them would add quite a bit of complexity.

My experience with raids is somewhat limited so anyone who wants to point out some of how the groups interact together it would be helpful.

Looks like great work so far.

Quote:

CREATE TABLE `raid_groups` (
`raidid` int(4) NOT NULL,
`groupid` int(4) NOT NULL,
`groupindex` tinyint(1) NOT NULL,
PRIMARY KEY (`raidid`, `groupid`)
)

CREATE TABLE `raid_leader` (
`raidid` int(4) NOT NULL,
`name` varchar(64) NOT NULL,
PRIMARY KEY (`raidid`)
)

Why the extra table? easyer to just do

CREATE TABLE `raid_groups` (
`raidid` int(4) NOT NULL,
`groupid` int(4) NOT NULL,
`groupindex` tinyint(1) NOT NULL,
`israidleader`int(1) NOT NULL,
PRIMARY KEY (`raidid`, `groupid`)
)

then you dont have to go grabbing from another table. and just check raidID and if raidleader is 1 then they are leader 0 normal.

less..is more =)

Quote:

Originally Posted by KLS (Post 154397)

Here's where I left off last time I was thinking about potential ways to track them.

Code:

CREATE TABLE `raid_ungrouped_members` (

  `raidid` int(4) NOT NULL,

  `charid` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  `ismaintank` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `charid`)

)



CREATE TABLE `raid_groups` (

  `raidid` int(4) NOT NULL,

  `groupid` int(4) NOT NULL,

  `groupindex` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `groupid`)

)



CREATE TABLE `raid_leader` (

  `raidid` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  PRIMARY KEY (`raidid`)

)

I am not very familiar with how the raids work either but from looking at your tables here could you just do something like this:

Code:

CREATE TABLE `raid_members` (

  `raidid` int(4) NOT NULL,

  `charid` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  `ismaintank` tinyint(1) NOT NULL,

  `isgrouped` tinyint(1) NOT NULL,

  `isleader` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `charid`)

)



CREATE TABLE `raid_groups` (

  `raidid` int(4) NOT NULL,

  `groupid` int(4) NOT NULL,

  `groupindex` tinyint(1) NOT NULL,

  PRIMARY KEY (`raidid`, `groupid`)

)

Using one table for all of your raid members (same table as your ungrouped_members tables) and add a isgrouped flag and a isleader flag.

One of the issues that I seen with devnoob's suggestion of adding the raid leader flag to the raid_groups table was that the charid is not referenced in that table and therefore does not point the leader to a specific character but only to a group.

Just a suggestion from that I seen only by looking at what you have posted so if this is completely off base I am sorry for that.

whoops yep...forgot to put that in there :p good catch...teach me to try and think before the 1st cup of coffee..

Code:

CREATE TABLE `raid_members` (

  `raidid` int(4) NOT NULL,

  `charid` int(4) NOT NULL,

  `groupid` int(4) NOT NULL,

  `_class` int(4) NOT NULL,

  `level` int(4) NOT NULL,

  `name` varchar(64) NOT NULL,

  `isgroupleader` tinyint(1) NOT NULL,

  `israidleader` tinyint(1) NOT NULL,

  `islooter` tinyint(1) NOT NULL,  

  PRIMARY KEY (`raidid`, `charid`)

)

ENGINE = InnoDB;



CREATE TABLE `raid_details` (

  `raidid` int(4) NOT NULL,

  `loottype` int(4) NOT NULL,

  `locked` tinyint(1) NOT NULL,    

  PRIMARY KEY (`raidid`)

)

ENGINE = InnoDB;

Is what I actually ended up going with.
Got basic creation and inviting ungrouped characters working, so much more to do.

KLS.

Names should not be able to be changed, just don't implement it.

The notes tab is just a minimalist way of showing the first tab. Don't worry too much about it.

Raids should completely overwrite the group function. The groups still function as groups should (buffs stay within groups unless target group buff is turned on). And leaving the group would make you go into the un-grouped portion of the raid.

Oh, and another note, if you didn't know about the looter thing.

Default for raids is: no one but the raid leader can loot anything off corpses until they open up publicly.
Adding a looter just gives the the person the ability to loot at the same time as the leader.

Additionally, things will have to be set so that if the raid leader logs without changing the raid leader flag, the raid leader goes LD, or gets booted while zoning, the raid leader status will default to whomever becomes the group leader of the raid leader's group.

Right now if the leader/group leader leaves the raid for any reason it just gets lost but that will change before release. Right now you don't get kicked from the raid for logging out but I'm not sure if that will stay.

Groups inside the raid mostly work, but there's still several kinks to work out.

Got rsay and gsay working inside raids as well as moving and inviting and disbanding seems to work correct for the most part. Need to do a lot of polishing with some of the packets; some people not getting group leader updates and it's a bit spammy for others but I think that might even wait till after the system gets released as it's cosmetic really.

Figured out notes and motd as well as raid/group leader changes.

Gonna start working on actually getting the system to interact with the world now.

Not sure if this helps, but I was a raid leader on live for a while and one thing I remember about the raid tool is it was always buggy in regards to the "make group leader" function, infact I don't think it ever actually worked correctly. I always had to manually tell groups change the leader themselves.

It's certainly possible to get it working correctly as I did it when I was creating the raids by hand. There's just a lot of situations where it needs to change and I don't have them all covered yet... not even close to having them all covered.

As kayen said, the raid function to change a group leader wouldn't be a big deal immediately so long as /makeleader is working. I haven't gotten to toy around with your new group code yet, so unsure if you'd already nailed it down.

Sounds like you're making fantastic progress, especially since we were always told this wasn't even possible. Keep it up!

Raids work now for most basic purposes.

Exp, rsay, gsay, loot, group spells, bard pulses, money splits, merit kills. Missing quest interface and tons of polish.

Oooooh KLS! I have been trying to hold back from posting a drooling post here about your work on this, but I can't hold back any longer! This is going to be so awesome! I will have a few encounters to adjust but I can't wait to set them for raid merit instead of hailing flags :D It will be really nice to not just let anyone come in and get the flags after the boss dies.

I do think it would be nice if there was a way to have group merit and raid merit separate though. Not a huge deal, but I just made a zone that runs on a completely new credits system (using quest globals) and it is designed for single groups only. If an entire raid can use the system it might cause me to have to come up with a new way to do it. Not a huge deal, and raids would definitely be worth the minor issue I would have in this one zone, but I do think it would be nice to be able to chose if merit goes to just the group or to the whole raid. Something to consider, anyway.