Some stuff

[fathernitwit]

havent had time to give this the attention it needs yet, but.. rules are designed to be fast, it basically works out to this much work:
rules_array[index].value

also, your change for groups seems to have caused more harm than good, people are reporting that once a group is formed, you cannot invite anybody else (which means to me that nobody is the leader, client side). Im going to revert it, in case you want to work on it more.

[KLS]

Odd, I'll have to look at it some more, I admit I don't really have more than myself to test groups with most times and I can't really support more than dual boxing with my server on my comp but I'll see what can be done, might have to recruit some people in IRC for this one =/

Nice about the rules though that means I can make any new mitigation system I put it be totally tweakable without needing to recompile, which seems nice considering I doubt many people have put much thought into str and ac currently in their databases when making the monsters.

[John Adams]

Something else up with grouping that I do not remember happening before. If I am solo, I can buff myself up no problem. I then join a another character to my group, and buff them, also no problem. But if I target myself again and try to re-buff, it only casts on the other player in the group. Even if they leave the group. It never seems to forget them. Even if they logout. I cannot target myself and get a buff to land.

This is the first I've seen of this. Also using 871 binaries.

[KLS]

I've seen that too John sorta, if I leave the group I'm fine and it only happens for group buffs for me, meaning to look at it. Not sure I'm getting the same problem as you however, think what's happening with me is a group spell casts on the leader first and goes down from there, and I think something's happening where if the spell wouldn't take hold cause of stacking somewhere it just cancels for everyone. If you can give me more info on your problem, detailed step by step instructions for reproducing etc, I can look into it.

This group thing is one of the most frustrating things I've ever done. The client knows it's part of a group and knows it's the leader but some piece of info is missing or inconsistant with the rest and the packet for invite isn't sent by client. On the other end, the client knows it's the leader and is in the group but again the same thing except this time it wont send group chat, sony set this up in a very confusing manner. I guess I just assumed at the beginning that the client wasn't completely retarded.. last time I'll have faith in that =P

I would go ahead and reverse it, not being able to talk is better than not being able to invite till you zone and I've tried about 10-15 different group packet combos with no luck so far.

[John Adams]

Let's see if I can step this through...

Leader char casts Speed of the Brood on himself, it lands ok.
Leader invites player to group, and player joins.
Leader then casts same Speed of the Brood on the new group member.
Leader then cancels the effect so he has no buffs.
Targets himself.
Casts Speed.
Nothing lands. Message in the window says the other player feels faster (or whatever).
If that player leaves the group, same thing. Seems stuck on targetting that player.
If the player logs off, leaving only the Leader in the zone, the buff casts, you see the glowies for it, but no message, and no effect icon.

Let me run through a few other tests with this. I might have been casting a group buff on myself, though I should still get it, that might be the key. I'll report back in a few.

[KLS]

Hum another thing I noticed something seems up with Character rules, they aren't loading from the DB correctly for me and trying to list them with #rules list Character returns: Failed to list rules!

I'll do a #rules setdb Character:MaxLevel 70 but when I zone it's back to the default in code of 65, same with Character:LeaveCorpses and Character:LeaveNakedCorpses.

All the other rules seem to work fine so long as they aren't in the Category character.

[John Adams]

Originally Posted by KLS

Hum another thing I noticed something seems up with Character rules, they aren't loading from the DB correctly for me and trying to list them with #rules list Character returns: Failed to list rules!

Almost sure we saw this error before the recent changes. It's in another thread about the rules system, I believe.


Back to groups... I found one thing which you might have mentioned. If the leader sends an invite to all party members before any one of them accepts, they can all join, and chat/buffs/etc all seem to work ok. If you invite 1 person, then they accept, then invite another, they get no invite.

As for my previous report, I was mixing how Group Buffs and Single Target buffs work, apparently. I think everything is just fine there, so I was way wrong! There still may be something in the message reporting, but I mostly played melee's on Live, so I cannot recall what message is given if you cast a group buff while targetting someone who is not in your group. No message at all, or should I still get the buff?

Sorry KLS. No issue with buffs and the new code, pretty sure.

