Some stuff

[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

[Damilis]

Originally Posted by John Adams

Ok, now I know you are an engineer IRL.

If I had a dime...

Now now, there's nothing wrong with engineers :P

KLS earns two thumbs up IMHO. Give that man a Klondike Bar!

[Dralanna]

Looking at your code for backstabs, and I'm a little confused.

the old code for max damage is

skillmodifier = (float)bs_skill/25.0;	//formula's from www.thesafehouse.org
max_hit = (int)(((float)primaryweapondamage * 2.0) + 1.0 + ((level - 25)/3.0) + ((GetSTR()+GetSkill(BACKSTAB))/100));
max_hit *= (int)skillmodifier;

the new code is

skillmodifier = (bs_skill*100)/25;	//formula's from www.thesafehouse.org
if(level > 25){
max_hit = ((primaryweapondamage*2) + 1 + ((level-25)/3) + ((GetSTR()+bs_skill)/100));
}
else{
max_hit = ((primaryweapondamage*2) + 1 + ((GetSTR()+bs_skill)/100));
}
max_hit *= skillmodifier;
max_hit /= 100;

So unless I'm missing something, for rogues over 25th level, the code is the same. In the new code you're multiplying the backstab skill by 100 in the skillmodifier variable, but then dividing by 100 in the end. Seems like an unneeded calculation.

[KLS]

The backstab formulas are wrong, Rogean is working on more accurate ones at the moment. The current ones pretty much under estimate backstab damage across the board, I just rewrote the formula for under 25 because part of it becomes increasingly negative for every 3 levels under 25 you become.

Let me explain what's happening with the new code with the * 100 / 100 later thing.

skillmodifier = (bs_skill*100)/25;

this makes our skill modifier for say 90 skill 360, in the old code we used floats for accuracy but we don't like to mix float and int math where we can avoid it. The old mod for a 90 skill would have been 3.6 but if we tried to simply switch that over we would lose the accuracy of using floats.. but when working with larger numbers you don't lose that accuracy when dividing.

Essentially we don't lose a .6 in the calculation doing it this way and don't have to convert from ints to floats to ints again.

I may not of explained it as well as I could have but meh.