While I like the idea of percentage based control over mercs I do think a rule should be in place to allow for complete disabling of the mercs. Not all servers will want the bots/mercs because of potential balance and/or performance issues. How about stick with the percentage idea but make 0% completely disable the mercs.

bots != mercs ever.

Mercs will always be active in code (once implemented) as that is the correct matching live route that EQEmu has taken. If you do not want them, do not add a merchant offering them, that is the customization route that EQEmu has taken.

another thing to consider is SoD+ clients are not available to purchase or download from stream at this time. Probably the majority of players use Titanium across most server. Unless someone wants to keep up with Live client to make it playable with emu to make use of mercenaries.

The way it is currently in the database (and handled by the server), is that it will not send the data to the client if they do not match the correct client version. So, if a client is using titanium, it won't send any data to it (and it wouldn't be able to handle it anyway).

If the majority of users use titanium, then they have the ability to use bots, if the server allows it, of course.

I guess we just have to hope that they put another version of EQ on steam or somewhere else for purchase.

Secrets said, Fairly certain on live mercs do not use weaponry, Problem has been solved they do now 80)

I don't think that is the case anymore. I think TFH is about 50% SoD+ clients, and EZ is probably 90% or more now. I don't know offhand what the numbers are for PEQ, but they are probably 50% or so as well for SoD+ clients. Most people run the UF client these days. Even though Titanium and SoF are the only legally available clients, they are still fairly hard to come across and most people don't bother trying to find them. The majority of clients attained these days are probably from illegal downloads. It is unfortunate there isn't a better option at this time, but it is what it is. At least most people who would want SoD or UF could probably get them if they really wanted to so they can use mercs and such.

Hopefully at some point in the future we will have a legal route for clients again that isn't so hard to locate and purchase (especially considering international players).

Sounds like Noport tried the MercsAndBots branch and saw that they are wielding weapons (which they always have on the branch). I guess he thinks that means we figured out the solution to the Mercs equiping weapons discussion in this thread. That is my interpretation anyway. Problem solved!

I've stuck this since it's currently active.

Also yeah the client thing is becoming an issue. I think realistically we're going to have to have a discussion about actually creating our own client sooner or later.

Thats going to be an interesting discussion considering the current stance on torrents. At least with torrents, there is wiggle room as if you bought something and lost the CDs you are kind of entitled to that data still, however its much more cut and dry when you are talking about ripping out the intellectual property(models, textures, zones, etc) and using them in your own product.

It's not really anything new, game recreations requiring original installs have been around for a long time. Regardless this isn't the place.

Just an update, moved mercs to NPC derived, gonna be a lot of bugs/un-implemented things that were bandaided before, such as merc death, merc zoning, etc.

Group joining/states will also be a pain to work with, from my limited testing.

Committing what I did tonight though

Did this commit go in? The last rev I see is 2255 from Nov 11th.

The sooner we can get this on the Trunk, the better, I think. I know Akka has a big change ready to go that might be a bit of a pain to get merged into the branch.

Inheriting mercs from NPCs will likely require quite a bit of work and testing to get the kinks all knocked out. It does make sense since technically mercs are NPCs. It would probably require a lot more duplicated code leaving mercs as their own class under mob. I kinda liked the idea of mercs being directly under mob, but hopefully having them under NPCs can be worked out before too long if we stick with using that route. I think having them as their own class directly under mob would probably allow for a cleaner and more flexible solution (even with duplicated code).

That why I created them under mob, but with stats being handled more like NPCs, I can see why it might work.

I have been working on getting stats in the database. I'm looking through my logs while writing a script to generate the stats and insert statements. I'm getting close to having something usable that can be tweaked, but I have little data for mercs > level 65, besides just DPS numbers ( no max hits, etc). If anyone has any readily available, I'd appreciate it.

Been terribly busy, sorry :x am fixing up my local source, then I'll commit it tonight.

edit: just committed it.

Just an inquiry, can we use the scalerate field in NPC_types and keep them in their own range?

That seems like it would make the most sense, people are more than capable of doing an update query by ID, and we can keep templates somewhat modular that way.

Thoughts?

