Quote:
Originally Posted by bad_captain
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.