Charmed mobs and the pet/group window and buffs
 

When a mob is charmed, the information that that mob is now your pet isnt being sent to anyone currently in the zones clients. So the charmers pet window isnt usable to control the pet(although /pet commands still work) and others in the group cant see the pets health bar in the group windows of UIs that support that.

People who arrive in the zone after a mobs been charmed clients do recognize the charmed mob as a pet, so they can see the pets health in the group windows

This also adversely effect necros, mages and druids when they charm something as their pet only buffs wont work on what the client sees as not a pet.

Im asking that one of your brilliant coders fix this.

Thanks.

I took a quick look at this and my guess is that the main problem is the OP_Charm opcode for Titanium is unknown (set to 0x0000 in patch_Titanium_conf).

This would be the opcode that the server sends to clients to inform them that an existing spawn is now a pet.

There is a value for this opcode in patch_6.2.conf, so it may work on that client (I'm at work and can't test it).

Wouldnt the Titanium and 6.2 share the same op code since this is a function long time in the game or did they completely redo the ops at some point so their no commonality.

Basicly, if most op codes are common between the two clients, could ya try copying the 6.2 op code to the Titanium one?

Opcodes change every time the client changes, so no they aren't the same.

Damn, thats lame.

Well since new people who arrive in the zone know that its a charmed mob, couldnt this be kludged to work by respawning the mob charmed and when charm breaks or forcing some sort of resend of that mobs info to people in the zone when its state changes like when you hand a pet a weapon, etc?

I guess this isnt a killer issue. Just something thats been around a while and was wondering if anyone had bothered to look into it.

Aye, and a royal pain in the ass, too.

I believe KLS was once long ago working on a workaround for this where the opcode wasn't needed. I think it was along the lines of once a NPC is charmed, the server was forced to send the pet window packet. I have the code archived somewhere, I'll see if I can find it (unless you still have it, KLS) Though, I was never able to get it working which I fully admit may have been an error on part part during merging.

Can work around not having the op by sending a despawn packet followed by a new spawn packet with the pet data set. It's inefficient but it gets the job done without having the opcode.

How does the server send the update that Ive handed my pet a weapon to everyone?

Could this be done a simular way?

If you can do the respawn idea so that one doesnt lose target when charm breaks, thats quite workable. Right now, Ill break charm early to recharm it and have a melee pull agro off me.

If we lose the target when the charm breaks, it certainly can add a extra undesirable thrill. :p

Maybe some industrious soul could run WireShark in a sandboxed server with two clients and then charm something. Might be an easy way to find the opcode's value. Then again I have no idea how much data this would mean you have to sift through but it does seem possible.

Was thinking a bit more about the respawn idea.

One thing that needs to be preserved through charming and breaking is the mobs items. I sometimes give my pet nice weapons off other mobs to use and then kill my pet later to reclaim the weapons.

Also, I could see the respawning being used to get a named mob to repop weilding something desirable. An exploit that Im sure most would servers would like to prevent.

The servers dont just automatically send the packets. They have to be coded to, and that's the problem.

I tried this on the 6.2 client the other day, and the pet window didn't come up when I charmed a mob.

I just found a 6.2 packet collect in the PEQ logs with an example of charm. It would appear the 6.2 opcode for OP_Charm is 0x10a1, not 0xdff as specified in patch_6.2.conf. This works for 6.2 only, not Titanium, so if anyone is still using 6.2, in patch_6.2.conf, change:

to:

Unfortunately it would appear packet collects from the Titanium era client are very rare, at least in the PEQ repository :(

That's because the Titanium client never actually existed on Live, by the time it shipped and hit stores several patches had already occurred on Live. Where as since 0.6.0 was a Live patch for a bit of time, we have tons of logs from it.

Oh, I thought Titanium was the only full package that actually did exist on live at some point. And that was why Titanium was able to be used while previous packs weren't. Which is also why the previous versions of the emu required actual live patches to work.

I'm feeling rather proud of myself this morning, I found the OP_Charm opcode for Titanium.

I read the Wiki pages that Trevius posted links to a couple of weeks back about using IDA to Disassemble the client
and find Opcodes.

E.g.: http://www.eqemulator.net/wiki/wikka...DevAsmRoutines

I don't know x86 assembler, however I have programmed in 6502 and IBM Mainframe assembly in years gone by, but I
still thought that finding opcodes through disassembly was 'out of my league'.

Well, I downloaded the free version of IDA, and disassembled the 6.2 client. Armed with the 6.2 Opcode, and with the
pointers to the dispatch routines and general methodology outlined in the wiki, I found the Charm routine in the 6.2
client.

I then disassembled the Titanium client and tried to find the same routine there, which I did. I then traced this back
up through the call tree and voila, for Titanium, OP_Charm=0x12e5. Just change this in your patch_Titanium.conf on the
server and restart it.