Rule Request Character:MaxLevelSkillCap

[trevius]

This is a request for a rule to allow the server to report skills properly for players that are above the max level. If a rule can't be made for this, I would appreciate help in finding the source that needs to be changed to allow it.

From my testing, if you #level a character over the max level defined on the server, the skills will then wrap around back to 0. This is just a graphical bug, because the skills all still work and skill up properly. They just show up in the skill window as wrong. Also, this effects stats such as AC and Attack heavily, but again this is just graphically. Using #showstats will still report the stats properly.

I am not exactly sure why it wraps the skills. I don't even see a reason for it to be in the code at all, but it would be nice to have an option to turn it off. I do know that if I turn #gm on, the false skill caps disappear after a few seconds and skills appear normal. I just need a way for it to display the correct skills even if a player is over the cap set on the server. The rule option could either be setting the max level for skills to show up properly, or it could be as simple as a true/false setting to turn the wrapping on or off.

This would be primarily for servers that want to increase the max attainable level of their server, but by non-traditional means. On my server, I have added a new custom quest that allows players to level from 70 all of the way up to 75 one level at a time. This is done by collecting from my top tier zone and turning them into a quest NPC that levels the character. I think it is a cool new way for me to reward my top end characters to make them stand out from the normal level 70s. It is also a way to allow players to progress onto even higher tiers to be added later that would otherwise be too hard for normal level 70 characters. By making level 75 only attainable via high end quest, it still keeps all of my current level 70 content perfectly balanced for new level 70 players. Also, since it is a quest, I can make it take longer than the normal exp grind from 70 to 75 and I can also make it more interesting by making raid encounters drop the quest items. Imagine raiding to level instead of just grinding. I like variety. I think once I get all of the bugs worked out, my players will really enjoy it.

[ChaosSlayer]

mmm, isn't skills are reported as 0 simply cause those values are not entered in DB for the level specified?
like max lev in DB is what 70? then skills prabobly end at 350, so for 71, a new row will have to be entered with some info, like 350+

These are pure speculations based on what I herd before....

[trevius]

Well, even if it did, my skill_caps table goes up to 75 for all classes anyway, so that isn't what is causing it. It happens as soon as my character exceeds the max level set for the server. Oddly enough, the skills don't correct themselves if I #level the character back down to 70 again. They don't show up normally again until the character is 65 or lower.

The skills seem to roll over no matter what value they are at. It still shows "master" for the skill, but the caps show up in red at 30 for a level 75 for most skills. Even if you setallskills to 31, they will still all show as capped at 30, but the caps aren't actually doing anything. So, it isn't the skills themselves that are rolling over if the go over the set limit. It is something with the Character:MaxLevel rule setting that causes the graphical glitch.

[trevius]

Now I am curious if the skills rolling over like this is because the Titanium client was made for max level of 70. I created a test server so I could do some testing with levels and spells, and I set the max level to 75 in the rules. When I logged in and #level 75 on a character, I see that their stats are still showing wrong in the char screen for AC and attack and the skills are still rolling over the same as well.

Does anyone who runs a server with levels over 71+ know if there is a way to correct this issue? I would really appreciate the info. I can't imagine that servers like KMRA with their level 87 max level would require players to use #showstats to see their real stats. I checked the forums of most server that have higher than level 70 caps and I didn't find any that referenced any stats issues or any use of #showstats.

Here are some code snippets from the EQEmu source that I thought might be related to the issue. I am not a coder, so I don't really know much about it.


