Mercenaries

[bad_captain]

I just committed some work I've done on mercs. Suspend is mostly working, basic stats are in (#showstats shows the stats we give the merc).

I had the 15 minute timer working at one point, but broke it again, so I need to figure out what happened with that. When the timer was working, I was being charged the upkeep, although the message stating the amount charged was incorrect.

I believe that suspend mostly works, but am unable to test unsuspend, because for some reason, no matter what I send in for suspended time in the suspend response packet, I get either 0 time remaining or 400+ hrs remaining. I'm not going to wait that long. There may be a mixup somewhere with the opcodes, because I get the following message:

[11.01. - 00:01:12] [WORLD__CLIENT_ERR] bad_captain: Received unknown EQApplicationPacket
[11.01. - 00:01:12] [WORLD__CLIENT_ERR] [OpCode OP_MercenaryTimerRequest (0x0924) Size=1]
[11.01. - 00:01:12] [WORLD__CLIENT_ERR] 0000: 30

I don't think the timer is being handled correctly, if at all. I don't get the

Message(7, "Mercenary Debug: Timer Request received.");

message at all, even when I got the 15 minute timer to work.

Another message I get is:

[11.01. - 00:01:18] [WORLD__CLIENT_ERR] bad_captain: Received unknown EQApplicationPacket
[11.01. - 00:01:18] [WORLD__CLIENT_ERR] [OpCode OP_Unknown (0x3401) Size=0]

I'm not sure if that is a relevant opcode or not. I'm using SoD.

Anyway, I just wanted to get the work out there, and hope to look further into the issues I'm having.


Somewhat unrelated, but affecting my debugging of some of these issues, is my inability to get EqExtractor to work for me. It works for captures I did at the end of last year using SoD, as well as ones I did earlier this year on live (in Feb). Now, any capture I do says it is an unsupported client version. I also get an error on the OP_DzChooseZone opcode, as it had a total length of 5, instead of six. I'm wondering if my SoD.conf file is messed up, but even using the default one from the trunk causes the issue. If anyone has any advice, I'd appreciate it. It would certainly help me figure out what's happening with some of these packets being sent and received.

[trevius]

Yeah, I noticed the 1 byte sized packet for Dismiss on SoD and UF as well, but in my collects from VoA, they are 0 bytes. I am guessing that the case is the same for the Timer Request packet, assuming that is what the packet is for. I am not 100% sure the opcodes are correct for those on SoD and UF compared to what I have for VoA, but the order looks correct as far as I can tell so it should be.

I think we could probably just change the size check to see if it is > 1 instead of != 0 for the Timer Request, which is what I set already for the dismiss request. I have no idea what the 30 (48 in decimal) means, but that is the same thing I was seeing in the dismiss packets in SoD and UF. It may be that the client is sending that because of some mistake elsewhere in the data we are sending in other packets, but that is just a guess at best.

The Unknown 0x3401 opcode is most likely not merc related. I don't see the equivalent opcode being sent in my merc collects for VoA. Also, it is near most of the earlier opcodes, and merc opcodes are much later and all near each other in the order, so it is probably for something else like deleting spawns or something.

Maybe I can get some time to mess with the suspend timer stuff and see if I can get that working.

I haven't messed with the code for it at all yet, but I could probably look into getting the extractor working for Live, and maybe SoD if that is an issue and is needed. Unfortunately, I kinda suck at reading packets that haven't been dumped, cause I don't know the packet header stuff too well yet. I am sure I could figure it out though. I think the collector only requires a minimum amount of correct opcodes and structures to function, so it shouldn't be too hard to get that working. I think one of the main things is to make sure the PP packet struct is correct size. I really don't know why it would error out on any DZ packet sizes, as that seems to be completely irrelevant to identifying client version unless Derision changed the extractor to use that packet for identifying the client instead of the one we use for EQEmu. It would probably take a bit for me to familiarize myself with the code for the extractor, but it would be good stuff to know anyway. I am sure Derision would appreciate help with maintaining it so he isn't the only one doing it.