I'm not sure what you mean 'in their own range'? I think it's been agreed that keeping mercs in a separate table from npc_types makes the most sense, if that's what you mean. KLS commented on that earlier.

Keep in mind, we need to include spell damage modifiers (per spell type, as I believe HoT spells aren't affected), as well as melee skills or discs, which don't conform to the npc_types table.

I agree some kind of scaling feature would be nice, but I also think allowing for complete customization has its benefits as well. I may have come over to Trevius' thinking in that respect. I'm not sure some aspects match a specific scaling rate, as looking at maxhit from lvl 1-60 does not seem to follow any particular equation, or any set of equations. I'm sure the same can be said of spell damage modifiers, etc. This also allows customization shown in live pets, where one particular pet focused with a particular focus has extreme regen - a bug I'm sure, but created some differentiation. SOmething similar could be done with something like the mercenary contracts, where obtaining a contract and hiring your mercenary that way results in a superior merc than what is available from the merchant, at the same proficiency and tier.

What I had planned to do was basically split the npc_types table in two and pull out any unneeded fields, and end up with a stats table (hp, mana, str, sta, resists, regen, etc for each level of a particular proficiency and tier), a texture table (to store visible textures and tints- weapons seem to change every 5 levels, and armor maybe every 20 or so?) - no need to duplicate the textures for every level. Then, one more table for the spell & skill mods (instant heal mods, nuke mods, buff duration mods if any, etc.).

I think the npc_types_tint table could be re-used for mercs as well. We would just need to add texture/model fields for each slot. It would be good to have that option for NPCs as well anyway, so you could have different textures for each slot if you wanted (plate chest, chain legs, etc). Then you would just assign a tint set ID to the merc and it would give the appropriate look.

I haven't tried the RoF beta yet (and don't plan to), but I hear that mercs may now have a new UI window that lets you at least view the equipment they are using. I don't have much detail on the subject, but if this is true, it would confirm that mercs do in fact equip gear. If no one can confirm now, we may have to wait until it goes live to be sure. Mercs equiping items could be something new to Live (assuming the info is true), or they may have done it all along.

Either way, even if it is true that Mercs can use gear, that is something that could always be added in later. Just like NPCs can use gear or not. It can factor into their combat, but not on the same scale as it does for player characters.

It is very possible that the casting bonuses and such come directly from focus effects on worn items. Though, it would be nice to have the option to change those values directly via a table like bad_captain mentioned.

As mentioned, a scaling option would be good if it could be worked out properly, but I think it would be pretty hard to really properly scale more than a few levels at a time. There may still be a good way to consolidate the large number of DB updates that would be required otherwise, though. We may be able to split stats out into a couple more tables and assign IDs from those stat tables to individual merc templates. There are probably different stats that overlap between different merc types. Maybe all tiers use the same STR/STA/INT/WIS/AGI/DEX/CHA and Resist values for each respective level of the merc, but they use different min/max and hp/mana/AC values. We could have one table that deals with stats and resists, then another that deals with min/max damage and hp/mana/AC, or whatever. It may take some analysis and thought to see if this approach would be worth-while, but if it can consolidate the amount of entries considerably, it could be worth it. Just kinda thinking out loud here, heh.

Trev these were found on a Merc FAQ I was looking at

Q: Can I give my mercenary weapons and armor similar to a pet?

A: No. your mercenary comes equipped with the armor and weapons he needs. Also his armor and weapons will get better as he levels up.

source http://almarsguides.com/eq/general/mercenaries.cfm


Can I give the mercenary gear?
No, you cannot gear the mercenaries or hand them any thing at all.

Source : http://www.necrotalk.com/showthread.php?t=9993

So it may be that in ROF giving them equipment is new..But looks like atm you cannot and their gear scales accordingly with preset sets of Gear based on level.

Ya, but the information may not be accurate in those FAQs. They say that mercs come with their own gear, but they don't know for sure if that means they actually have a full set of equiped items (inventory) or if they are just simulating a set of gear by sending texture and wearchange packets and adjusting NPC stats accordingly to scale. Considering that all of the mercs I have seen in the past only wore armor with no tint, that makes me lean toward them just sending a texture change. If they were using actual gear, why not use existing gear sets made for players (which would have a tint applied)? Of course, they could also send a tint to simulate that as well, which we already have an option for in the emu.

