Thread: Raids
View Single Post
  #1  
Old 08-16-2008, 11:19 PM
KLS
Administrator
 
Join Date: Sep 2006
Posts: 1,348
Default Raids

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:





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.
Reply With Quote