Mercenaries

[trevius]

Originally Posted by Secrets

before I went crazy.

I though you were born crazy! <3 Secrets

And yeah, it is a unix timestamp. I didn't look much into that function when I stuck that in there. I was just populating fields with data. You may be right that it is returning an undesired result.

[Secrets]

Originally Posted by trevius

I though you were born crazy! <3 Secrets

And yeah, it is a unix timestamp. I didn't look much into that function when I stuck that in there. I was just populating fields with data. You may be right that it is returning an undesired result.

I'll be committing what I learned from the disassembly soon.

In the meantime, here's a list of valid merc status update IDs. The packet is used on the client and server, whereas the client sends different data than the server packet. It's not just used for hiring as you can see below:

// [OPCode: 0x5e78 (OP_MercenaryHire?)] On Live as of April 2 2012
/*
Valid response IDs:

0 - Hire me! (Assign Merc after sending this.)
1 - Insufficient money message.
2 - Mercenary-To-Hire does not exist in the server's DB.
3 - Mercenary failed to spawn. (this actually tells us the mercenary should spawn BEFORE recieving this packet.)
4 - Mercenaries not allowed in raids.
5 - You already have a mercenary request pending
6 - You must dismiss the mercenary before hiring a new one.
7 - You must dismiss your suspended one before hiring a new one.
8 - Group is full.
9 - Error creating mercenary
10 - Replacing mercenary(?!)
11 - Your mercenary has quit! You ran out of money to pay for your mercenary!
12 - Your mercenary waived an upkeep cost of %d plat, and %d gold and your mercenary upkeep cost timer has been reset to %s. <-- these values are for GM resets of mercenaries and are generated from the client's
mercenary info. NOT from the packet.
13 - Your mercenary is about to be quit due to insufficient funds! <--- Sent before the mercenary quits, unsure of time sent before.
14 - There is no mercenary liason nearby! <-- hacking attempt check if no mercenary merchant is in the zone!
15 - You are too far away from the liason! <-- Liason exists as type in the zone, but client is too far away. (position update happened)
16 - You do not meet the requirements for that mercenary! <-- For example, if a mercenary is 'unlocked' in some way, send this if they do not have the mercenary unlock.
*/

[bad_captain]

I did some debugging on the timer stuff. 0 or 1 sized didn't seem to help. I did notice that at some point it was working and tried to figure out how I did it.

I found out there is a bug where if you have a merc suspended, it allows you to purchase a new merc. That part is easily fixed, but I found out something interesting. If I suspend my merc, then purchase a new one, my timer suddenly began to work. With the help of the debug messages, I found that if I had a merc suspended (the client thinks I have one), and purchase a new one, it doesn't do a data request for the merc data, since I assume the client thinks it already knows it. Somewhere in the data response, where it requests the current merc (merchant ID = 0), there's something that causes the timer to not work.

I did notice that there are two very similar structures: MercenaryData_Struct and MercenaryListEntry_Struct. There may be a chance to combine the two, and there may be a mixup of when to use one or the other, or something. I'll check into this a little more, but I thought I would throw it out there.

[trevius]

Thanks for the info, Secrets! That is some nice data for the hire packets for sure.

Originally Posted by bad_captain

I did notice that there are two very similar structures: MercenaryData_Struct and MercenaryListEntry_Struct. There may be a chance to combine the two, and there may be a mixup of when to use one or the other, or something. I'll check into this a little more, but I thought I would throw it out there.

Yeah, when I first wrote the structs, those 2 were using the same struct for their packets. The problem was that on the Live collect from VoA that I have, the MercenaryData_Struct has an extra field at the end, which I am really not too sure about. So, I split them up into 2 separate structs just to get things working. Since we actually build those packets on the fly in the patch files, the structs don't actually matter other than being a place to store the data so we can pull it when creating the packets in the path files. So, at this point, we should be able to just remove the MercenaryListEntry_Struct struct and store everything in MercenaryData_Struct instead, including the additional field. Even if that additional field isn't used, we can determine if we want to use it or not when we create the packets in the patch files.

Right now, it looks like I have that additional field at the end of the data update commented out in the encodes. I would either need a collect from SoD and UF or to have someone like Secrets to check the IDA output to figure out the correct packet struct to verify if it is correct or not. Maybe just uncommenting that so it adds the extra field would make it work, I dunno. I also don't know if that field only comes at the end of the packet, or if it can also come with every iteration of the merc data if more than one merc is owned. If it is related to owning multiple mercs, I think that was added later, so SoD and maybe UF might not have that field. At this point, it is just speculation though.