client.cpp
bool Client::CanHaveSkill(SkillType skill_id) const {
return(database.GetSkillCap(GetClass(), skill_id, RuleI(Character, MaxLevel)) > 0);
//if you don't have it by max level, then odds are you never will?

int8 Client::SkillTrainLevel(SkillType skillid, int16 class_){
return(database.GetTrainLevel(class_, skillid, RuleI(Character, MaxLevel)));


client_process.cpp
SkillType sk;
for (sk = _1H_BLUNT; sk <= HIGHEST_SKILL; sk = (SkillType)(sk+1)) {
if(sk == TINKERING && GetRace() != GNOME) {
gmtrain->skills[sk] = 0; //Non gnomes can't tinker!
} else {
gmtrain->skills[sk] = GetMaxSkillAfterSpecializationRules(sk, MaxSkill(sk, GetClass(), RuleI(Character, MaxLevel)));
//this is the highest level that the trainer can train you to, this is enforced clientside so we can't just
//Set it to 1 with CanHaveSkill or you wont be able to train past 1.
}

features.h
//The Level Cap:
//#define LEVEL_CAP RuleI(Character, MaxLevel) //hard cap is 127
#define HARD_LEVEL_CAP 127

exp.cpp
int8 maxlevel = RuleI(Character, MaxLevel) + 1;

if(check_level > maxlevel) {
check_level = maxlevel;
set_exp = GetEXPForLevel(maxlevel);
}

if ((GetLevel() != check_level) && !(check_level >= maxlevel)) {
char val1[20]={0};
if (GetLevel() == check_level-1){
Message_StringID(15,GAIN_LEVEL,ConvertArray(check_ level,val1));
SendLevelAppearance();
//Message(15, "You have gained a level! Welcome to level %i!", check_level);
}
if (GetLevel() == check_level){
Message_StringID(15,LOSE_LEVEL,ConvertArray(check_ level,val1));
//Message(15, "You lost a level! You are now level %i!", check_level);
}
else
Message(15, "Welcome to level %i!", check_level);
SetLevel(check_level);
}

//If were at max level then stop gaining experience if we make it to the cap
if(GetLevel() == RuleI(Character, MaxLevel)){
int32 expneeded = GetEXPForLevel(RuleI(Character, MaxLevel) + 1);
if(set_exp > expneeded)
{
set_exp = expneeded;
}
}

void Group::SplitExp(uint32 exp, Mob* other) {
if( other->CastToNPC()->MerchantType != 0 ) // Ensure NPC isn't a merchant
return;

int i;
uint32 groupexp = exp;
int8 membercount = 0;
int8 maxlevel = 1;

for (i = 0; i < MAX_GROUP_MEMBERS; i++) {
if (members[i] != NULL) {
if(members[i]->GetLevel() > maxlevel)
maxlevel = members[i]->GetLevel();
//groupexp += exp/10;
groupexp += (uint32)(exp * zone->GetGroupEXPBonus());


int conlevel = Mob::GetLevelCon(maxlevel, other->GetLevel());
if(conlevel == CON_GREEN)
return; //no exp for greenies...


Also, my players reported that if they scribe their spells from the spell scriber and then memorize spells over their level and zone, the spells over their level in their spell book will vanish but the memmed ones stay there. I am guessing the code below is what causes that. I think it is because it referenced maxlevel and my players with the problem are over the maxlevel defined in my rules. The max level in the rules is set to 70, but I made a way to get to 75 via quests only.

client_packet.cpp
//Validity check for memorized
if(Admin() < minStatusToHaveInvalidSpells) {
for (uint32 mem = 0; mem < MAX_PP_MEMSPELL; mem++)
{
if (m_pp.mem_spells[mem] < 1 || m_pp.mem_spells[mem] >= (unsigned int)SPDAT_RECORDS || spells[m_pp.mem_spells[mem]].classes[GetClass()-1] < 1 || spells[m_pp.mem_spells[mem]].classes[GetClass()-1] > GetLevel())
m_pp.mem_spells[mem] = SPELLBOOK_UNKNOWN;
}
int maxlvl = RuleI(Character, MaxLevel);
for (uint32 bk = 0; bk < MAX_PP_SPELLBOOK; bk++)
{
if (m_pp.spell_book[bk] < 1
|| m_pp.spell_book[bk] >= (unsigned int)SPDAT_RECORDS
|| spells[m_pp.spell_book[bk]].classes[GetClass()-1] < 1
|| spells[m_pp.spell_book[bk]].classes[GetClass()-1] > maxlvl)
m_pp.spell_book[bk] = SPELLBOOK_UNKNOWN;

//I believe these effects are stripped off because if they
//are not, they result in permanent effects on the player
for (uint32 j1=0; j1 < BUFF_COUNT; j1++) {
if (buffs[j1].spellid <= (int32)SPDAT_RECORDS) {
for (uint32 x1=0; x1 < EFFECT_COUNT; x1++) {
switch (spells[buffs[j1].spellid].effectid[x1]) {
case SE_Charm:
//case SE_Rune:
buffs[j1].spellid = SPELL_UNKNOWN;
m_pp.buffs[j1].spellid = SPELLBOOK_UNKNOWN;
m_pp.buffs[j1].slotid = 0;
m_pp.buffs[j1].level = 0;
m_pp.buffs[j1].duration = 0;
m_pp.buffs[j1].effect = 0;
x1 = EFFECT_COUNT;
break;
case SE_Illusion:
if(m_pp.buffs[j1].persistant_buff != 1){ //anything other than 1=non persistant
buffs[j1].spellid = SPELL_UNKNOWN;
m_pp.buffs[j1].spellid = SPELLBOOK_UNKNOWN;
m_pp.buffs[j1].slotid = 0;
m_pp.buffs[j1].level = 0;
m_pp.buffs[j1].duration = 0;
m_pp.buffs[j1].effect = 0;
x1 = EFFECT_COUNT;

Again, I appreciate any info related to this. I am not a coder, but I have spent plenty of time the past couple of days trying to read through most of the source to see if I could find the cause of my current issues.

Thanks