I have not looked into the MQ2 source for their spawn searches but found this over on their forums

I'm tempted to just go ahead and add in equipment, as it won't be that much work (minus weapons), and it will affect the stats used as base stats (what I'm working on now & they would need to be significantly adjusted later if equipment we added). Not only that, but secondary stats such as spellshield, healing amount, etc would need to be addressed. Equipment allows mercs to have those stats without having to give them the stats initially. Plus, it allows for a lot of possible customization.

I would be curious to see just what equipment they do use on live, if any. I know it was odd to see my tank merc alternate between weapon types, using 1hs, 1hp, and hand-to-hand weapons at lower levels.

Also, not sure about this, but just because a merc is 'wearing' a piece of equipment doesn't necessarily mean it has to use that texture, right? They could use the equipment for stats, but display what we specify, correct?

FYI, the info quoted above is false.

And, Noport, mercs have always displayed weapons and armor like you show in that pic. That is nothing new. It doesn't mean that they actually equip any of the items they are displaying, it could just be (and most likely is) for display only.

That is correct. We can send texture changes, or wearchanges to make any NPC appear to wear/wield whatever we want, no matter what their inventory actually is (or isn't). Keep in mind that there is 1 extra step that has to be taken to make different weapon type changes work as needed; we have to also change the attack message to match the weapon model (slashes, crushes, etc). NPCs already support this type of change in fields of the npc_types table.

i'll say this Trevius is correct there is nothing new. my mercenary hits for 2k a swing not counting crits. this is what you get when you receive your mercenary this is a tier V mercenary. the mercemary ui looks just like what Secrets posted (just for display only).

I think its fairly obvious that mercenaries wear opcodes.

I think if we make sure all servers can continue to run without mercs after getting latest, it should be able to be merged now. And for that to happen, we just need a simple script to change the 9 mercenary liaisons (class_id 71) to guards or whatever, then we should be good to go. (I have 9, stock peq may have fewer- I can't remember if I've added any mercenary liaisons)

We still need the scripts to change all of the current PoK guards into mercenary liaisons, but that shouldn't be too much work. I have a bunch of collects, so I think I'd just need to create the scripts and test it all out. This would then be added to the current mercs.sql to fully enable mercs on servers who want them.

Could you not add a rule that just makes them not respond?

Would probably be the best way to do it. I just got a job irl (shocking i know) so i'll have less time to work on this but i'll see about doing that.

You really really aren't going to want to merge all of my changes manually, so give me an idea of when this is going to happen.

Yeah, not sure what I was thinking. I guess that's what I get for posting so late. A rule would be best. I would say sometime this weekend, Akkadius.

Secrets, I took a look at your code and have a question. Why did you put the merc_npc_type_id in the merc_types table instead of putting the merc_type_id, merc_template_id, or something else within merc_npc_types to designate what it belongs to?

Because the stats aren't dependent on race, the table I created for holding merc stats had the class, proficiency, tier, and level to designate which record to use. Unless I'm missing something, I'm not sure how to get a specific record within the merc_npc_types table, although I guess id isn't auto_incremented, so I guess you could reuse the id multiple times. But, again, the stats aren't race dependent (I guess the appearance fields may be; although they are actually randomly generated on hire and may not be necessary to have in the table. They aren't level dependent anyway so it may be best to put that stuff in another table to avoid duplication). Plus, having to update the merc_types table with an arbitrary id from another table after the data has been generated, will most likely be tedious, and to me, harder to maintain.

If we add in trevius' suggestion to use the npc tints table (or at least a copy of it for mercs), it may be best to pull out the textures and tints to another table, especially since they will not be changing every level (I don't think armor changed but every 10-20 levels, where weapons changed every 5). I haven't done this in my example, but could easily be done.

Also, some of the fields in npc_types aren't relevant to mercs, and could most likely be removed.