It is interesting that your timer started working when you had a merc already suspended. That sounds like the client is ignoring the merc data update response the way we are sending it. Something like that could definitely be caused by a packet struct issue, like size, which could be due to that missing field at the end (or any other peice of data). Right now, the data update struct isn't being fully populated based on what I saw on my VoA collects anyway. I know the merc name field is not yet being populated, which could also be the reason why it is failing. The variable sized packets just take a bit more work to get them sending as needed, but I am sure we can work out the rest of whatever is needed easy enough. The merc name field can probably just be changed to be 64 bytes, and we can add that to the encode with the appropriate size and null terminator. Also, if that last field in the data update only comes after the iterations for each merc data, we can't add it after "MercenaryData_Struct MercData[0]" due to the fact that 0 sized arrays have to be at the end of the struct, but we could easily just add it in during the encode by checking if we are on the last iteration and only adding it then. Either way, that doesn't matter too much at this point, until we get to the point of trying to manage more than 1 owned merc at a time.

[bad_captain]

The ability to have multiple mercs came in December of last year, which was a month after VoA came out. From the December 14th 2011 patch notes:

Mercenary Roster -
- Players can now buy extra mercenary slots on the Marketplace and keep a roster of mercenaries that they can switch between. Mercenaries operate the way they used to, except that if you purchase another mercenary, it will become active and replace the mercenary you had active before (if any). Dismissing a mercenary will cause the first remaining mercenary in your roster to become the active mercenary (though suspended). Transferring a mercenary will cause the target player's active mercenary to be suspended and the newly transferred one to become active.
- To switch mercenaries in your roster, open the Mercenary Management UI.
- Added the new command /mercswitch. With no arguments, it lists the current roster of mercenaries and displays the one that is currently active. Adding a parameter allows switching between mercenaries in the roster.

I don't think the name is needed for SoD or UF, and wasn't present until this patch. I have collects from December 7th or 8th (before the change), and then Provocating sent me caps from December 27th - 30th (after). One of the unknowns may not be needed as well, I will have to double check my packets to verify. The additional fiend at the end may have come at the same time, as I don't believe it is in my captures either. I hope to verify tonight, but things have been a little busy around work with the election.

Here's a packet from 12/5:

12/5/2011 2:56:56 AM
[OPCode: 0x0327] OP_MercenaryDataResponse [Server->Client] [Size: 82]
000 | 01 00 00 00 e4 a4 bf 07 01 00 00 00 16 07 00 00  | ................
016 | e4 a4 bf 07 29 41 c0 07 00 00 00 00 00 00 00 00  | ....)A..........
032 | 00 00 00 00 00 00 00 00 13 00 00 00 00 a0 bb 0d  | ................
048 | 00 24 00 00 00 01 00 00 00 02 00 00 00 00 00 00  | .$..............
064 | 00 01 01 00 00 00 02 00 00 00 00 00 00 00 01 00  | ................
080 | 00 00                                            | ..

The Group UpdateB packet and the two following have the merc's name.

[OPCode: 0x7139] OP_Unknown [Server->Client] [Size: 86]
000 | e1 ad 00 00 02 00 00 00 xx xx xx xx xx xx 00 00  | ........MyName..
016 | 00 00 00 xx xx xx xx xx xx 00 00 00 00 05 00 00  | ...MyName.......
032 | 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00  | ................
048 | 44 69 61 73 72 69 72 31 30 32 37 39 39 00 01 00  | Diasrir102799...
064 | xx xx xx xx xx xx 00 05 00 00 00 00 00 00 00 00  | MyName..........
080 | 00 00 00 00 00 00                                | ......

12/5/2011 2:56:58 AM
[OPCode: 0x7706] OP_Unknown [Server->Client] [Size: 16]
000 | 5c 02 00 00 c2 04 00 00 44 69 61 73 72 69 72 00  | \.......Diasrir.

I haven't checked to see if those opcodes have been figured out. I just wanted to post them for reference.

[trevius]

I think those 2 unknowns are just normal group packets. They look pretty familiar just based on the info in them.

That 12/5/11 packet is interesting. Here is the breakdown of the packet into a struct as far as I can tell. Almost all of the fields match up with what I have seen on VoA other than the last extra field on VoA and the Status field for the new F2P membership stuff. Though, there appears to be an extra MercType field at the top of the struct, which is something I haven't seen before. Maybe if we try the struct like that, the update will work properly. I will see if I can figure out a good way to do that. I can't think of a good reason to have the MercType field redundant like that unless it is something to tell the client which is the highest type it currently has access to or something.

