Going to chime in: I think bots are a clusterfuck and if we're implementing mercs we should implement them as a new system and not shoehorn them into the gap we've made with bots(esp since they don't work 100% the same).
|
Maybe once Mercs are in, trunk drops support for bots, who are then maintained in the MercsAndBots branch. Seems like an acceptable solution to me.
|
Here are some more Mercenary related opcodes for SoD and UF:
SoD Code:
OP_MercenaryDataUpdate=0x0786 # Code:
OP_MercenaryDataUpdate=0x57f2 # Also, it looks like OP_MercenaryAssign may actually just be OP_WeaponEquip1 according to the info I can find in my last collects. It is the same size packet and seems like the same struct. If we can verify this, it is one less thing to deal with for merc stuff. Code:
// 0x7404 - OP_MercenaryAssign (Same packet as NoMercenaryHired_Struct?) [Server->Client] Code:
[OPCode: 0x7404] OP_WeaponEquip1 [Server->Client] [Size: 12] |
And here are some roughed in packet handling for mercs for client_packet.cpp. These are mostly just hard set with the basic packet responses so they can be corrected later with actual functions supporting them.
Code:
ConnectedOpcodes[OP_MercenaryCommand] = &Client::Handle_OP_MercenaryCommand; Code:
void Client::Handle_OP_MercenarySuspendRequest(const EQApplicationPacket *app) |
I think it may need some testing, but based on my VoA merc collects, I found a couple more opcodes that appear to be mercenary related:
SoD: Code:
OP_MercenaryDismiss=0x319a # Code:
OP_MercenaryDismiss=0x0bd0 # All of these new packets will probably take some playing around with to figure out which are required for what and which may not be required at all (if any). I will work on some basic handling for these as well, which can be refined later. |
I think this should be the basic handling for those 2 new opcodes:
client_packet.h Code:
void Handle_OP_MercenaryDismiss(const EQApplicationPacket *app); Code:
ConnectedOpcodes[OP_MercenaryDismiss] = &Client::Handle_OP_MercenaryDismiss; Code:
void Client::Handle_OP_MercenaryDismiss(const EQApplicationPacket *app) |
The last commit I did for Rev2234 is causing a zone crash when sending the mercenary merchant list. Simple fix is this:
client_packet.cpp in Client::Handle_OP_MercenaryDataRequest(const EQApplicationPacket *app) Replace: Code:
packetSize = sizeof(MercenaryMerchantList_Struct) - 12 + mercTypeCount * 4 + ( sizeof(MercenaryListEntry_Struct) - 40 + sizeof(MercenaryStance_Struct) * mercStanceCount ) * mercCount; Code:
packetSize = sizeof(MercenaryMerchantList_Struct) + sizeof(MercenaryListEntry_Struct) * mercCount; I don't have access to test this right now, but will check it in the morning and commit the fix. Just noting it here for anyone following the merc branch changes. |
See this is why we need automatic packet encoding/decoding even at the application level. =/
|
I did some spawn work last night. I cleaned up some code in client_packet.cpp and tried to flesh out the hiring / spawning process.
I was able to get the merc when hired added to my group. I had added some code for the merc to follow me, but it doesn't work yet. I didn't get a chance to test it out other than seeing it didn't work. I added some code for dismiss, but it didn't seem to work either. It may have been an issue with getting the merc owner, as I had a similar issue on spawning I was able to fix. I just ran out of time to test out why. My plan is to clean up the spawning process a little more, get my merc to follow me, get suspend/unsuspending & dismiss working tonight. A little more work needs to be done before being able to save the merc to the database (definitely not in the player profile). The merc templates are currently being stored in the zone, so there is duplication. It could be moved to EQSharedMem to eliminate that, but to get it up and running, that's where I put them. The shared memory stuff may be beyond my pay grade, but there's plenty of time before anyone needs to worry about it. I think it's around 150kb per zone if my math is close. If anyone has a live paid account on EQ that has mercs, I have some things I need to check on that I can't on my account. If anyone is able and willing, I'd appreciate it. |
Also, I think I have everything to put the correct stances in. Is there anything else that needs to be done besides modifying the packet size when creating it to account for the extra stances? Besides actually loading the correct stances, of course.. I'm in no hurry to add them, but wanted to check so I knew what changes would be needed. Passive and Balanced are fine for what we need to do yet.
|
Quote:
|
Quote:
If we need to increase the number of merc types or stances at some point, I think we just have to adjust the related structs in eq_packet_structs.h. |
Okay, good to know.
5 stances should be okay, I believe. I'll have to check for any that might have more. Caster has the most - Passive, Balanced, Burn, and BurnAE for sure, maybe Efficient or Aggressive (I don't have them right in front of me). Healers have Passive, Balanced, Efficient and Reactive. We will need to increase Merc Types, though. While I'm not even sure if they have any Master Mercenaries, there are a few Mercenary Merchants who have 2 races, so they will have at least 4 (6 if you include master). I was able to get mercs to follow last night, and dismiss and suspend mostly working. Also, I fixed a couple of issues that allow the illusion packet to work (purchasing mercs from Guardian Norerd in PoK who needs to be changed to be a froglok now results in a froglok merc). I still need to add the SQL to fix the mercenary merchants, but i know him and Mercenary Mdjai in Crescent Reach work. |
I apparently made a few changes before I committed that I forgot about. One is causing a crash when hiring a merc. To fix this, add the following to the Merc constructor:
Code:
p_depop = false; |
Quote:
|
All times are GMT -4. The time now is 06:03 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.