Just for reference, here's how I had it broken down (I could easily remove the id and just use class, proficiency, tier, and level as the primary key - I just prefer one field for the key that is not dependent on any other field or in any way related to the actual data):

Any thoughts, or am I thinking too deeply about avoiding duplicate data within the table? I'm mostly just trying to keep it as easy as possible for admins to manage, as well as us if we need to make tweaks (which we will).

Also, is the purpose of the client_level just so we can have mercs not have the same level as clients if admins want to?

The purpose of client_level is to assign an appropriate template for the client's level. For example, let's say a merc template is an erudite paladin and the client is 66. The two key system works like this:

merc_npc_type ID 644, level 66: We get the stats, appearance (some mercs have weapon changes and/or texture changes on specific pieces of gear at specific levels) of merc type 644. We duplicate the race/class appearance currently in the table and that can be changed. What is not duplicated however is the stats, weapon appearance, and any other npc-specific fields.

If the client is 65, and the merc_npc_type ID is 644, we get ID 644-65 instead. This allows us to fine-tune npcs by ranges at the expense of more database entries. Keep in mind we're not loading this entire table, only specific NPCs as they are referenced just like the npc_types table, so it is highly memory efficient as well.

What is loaded, however, is the entire list of templates. We reference a specific template, which references a specific merc_npc_type_id. When it comes time to actually getting the template, we have to pass the client's level to the equation in getting the absolute proper merc_npc_type_id

This allows us to fine-tune a merc_npc_type to a specific level. For example, from 65 to 66 on live, I believe there's a rather large gap in power. A simple scaling template will not be plausible in that scenario. Also, npc weapons vary depending on level. I suppose we could template that as well, not sure.

The class/race IDs are still there in the templates table right now for determining stances. No other purpose is what I intended... might be bugging out atm though. Just for live-collected data purposes.

I suppose we could have appearance in its own table and assign each merc_npc_type an entry, but that seems like it would overcomplicate things by adding another table.

Is there any difference between client_level and level in merc_npc_types? Since the merc is supposed to be the same level as the client, couldn't you just go by level? It's not a big deal, just curious.

Also, I don't think having the merc_npc_type_id in the merc_types table will work. There will by many merc_npc_types for every merc_type. Merc Types are what show up in the dropdown of the mercenary purchase window. It only relies on the race and proficiency (apprentice or journeyman). Subtypes include the class & tier. The merc_npc_types table will also depend on the merc_subtypes, since there will be different stats for different classes & tiers. You could put it in merc_templates, but because the stats really don't depend on race, you would have to duplicate the merc_npc_type_id for each record in merc_templates with the same class, proficiency & tier. That's why I just included the class, proficiency & tier in my stats table, but it could be done in merc_templates as well.

I just want to make sure I understand your logic before putting the stats in, since it will be harder to change once it's merged into the trunk and people start playing around with them.

Could do it by level, I just wanted to have the opportunity for different merc levels than what the client is actually having for custom server purposes. For example, a merc might be level 44 for a level 50 character, 45 for a 51, etc, in a custom scenario anyways.

I wanted to leave it open-ended enough that PEQ and other servers that need the merc to be more modular can use it in their own way without having to change too much.

Currently the class/race is set from the merc's template, not the merc_npc_types table. If you would like to trim that merc_npc_types table of duplicate entries be my guest.

Made a ton of progress tonight. Mercs now save groups across zone, they now show up as 'in the zone' on the group window. They do not save health or any buffs across zones yet. I'd say the basic functionality works great so far.

Gonna commit it later tonight after I fix it up a bit. Perhaps we can start moving it into the main branch? It seems 'ready' so to speak. I'd like to see about PEQ trying to break them when I commit it to SVN and we have PEQ's database updated.

Picture of the mercs in groups. When one merc is removed, they get suspended. Not sure if that's how live intended mercs, but it seems 'better' imho.

When the leader is removed, the merc gets added to a new group with the person who got kicked.

Currently, you have to unsuspend your merc once you are in a group. Perhaps support for pending invites from players both merc grouped could be added later.

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

Updated mercs last night. It includes a significant database update, and mercs.sql will need to be re-run for it all to work. There were really too many to create an update, so just source in mercs.sql again. The only other thing needed from secret's update 2 is adding ismerc to the one group table.