01 00 00 00 - 1 - MercStatus
e4 a4 bf 07 - 130000100 - MercType again ?
01 00 00 00 - 1 - MercCount
16 07 00 00 - 1814 - MercID
e4 a4 bf 07 - 130000100 - MercType
29 41 c0 07 - 130040105 - MercSubType
00 00 00 00 - 0 - PurchaseCost
00 00 00 00 - 0 - UpkeepCost
00 00 00 00 - 0 - AltCurrencyCost
00 00 00 00 - 0 - AltCurrencyUpkeep
13 00 00 00 - 19 - AltCurrencyType
00          - 0 - MercUnk01
a0 bb 0d 00 - 900000 - TimeLeft
24 00 00 00 - 36 - MerchantSlot
01 00 00 00 - 1 - MercUnk02
02 00 00 00 - 2 - StanceCount
00 00 00 00 - 0 - MercUnk03
01          - 1 - MercUnk04
01 00 00 00 - 1 - StanceIndex
02 00 00 00 - 2 - Stance
00 00 00 00 - 0 - StanceIndex
01 00 00 00 - 1 - Stance

[bad_captain]

I think it is the same as the initial data response, where it has the number of types to follow, the merc type, the number of mercs that follow, and then the merc. From what I've seen after hiring 5-10 mercs during that time ( I was mostly trying to get the full response packets so I didn't get as much as I'd like of later packets), the first is always 1, followed by the type. I may be wrong though. I guess I never did try hiring and not actually get to hire. Maybe one of the other fields is status?

And thanks for fixing my post. I was in a hurry to go vote before work and missed that.

[trevius]

Ahh, that makes more sense. I didn't even think about it that way because the struct I have from April 2 2012 shows the following structure:

[OPCode: 0x6537] OP_MercenaryDataUpdate [Server->Client] [Size: 93]

00 00 00 00 - 0 - MercStatus
01 00 00 00 - 1 - MercCount
8f 01 00 00 - 399 - MercID
e4 66 ab 13 - 330000100 - MercType
09 b5 ab 13 - 330020105 - MercSubType
bb 00 00 00 - 187 - PurchaseCost
b2 00 00 00 - 178 - UpkeepCost
01 00 00 00 - 1 - Status
00 00 00 00 - 0 - AltCurrencyCost
01 00 00 00 - 1 - AltCurrencyUpkeep
13 00 00 00 - 19 - AltCurrencyType
00          - 0 - MercUnk01
a0 bb 0d 00 - 900000 - TimeLeft
05 00 00 00 - 5 - MerchantSlot
01 00 00 00 - 1 - MercUnk02
02 00 00 00 - 2 - StanceCount
88 d5 8b c3 - 3280721288  - MercUnk03
01          - 1 - MercUnk04
4b 65 6b 6c 65 6b 00 Keklek - MercName
00 00 00 00 - 0 - StanceIndex
01 00 00 00 - 1 - Stance
01 00 00 00 - 1 - StanceIndex
02 00 00 00 - 2 - Stance
01 00 00 00 - 1 - MercUnk05

Note the additional fields I saw are in green, and MercUnk03 also has some data in it in the VoA collect, where yours looks almost just like what they do when sent as a merchant list with no data in MercUnk03.

Maybe they used to use the same structs for merchant lists and the data updates, but changed that later in VoA since some things like the MercTypes list are unneeded.

Either way, at least both versions are in this thread as examples for that packet, which may help for comparison purposes.

[Secrets]

I can confirm that the OP_MercenaryDataUpdate packet that we have listed is not existent in any packet handlers for Seeds of Destruction. Not sure about underfoot but the opcode we have listed is not there at all.

[Secrets]

http://i.imgur.com/SYhg9.jpg

[Secrets]

Gonna be committing the next part of the merc stuff tonight; I got the packets in order and well, a quite nice result:

[bad_captain]

Great work, Secrets!

I took a few days off, but planned on getting back to it. I was planning on working on the database side, for getting the basic stats per level, class, proficiency, etc., naming rules, and anything else that's still needed.