[KLS]

Something with the #rules list:

RuleManager::CategoryType RuleManager::FindCategory(const char *catname) {
	int r;
	for(r = 1; r < _CatCount; r++) {
		if(strcasecmp(catname, s_categoryNames[r]) == 0)
			return((CategoryType) r);
	}
	return(InvalidCategory);
}

Any reason we start the index at 1 instead of 0? I changed that and rules seem to list fine.

Rule loading appears just a matter of me being a newbie, wasn't using #rules store default for default rules like I should have been.

On live if you cast a group buff on someone not in your group without /tgb on it will target your group else it will target theirs. /tgb seems to be a little iffy on the emu though, was gonna say I couldn't reproduce your issue at all. Unsure of the message you should be getting.

[paaco]

I tryed to use #rules to set my server to lvl 50, it told me that same message about failing. But it worked. I thought that was odd myself.

[KLS]

Was noticing current end wasn't saving right with #save and zoning when I came across this:

in Client::FinishConnState2(DBAsyncWork* dbaw) (at about line 5980)

	CalcBonuses();
	CalcMaxHP();
	CalcMaxMana();
	if (m_pp.cur_hp <= 0)
		m_pp.cur_hp = GetMaxHP();
	
	SetHP(m_pp.cur_hp);
	Mob::SetMana(m_pp.mana);
	SetEndurance(m_pp.endurance);

We calculate maxhp and max mana in calcbonuses.

void Client::CalcBonuses()
{
	_ZP(Client_CalcBonuses);
	memset(&itembonuses, 0, sizeof(StatBonuses));
	CalcItemBonuses(&itembonuses);
	CalcEdibleBonuses(&itembonuses);
	
	RecalcWeight();
	
	CalcSpellBonuses(&spellbonuses);
	
	CalcMaxHP();
	CalcMaxMana();
	CalcMaxEndurance();
	
	CalcAC();
	CalcATK();
	CalcHaste();
	
	CalcSTR();
	CalcSTA();
	CalcDEX();
	CalcAGI();
	CalcINT();
	CalcWIS();
	CalcCHA();
	
	CalcMR();
	CalcFR();
	CalcDR();
	CalcPR();
	CalcCR();
	
	rooted = FindType(SE_Root);
}

An issue I see is we calc the hp/mana/end before we calculate the stats which could potentially cause problems, could we not change this stuff to:

	CalcBonuses();
	if (m_pp.cur_hp <= 0)
		m_pp.cur_hp = GetMaxHP();
	
	SetHP(m_pp.cur_hp);
	Mob::SetMana(m_pp.mana);
	SetEndurance(m_pp.endurance);

void Client::CalcBonuses()
{
	_ZP(Client_CalcBonuses);
	memset(&itembonuses, 0, sizeof(StatBonuses));
	CalcItemBonuses(&itembonuses);
	CalcEdibleBonuses(&itembonuses);
	
	RecalcWeight();
	
	CalcSpellBonuses(&spellbonuses);
	
	CalcAC();
	CalcATK();
	CalcHaste();
	
	CalcSTR();
	CalcSTA();
	CalcDEX();
	CalcAGI();
	CalcINT();
	CalcWIS();
	CalcCHA();
	
	CalcMR();
	CalcFR();
	CalcDR();
	CalcPR();
	CalcCR();
	
	CalcMaxHP();
	CalcMaxMana();
	CalcMaxEndurance();

	rooted = FindType(SE_Root);
}

That way we would only calculate hp and mana once at that point and max endurance would calculate correctly on connection.

[KLS]

Here's what's up with the groups:

When we do it the way I do it, what I assume is probably the correct way the client switches from using GroupInvite opcode to GroupInvite2 opcode and GroupFollow opcode to GroupFollow2 opcode. Of course no one ever figured those opcodes out so they're all set to 0x0000.

Here are the titanium opcodes, I don't have the 0.6.2 opcodes yet because I don't have a 0.6.2 client atm.

OP_GroupFollow2=0x42c9		#this is a 2nd version of follow, that's used with invite version 2 is used 
OP_GroupInvite2=0x12d6		#this is a 2nd version of invite