There are now merc stats for up to level 85. Up to 65 should be reasonably close, but more data is needed after that. Once mercs are able to act in combat, a better approximation can be made on some stats. Hp, mana, and maxhit would be the three most important to update post 65. We may need to add in the advanced stats, or add in equipment (I've read a few rumors of mercs having cloaks or something similar to pets (which are equipped based on pet power), and include the advanced stats. Depending on how well mercs perform in battle may help decide how to approach this.

Armor and weapon textures are set from the database. Currently, there's a record per proficiency/tier/class combination (check out reference table, merc_npc_types). Melee mercs have two records, one prior to dual wield, and one after. Healers and casters have one record only. This should suffice until more important work is accomplished. Weapon textures set from db is used instead of the previously hard coded values.

Mercs level with you- they will update stats when you level, but will con dark blue until you zone/suspend/etc.

Note: merchants are given the merc data if they should, but the npcs still need to be updated for correct placement, race, gender, etc. Two vendors that work are Mjdai in crescent reach tent, and guardian norerd in pok, who is at the top of the bridge by the soulbinder.

Two bugs I've noticed: after zoning, suspending/unsuspending, my merc no longer follows me ( code appears to be there to set the correct followID), and after dismissing a mercs, then rehiring, the second merc doesn't have stance data in merc window.

I will try to update my earlier post concerning what still needs to be accomplished for mercs tonight. I will be testing out the bugs listed earlier, and work on getting mercs into combat. I will need some more data on spell lists for healers and dps casters. I will focus on melee mercs first.

I also merged in everything from the trunk, so if everything checks out, it should be able to be merged into the trunk. A sql update would need to be added for the merc rules that have been added into the source. I can try to add that this weekend as well.

I committed mercs to the trunk.

I split out the sql into 4 files which need to be sourced for mercs to work correctly:

OPTIONAL SQL: utils/sql/svn/2380_optional_merc_rules.sql
OPTIONAL SQL: utils/sql/svn/2380_optional_merc_merchant_npctypes_update.sql
OPTIONAL SQL: utils/sql/svn/2380_optional_merc_data.sql
OPTIONAL SQL: utils/sql/svn/mercs.sql

Splitting it up was done to keep rules separate from the data, and some servers may not need to update the PoK merc merchant spawns. The merc data that should not change much if at all is in the merc_data.sql, while merc stats, textures, and eventually spells & discs will be put into mercs.sql. This way, whenever changes are made to merc stats or spell casting AI is finalized, you will only need to source mercs.sql instead of the whole thing.

Included in the commit is basic merc functionality for melee (tank) mercs. Healing & Caster DPS mercs do not have spell lists or spell casting AI yet. I currently compiling spell lists for them, and I am adding the AI for the next commit.

Mercs do not currently charge you for being purchased or upkeep (the code just need to be uncommented), but until they are more functional, I would keep it commented out. I think a rule could be added as come servers may not want to be charged anway, but for now, I just have it commented out.

Current bugs I will be working on are the merc timer and stance bugs. SOmetimes, stances fail to show up (rarely) when hiring a merc, and sometimes (often the same time), the merc timer doesn't function. This will be addressed before players are charged for mercs.

I will update my earlier post about the current state of mercs and what still needs to be accomplished, but for now, I wanted to state that you can at least play around with them. They should group with you, attack when you get aggro, level with you, and increase in power as you level.

I'm still looking for post 65 data for mercs as far as HP, max hit, spells lists, etc. Just include class, proficiency, tier, and level please.

The newb merc you get in me tutorial on live has no purchase cost or upkeep cost. So the base merc code should account for a merc with no costs.

I haven't look at the tutorial yet. If the player is below level 10, there shouldn't be a cost or upkeep. Is the merc from a merchant in the tutorial zone? I think if we add data to their merchant list, it should show up as being 0. If nothing is sent to them, it reads as 123p or something. I still need to get spawn data for merc merchants in starting cities, then I can finalize the merc merchant stuff. PoK should be done, and I know the one in Crescent Reach works.