Being able to give mercs equipment would help with that, but I think even if mercs have equipment, allowing equipment trades would be a low priority.

I'm more concerned about having to have a record for every level for mercs, for each proficiency, for each tier, for each class. That would be 4 classes, 3 proficiencies including master, 5 tiers, and however many levels each server allows.

Maybe there can just be a tier modifier for each proficiency, with records for certain level ranges. I.E for levels 1-50, you have one record with stats that would max at level 50. In the code, it would scale the stats based on level. Then, another record for lvls 51-65, and so on. That way you could scale based on level, while giving the opportunity to change some parameters at certain levels.

I currently have skills being set to the max for their level based on their class, but I guess that could be put in the database as well.

I think skills being max for their level is fine. It wouldn't hurt to have the option to be able to set it in the DB, but that shouldn't be something to really worry about at this point.

I think the best way to handle stats would probably just be to do it the long way by having each merc class/proficiency/level in the DB. Even for a server with max level of 80, that is only like 960 entries, which isn't huge in terms of db entries. Most of that could be written, adjusted, and scaled by simple queries fairly quickly using similar formulas to what might be used if we had scaling hard set in the source.

I am sure it could be done by setting a base and then having fields for scaling each field by X amount for levels Y+ or whatever, but having the individual entries allows for the most flexibility by far and shouldn't be too hard to manage.

As far as the upkeep cost packets go, the first one was definitely just an OP_MoneyUpdate, which I broke down here:

My guess is that the 45 Plat and change is how much you had on your char after the charge happened. You probably started with 46 Plat 9 gold 6 silver and 5 copper, or something like that before the charge.

So, the charging for mercs should be very simple and is no different than how we already do money updates for just about everything else.

I am not 100% sure about the second packet. Your collect is from a time-frame that I don't have a good opcode reference for, so without the full collect and other merc packet examples, I am not able to verify for sure which packet that is. Since it is 4 bytes and is definitely around the merc related opcodes, I assume it is what we currently refer to as OP_MercenaryHire.

My guess is that ResponseType 10 is just a server response saying you get to keep your merc :) If that is the case, then there is probably another ResponseType for dismissing mercs as well, but we will need to figure out what that is either via collects or by testing with sending different ResponseTypes from 0 to 10 (or so). It could also be that there is a separate packet/opcode for dealing with dismisses or whatever that upkeep packet is, but I would need a more complete collect example to be able to tell for sure.

While that would be a nice concept to implement for custom servers, that is not how mercs work on live. It is more important to make sure the design will make them work as they do on live, and then keep/add room for customization where possible for non-legit servers.

Which is exactly what I was trying to convey (even if it didn't come out that way). Thanks.

I completely forgot about the money update packet and how it works. I'll see if I can get that MercHire packet to work. I think you are correct, since when upkeep is charged, a check is made to make sure there is enough money to keep the merc. Otherwise, the merc is dismissed. It also sends the message that you have been charged upkeep, but I wasn't sure if it was just a message packet or not.

For stats, I can see a benefit both ways. If rules were used, it would be much simpler to modify stats off of a few base merc records (still have per level, class, at least, probably proficiency as well.). But, you missed tier, so multiply that total by 5. Besides HP, Mana and Maxhit(if used), I'm not sure many stats will have that big of an impact, at least less than skill or spells and their focuses.

I guess for now I'll leave stats how I have them so I can work on other things. I just have base stats, then item, spell, and aa bonuses (which we could rename merc bonuses and would be based on proficiency and tier) . Then we can set the base stats to whatever we decide. I am under the assumption we will be using max and min hits instead of calculating them from weapons. This way, some combat code can be worked on.

FYI, I haven't given up on doing Merc work. I am just taking a bit of a break before working on more of it. I started reading this "Thinking in C++" book to give me a better understanding of coding before picking back up on it. About halfway done with the book so far. It is a good learning experience and is filling in details for stuff I am familiar with from reading the source, but never really fully understood in depth. Up to this point, almost everything I have learned about coding has been from examples in the EQEmu source. So, it will be nice to understand everything a bit better before picking up on more coding (about time, right?) :)

Hopefully I can finish the book up this week and start back into working on more stuff. The winter is normally a good time for coding anyway, since there are less things to do outside and around the house so there is more free-time for dev work.

By Bruce Eckel?

Yep, that is the one. Seems pretty good so far for a free one. It assumes the reader is a C programmer, so it isn't really for beginners or anything, but it covers stuff pretty well either way if you have the basic idea of what is going on. Sorry, not trying to derail this thread :)

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:

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

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

Another message I get is:

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.

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.

you can get cavedude precompiled Version here https://code.google.com/p/projecteqd...e.zip&can=2&q=

says it is an unsupported client version:
keep your opcode files in format of patch_Oct16-2012.Conf
make sure you have a file with the same name as patch_oct16-2012.CS in the same directory.
so you might have to copy and rename *.cs files to match your *.conf file name
if you keep having the same problem download wireshark Version 1.8.2

that is the reason you are receiving unspported client version.

0x3401 was Op_NewZone in VoA it was changed in Oct 2012
OP_NewZone=0x0d60 # 0x3401

I have no idea what the 30 (48 in decimal) means:
30 means End if satement or else sub, or if clause
48 means EOF means end of file.

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.

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.

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.