Mercenaries

[bad_captain]

For eqextractor, I think it only needs the size of the pp. I don't think it ever gets there, maybe because of the other issue. When it checks the opcodes, it converts the opcodes to number, with playerprofile being like 245 or whatever. It loops through the opcodes to convert and at that point, it errors because of the Dz opcode. If I make the length 6 by adding a zero at the end (length is the number of characters in the opcode, not packet size. i.e. it's 0x0d6 instead of 0x0d60), it loads, but still doesn't find the correct sized pp. I added a conditional breakpoint to stop when it reached 245 or whatever the player profile one is and it never stopped. I might just use 0x0000 for the one it errors on in case the incorrect opcode causes some other error, then step through manually until I reach the player profile and see why it's not matching the size. It's just strange that it works correctly for collects from last year, but not now. Maybe something is messing up my packets. Who knows.

I'll try the size 1 timer packet and see if that helps.

For the suspend response packet, if I send the time suspended using timer::getcurrenttime, I get 400+ hrs remaining. If I send 30000 (5 minutes), I get the same. If I send the current time + 5 minutes ( in case it's actually when they are available to be unsuspended), I get 0 min 0 sec remaining. This one has me confused for sure. I haven't checked the encoding yet. Maybe there's something there.

[trevius]

Originally Posted by bad_captain

This one has me confused for sure. I haven't checked the encoding yet. Maybe there's something there.

Right now, the only encoding is for OP_MercenaryDataResponse and OP_MercenaryDataUpdate. The rest of the packets seem to not need encodes/decodes so far to my knowledge. There may need to be more encodes/decodes added, but most of the other packets are pretty small and simple, so it is less likely they will need them. It is hard for me to tell for sure without good collects from Live for each client.

[Secrets]

It's a UNIX timestamp that it uses for mercenary timers. I'm not sure what value Timer::GetCurrentTime returns, but time_t's value should work fine.

PS: I'll be helping with mercenaries soon. I had a lot of experience with the packets before I went crazy. I also have been reverse engineering other games' file formats so I learned a LOT about IDA and game design in general as a result.

I have to get my development environment set up again. Been a while.

[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.
*/

[Secrets]

So, the assign packet.

It's actually a 16-byte packet that does different things depending on variable size.

I had a screenshot from when I last worked on it. Basically, there's a few fields, and you were right about the unhire struct being the same as the assign struct:

struct MercenaryAssign_Struct {
/*0000*/ int32 MercEntityID; // Seen 0 (no merc spawned) or 615843841 and 22779137
/*0004*/ int32 MercState; // Seen 0 with no merc hired
/*0008*/ int32 MercSuspended; // Seen 1 when no merc is hired - ID unique to each type of mercenary
/*0012*/ int32 MercTimeRemaining; //UNIX Timestamp. The reason the client accepts this part of the packet missing is because SOE stupidly left no size checks. //I assume they wanted it in another packet but never removed it?
/*0016*/
};

I'm not actually sure if MercSuspended is the suspend state of the merc, it could be a list of stances from the client. It might not be. I'm not sure, I haven't observed the packet.

It's also possible the suspended state is a value from 0-4 depending on if the merc is suspended, active, dismissed or two other states? not sure.

Another thing it could be is that I have the initial hire packet and the assign packet screwed up, which would explain the merctimeremaining part being missing.

I forget what values these were but it *was* working at some point: