Group/raid test cases

R

Rymy

Developer
Staff member
Yes they are fubared. What I'm looking for is specific, repeatable test cases of things that are broken. I know I have witnessed many of these issues but I'm just trying to get the broken/repeatable cases documented so when I do really try to fix them, I have clear cases I can test.

Here's an example of a minor issue (you don't have to be this specific, but for repeating them it's nice. Also if the same thing can be reproduced with 4 people in raid rather than 18 that's good to document because it's a lot easier for me to load 4 test clients than 18...)
1) Person A invites B to a group (they accept).
2) Person C invites D to a group (they accept).
3) Person A raid invites person C (they accept).
4) Person A invites person E (they accept).
5) Verify that Person A & B must do a /cm refreshgroup to be able to see Person E in group.
 
4 boxing is illegal, reported.


But back to real talk. Thanks for looking at these. I don't have any examples ready to go right now, but if you need a raid force to test them, <Resurgum> is available and we typically have players on. Just send a message either here or in game to Marthog (me) or Pecannius and we can get something setup.
 
Most raid bugs seem to be variations on the same theme. Here's the most egregious culprit:

==========​

EVERYONE'S FAVORITE RAID BUG​
  1. Raid is formed.
  2. A player goes linkdead, gets disconnected, gets booted, etc.
  3. Same player returns and shows in raid/group but is actually bugged.
How to tell:
  • Bugged player will not receive group heals or single-group buffs (e.g. Cunning of the Beast) unless targeted directly, in which case only the bugged player and the caster will receive said heals/buffs (as if the bugged player were in his/her own group).
  • Bugged player's group heals or single-group buffs will land only on him/herself unless an unbugged group/raid member is targeted directly.
  • Bugged player's mana bar will appear empty to other players; other player's mana bars will appear empty to the bugged player.
How to "fix":
  • Bugged player must /dis + /raiddis, then rejoin the group via /invite.
OR (if bugged player is a group/raid leader, does not reappear, cannot /dis + /raiddis, etc.)​
  • All 17 remaining characters must /dis + /raiddis, then reform groups and raid from scratch.
==========​

While we're on the topic, I might use the opportunity to remind everybody that reinstating /cm raiddestroy could at least provide a quick(ish) workaround for raiders. I know it isn't ideal and leaves the onus on players to get the raid in working order any time it bugs out, but it would at least be better than waiting around for 18 characters to /dis + /raiddis, send/accept fresh group invites to reform groups from scratch, and then finally reform the raid. Given that ninja AFKs are inevitable, that unobservant players exist, and that there may be further group/raid bugs preventing players from leaving group or forming a new group beyond the one that initially broke the raid, sometimes a single raid reformation in 2.5 can bring everything to screeching halt for 5-10 minutes.

One last thing. I don't have much to base this on, but I have a suspicion that the root of almost all raid bugs in this client stem from one problematic "feature" that was never present in previous clients -- that when a player leaves the game, s/he is removed from the group. Thus, the player "leaves" the group when disconnected but the same mechanic doesn't apply to the raid, so the bugged player is left in group/raid limbo. This creates a disconnect between the raid roster and the group roster, leading to all the awful bugs we're so painfully familiar with by now. It is my suspicion that if the client can be modified not to remove players from group upon leaving the game, the vast majority of group/raid bugs would vanish in one fell swoop.
 
It is my suspicion that if the client can be modified not to remove players from group upon leaving the game, the vast majority of group/raid bugs would vanish in one fell swoop.
Click to expand...
That was my inclination as well but I was told that this was put in there to fix a number of bugs. I might try to go down that road though.

I'll try to fix the 2 test cases documented but I'm pretty sure there's a bunch of other crap going on too.
 
Fixed 2 issues (will be checked in / patched eventually).
1) When a group member joins, you will automatically refresh your group window (aka no having to type /cm refreshgroup whenever some joins your raid group).
2) When you go LD you will for realz be dropped from group/raid. (Currently if someone goes LD and comes back it looks like they're in group, but in reality they're only like half there. Now they will be totally dropped).

It's surprisingly non-trivial to change group leaders in a raid. But once I figure that out the super annoying bug of when a group/raid leaders goes LD your raid gets fubared should be fixed as well, aka the biggest, most annoying problem.
Also, I want to fix that bug when you have 3 groups in a raid and 1 group drops the raid and try to get raidinvited again, they are kind of grouped but just show up as floating in the raid.
 