A decision that still needs to be made is whether mercs use equipment (and weapons) or max & min hit values. The benefit of using weapons would seem to be less balancing that would need to be done in the database, since there wouldn't be records that would need to be updated per level, class, proficiency, and tier. That's quite a few records to have to change if melee attacks are under or over powered. On the other hand, if weapons are used, it could require more data elements that need to be edited to change the resulting damage.

As you said, much of the AI can be copied from bots and edited where needed. I'm sure the stance code for bots can be improved, but that could provide a start. I'm still working to get all spells used, and I know they differ based on the selected stance, so that data still needs to be captured completely. I think I can currently come up with basic spell sets for all of them, but more data is needed, especially for higher levels.

[Secrets]

Fairly certain on live mercs do not use weaponry, and instead have min/max values based on level. According to a few posts on ZAM, proficiency determines how many NPCs a merc can take on at once before feeling 'overwhelmed', an overwhelmed merc will fight but with a debuff. Not sure where the debuff is from or if it's a spell or anything. Tier determines the quality (dps output) of the mercenary.

Also, from limited testing on live, mercs seem to follow NPC stat rules more than PC stat rules. With the exception of HP, their damage seems more like that of an equal level NPC. For example, a level 50 mercenary deals around 151 points of damage and quad-attacks. This is close to being on par with a Plane of Justice sentinel, but with extra quad attacks. As for HP their HP is more so that of a player. They do not follow AA rules as far as I can tell, however, they have considerably more AC than a player would at that level. They seemed easily damaged by spell casters, so I assume they have very little resists.

I think the best way to do it would be min/max anyways; weapons do not make sense as mercenaries on live do not store items.

That only covers tank mercs, caster mercs are another animal entirely but from my testing they follow PC spell rules in general but only basic functionality; ie, heals, hots, very minor buffs (no resist buffs. hp/ac only), and cures. I didn't play live when caster (ranged dps) mercs were implemented so I cannot comment on them.

Due to the 'era' of what PEQ is in, If they were added on PEQ they would severely imbalance gameplay unless tweaked. The level 68 mercenaries were doing 768 damage quad (!) and that's a bit absurd for PEQ's DPS output at the moment.

Perhaps PEQ can increase the quality of mercenaries per expansion. They should always match the quality of NPC that is in the next expansion, for general rule of thumb. This is why SOE does level cap increases with most expansions; so they can balance out mercenaries and do a gear reset.

[Robregen]

Due to the 'era' of what PEQ is in

could probably add in an optional rule to allow mercenary or what's not.

[trevius]

Originally Posted by Robregen

could probably add in an optional rule to allow mercenary or what's not.

I believe PEQ has optional SQL that enables the Mercenary Merchants in PoK (at least). If someone doesn't want to use mercs, they just don't run that SQL. I know it changes the NPC names, but I am not certain if it changes their class to be Merc Merchant class or not. If it does change the class, then it should be fairly simple for servers to decide to use mercs or not by enabling the merchants or not. For anyone using Live collects (such as the ones Robregen has done), people would manually have to change all other zones with merc merchants like Crescent Reach or other newbie zones that might have them.

A rule would probably be fine, but I think the simplest rule would be to just have it disable the merchants. If it doesn't send class 71, then they can't get the mercenaries. We could probably add a rule to the fill spawn struct function to change class 71 to class 1 or something instead if mercs are disabled.

And yeah, from what I have read, confidence only effects how many NPCs they can have on their hate list before they start fleeing. There were some interesting posts on ZAMs about people finding ways around having their mercs flee when multiples were attacking. It probably wouldn't be too hard to copy that mechanic based on the info provided, but to me that sounds like implementing an exploit from Live just to try to copy it exactly.

I agree with Secrets that Live probably uses min/max for Mercs as well as stats instead of equiping armor. There is really no need to have them equip actual items unless they were going to allow those items to be changed out by players. Otherwise, it is just a waste of DB space for them and more DB hits than would be required without them.

I know there was a time when anytime you saw an NPC with a weapon, they actually had that weapon in their inventory. I am not sure exactly when that changed, but I am positive they don't do that all of the time anymore. I know at least by TBS they had started just sending weapon models with wearchange packets for NPCs that didn't actually wield the weapon they showed. I know this because I remember seeing an NPC in Stonehive with a weapon that wasn't on its corpse after I killed it (and wasn't something that is included with that NPC model). They probably changed that to be more flexible and maybe to mess with ShowEQ users as well, since I know people used to look for NPCs with weapons equipped so they knew which ones to go after.

BTW, awesome work so far, Secrets! Hopefully we will be ready to merge with the trunk soon.