Tested it with 3 people and it worked fine, leader could talk and could invite the 3rd person correctly. Such a simple problem and it only took me 2 days to figure out.

[John Adams]

lol, well at least you CAN figure it out. Maybe if I stick with this a few years, I might learn something.

[KLS]

For 6.2

OP_GroupInvite2=0x1f27

I wasn't able to find the OP_GroupFollow2 for 6.2, but the client appears to only send a OP_GroupFollow2 on accepting a group they were invited to with OP_GroupInvite2. So I made a little work around in Handle_OP_GroupInvite2 that recreates the incoming packet but always sets it to a GroupInvite opcode before sending it to the target.

void Client::Handle_OP_GroupInvite2(const EQApplicationPacket *app)
{
	if (app->size != sizeof(GroupInvite_Struct)) {
		LogFile->write(EQEMuLog::Error, "Invalid size for OP_GroupInvite: Expected: %i, Got: %i",
			sizeof(GroupInvite_Struct), app->size);
		return;
	}

	if(this->GetTarget() != 0 && this->GetTarget()->IsClient()) {
		//Make a new packet using all the same information but make sure it's a fixed GroupInvite opcode so we
		//Don't have to deal with GroupFollow2 crap.
		EQApplicationPacket* outapp = new EQApplicationPacket(OP_GroupInvite, sizeof(GroupInvite_Struct));
		memcpy(outapp->pBuffer, app->pBuffer, outapp->size);
		this->GetTarget()->CastToClient()->QueuePacket(outapp);
		safe_delete(outapp);
		return;
	}
	/*if(this->GetTarget() != 0 && this->GetTarget()->IsNPC() && this->GetTarget()->CastToNPC()->IsInteractive()) {
		if(!this->GetTarget()->CastToNPC()->IsGrouped()) {
			EQApplicationPacket* outapp = new EQApplicationPacket(OP_GroupUpdate,sizeof(GroupUpdate_Struct));
			GroupUpdate_Struct* gu = (GroupUpdate_Struct*) outapp->pBuffer;
			gu->action = 9;
			strcpy(gu->membername,GetName());
			strcpy(gu->yourname,GetTarget()->CastToNPC()->GetName());
			FastQueuePacket(&outapp);
			if (!isgrouped){
				Group* ng = new Group(this);
				entity_list.AddGroup(ng);
			}
			entity_list.GetGroupByClient(this->CastToClient())->AddMember(GetTarget());
			this->GetTarget()->CastToNPC()->TakenAction(22,this->CastToMob());
		}
		else {
			    LogFile->write(EQEMuLog::Debug, "IPC: %s already grouped.", this->GetTarget()->GetName());
		}
	}*/
	return;
}

Tested on 6.2 earlier and it worked fine, will need to go test on titanium tonight but don't see why it shouldn't work.

[John Adams]

Originally Posted by KLS

will need to go test on titanium tonight but don't see why it shouldn't work.

Ok, now I know you are an engineer IRL.

If I had a dime...

[KLS]

Just some more stuff, I posted this to the irc but it keeps getting lost, been asked to repost it a few times to irc but it always seems to get lost again, so I'm gonna post it here too.

-Redid the Critical Hit code to be portable
-Fixed Cleave effects in the process of redoing critical hits
-Added criticals to special attacks
-Applied haste to combat ability timers
-Cleaned up a lot of special attack code
-Rewrote most of the backstab function, and pretty much all of the MonkSpecialAttack one
-Redid some of the npc::doclassattacks, namely moved Harmtouch/Layonhands to a seperate timer from bash/kick
-Added a rule that lets server ops decide when NPCs can bash/kick
-Raised the base damage of kick/bash slightly, mostly so it doesn't do so little damage on the lower end, was getting kicks for 3 damage at level 15.
-Monk attacks can now be missed as well as avoided
-Attacks wont avoid so often, they were being avoided twice in the code.
-Removed the pvp reductions from special attacks, we already do this in the client::damage function, no need to do it twice.

http://hmproject.org/files/spcatk.patch