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.

Good job fellow old coder. Although I got out of programming some 20 years ago, I too did a fair amount of 6502 on PETs, C64s, VIC 20s of all things. Also, Z80 on my TRS-80

Although with this opcode, the pet window comes up and you can control the pet with it, I didn't see the pet's health bar in other group members group window. I'm guessing the code just needs altering to send the OP_Charm packet to all group members.

Only this morning? Hell, you're the main reason why I keep coming back to these forums! You always have a very useful fix for all eras - since you like to fix stuff that started back in the older days, it then benefits the classic people and the "live pursuants', or anyone else for that matter.

When I start my daily 'fiddle' with EqEmu , first thing that comes to mind is, "I wonder if Derision has anything new? I think I'll check the forums ..."

If I were still giving out ranks, I would have had to find a new rank for you.

Thank you for the fix!

That is damned impressive. I've seen so many things on here dismissed as not being feasible, and I'm always so proud to see someone find a way to work it. Fantastic work!

Actually I meant you could sniff the packet coming from the client. Still, I don't know how far that would get you. Obviously if the problem is the opcode sent back down to the client, not very.

And great work on finding the OpCode!

Well Im sure there must be some routine to send updates about specific NPCs, this issue certainly isnt as much of an issue as not being able to buff ones pets if a necro, mage, druid and anyone else Id forgotten.

All pets health bars, summoned or not, arent updated without targetting the pet as it is right now, so most charmers/pet classes have become used to keeping on eye out on their pets health.

Although, feel free to fix these two issues too. heh.

Again, thanks.

He already did: http://eqemulator.net/forums/showthread.php?t=25699

Cool. Assuming that sends pet health updates to other group members too, that leaves only the update to group members when someone charms/loses charm on a mob.

Good work!

It's not really anyones fault, I think there's a reason for this; Roughly, we have two types (in the computer realm) - The Hackers (good hackers!) and the Programmers. A Hacker will try anything regardless of 'if it's supposed to work or not'. Hackers are what made the C64 PC so popular (C64 (Commodore 64) was probably the most hacked PC ever). On the other hand, Programmers follow rules and do not like to depart from that.
In general, Hackers have some knowledge of programming while a good Programmer is highly educated in his area.
The trick is to have a highly educated programmer that likes to hack, and has no qualms about it (hacking, trying anything). Keep in mind, to me, hacking is not a bad word, and it is a main ingredient to a lot of good things that happened in the computing world.
That's why I tried to tell some people, you have to get the fixes posted in ASAP, not worry about if it's perfect. People like Derision obliviously know what they are doing (a highly educated programmer that likes to hack?), and don't need to be oppressed by the useless bureaucracy that has developed here. In fact, I now see other submissions(from other people) that were posted a long time ago and were totally ignored? why? Because someone said it was not going to work?
New stuff needs to get placed in the source, if it doesn't work, well, we all know this is beta (alpha?), it can be taken out again.
But I'm tired trying to get this project to 'rise from the dead'. I finally learned how to add all these submissions myself, to my own source.