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.