ynnear said:
Grinkles,
Do you know if the current client is lua? Might be able to shed some light?
Click to expand...
Rymy & Co. are infinitely better suited to answering this question, but as far as I know (from an outsider's perspective), Shards of Dalaya is a highly unwieldy hodgepodge of Perl for the older stuff, Lua for the past ~5 years of content, and a whole lot of improvised gobbledygook in between.
 
Grinkles said:
One last thing. I don't have much to base this on, but I have a suspicion that the root of almost all raid bugs in this client stem from one problematic "feature" that was never present in previous clients -- that when a player leaves the game, s/he is removed from the group.
Click to expand...
I've been doing some more research and while at first glance dismissed this. Some tests I did let me to come back to this. I'm not going to submit it tonight, but cautiously hopeful that this might be the key to fix most of the current issues. I'm sure other bugs may be introduced from this big change, but preliminary tests look good.
 
ynnear said:
void on client functions arent following their method
Click to expand...

I don't want to jump down your throat again since we've a a bout recently, but please, please, use complete sentences and thoughts when posting on the forums. Anything less just ends up being confusing or callous-seeming. I know that you have good intentions, but I implore you to take to the time required for proper follow through with your intent.
 
AngryCow said:
I don't want to jump down your throat again since we've a a bout recently, but please, please, use complete sentences and thoughts when posting on the forums. Anything less just ends up being confusing or callous-seeming. I know that you have good intentions, but I implore you to take to the time required for proper follow through with your intent.
Click to expand...
troll elsewhere please.
 
Ok let me explain in detail. The game which can be called Server Platform which ever you like. Isn't voiding Clients. Clients are what we call the everquest.exe. Marthog playing marthog would be a Client, Nwaij playing Nwaij would be a client. Uh oh Nwaij gets mad and closes his client why zoning. Group gets bugged. The void Function should kick in, this function removes the Voided Client from group and promotes the most Senior member. This inturn effects the raid functions as well.

Should look like this The script is different but the information should be the same.

//if the group was in the zone already
bool Group::UpdatePlayer(Mob* update){

bool updateSuccess = false;

VerifyGroup();

uint32 i=0;
if(update->IsClient()) {
//update their player profile
PlayerProfile_Struct &pp = update->CastToClient()->GetPP();
for (i = 0; i < MAX_GROUP_MEMBERS; i++) {
if(membername[0] == '\0')
memset(pp.groupMembers, 0, 64);
else
strn0cpy(pp.groupMembers, membername, 64);
}
}

for (i = 0; i < MAX_GROUP_MEMBERS; i++)
{
if (!strcasecmp(membername,update->GetCleanName()))
{
members = update;
members->SetGrouped(true);
updateSuccess = true;
break;
}
}

return updateSuccess;
}


void Group::MemberZoned(Mob* removemob) {
uint32 i;

if (removemob == nullptr)
return;

if(removemob == GetLeader())
SetLeader(nullptr);

for (i = 0; i < MAX_GROUP_MEMBERS; i++) {
if (members == removemob) {
members = nullptr;
//should NOT clear the name, it is used for world communication.
break;
}

or

bool Group::DelMemberOOZ(const char *Name) {

if(!Name) return false;

// If a member out of zone has disbanded, clear out their name.
//
for(unsigned int i = 0; i < MAX_GROUP_MEMBERS; i++) {
if(!strcasecmp(Name, membername))
// This shouldn't be called if the member is in this zone.
if(!members) {
memset(membername, 0, 64);
return true;
}
}

return false;
}

bool Group::DelMember(Mob* oldmember, bool ignoresender)
{
if (oldmember == nullptr)
{
return false;
}

for (uint32 i = 0; i < MAX_GROUP_MEMBERS; i++)
{
if (members == oldmember)
{
members = nullptr;
membername[0] = '\0';
memset(membername,0,64);
break;
}
}

/* This may seem pointless but the case above does not cover the following situation:
* Group has Leader a, member b, member c
* b and c are out of zone
* a disconnects/quits
* b or c zone back in and disconnects/quits
* a is still "leader" from GetLeader()'s perspective and will crash the zone when we DelMember(b)
* Ultimately we should think up a better solution to this.
*/
if(oldmember == GetLeader())
{
SetLeader(nullptr);
}

//handle leader quitting group gracefully
if (oldmember == GetLeader() && GroupCount() >= 2)
{
for(uint32 nl = 0; nl < MAX_GROUP_MEMBERS; nl++)
{
if(members[nl])
{
if (members[nl]->IsClient())
{
ChangeLeader(members[nl]);
break;
}
}
}
}

Should be something Similar to this. Maybe we can look at this?
 
I appreciate the effort, but the old eqemu code you linked is so far from anything usable/similar in the current code base that it doesn't begin to address/fix anything.
 
Rymy said:
I appreciate the effort, but the old eqemu code you linked is so far from anything usable/similar in the current code base that it doesn't begin to address/fix anything.
Click to expand...

You miss what i am saying. Please review how Voids are being done on Clients. I strongly Feel the answer is there.
 
Also Ran into a problem that someone kicked a client off and made the group go boom, so i feel this may need more review Taryth
 
You must log in or register to reply here.
Back
Top Bottom