Ability to level past 89ish?

[Secrets]

I noticed recently that if you try and get past a level around level 89, you cannot go past level 89, or so. Is there a way to fix this?

I'm guessing it would be in exp.cpp and features.h, but... I am not sure.

I would love to see the ability to level to 254 (which is the max before you have spell issues) added into the source. (in b4 why are you having characters level that high?)

[ChaosSlayerZ]

I absolutly, 500%, support this notion!

I don't know about 254 (yet) but I have allready laid out content progression up till lev 150 =)

[trevius]

I don't recall there being a limit in the source other than level 254. Though, there may be a define set for it that sets it to 127. As far as I know, there is nothing restricting levels below 127 atm. I can #level to 254 just fine. I assume you are referring to leveling via experience? Which client are you using, Titanium or SoF? Are you sure you have both the MaxLevel and MaxExpLevel rules set to allow you to go above those levels?

Why are you needing to level that high??? JK, I am betting it is Raid Addicts related :P

[Secrets]

I don't recall there being a limit in the source other than level 254. Though, there may be a define set for it that sets it to 127. As far as I know, there is nothing restricting levels below 127 atm. I can #level to 254 just fine. I assume you are referring to leveling via experience? Which client are you using, Titanium or SoF? Are you sure you have both the MaxLevel and MaxExpLevel rules set to allow you to go above those levels?

Why are you needing to level that high??? JK, I am betting it is Raid Addicts related :P

It's via experience and I think it is directly related to the experience formula in features.h, i'll see what I can do about it.

And no, it's not related to raid addicts for a change. It's a secret project!

[Yeormom]

#define HARD_LEVEL_CAP 127

The definition EXP_FORMULA is not preventing you from exceeding level 89.

[Secrets]

#define HARD_LEVEL_CAP 127

The definition EXP_FORMULA is not preventing you from exceeding level 89.

That variable isn't used anymore in source, AFAIK. The only time I saw it used was in SKILL_CAPS, and I think it was removed recently.

[KingMort]

ATM When you get past 87, actually when you ding 88 then die you will go to level 1 that is why 87 is the max level on Raid Addicts... To counter this you could have player quests running so it gives them an extra bit of exp after they ding 88+ ... But that is kindof ghetto if you ask me

[ChaosSlayerZ]

ATM When you get past 87, actually when you ding 88 then die you will go to level 1 that is why 87 is the max level on Raid Addicts... To counter this you could have player quests running so it gives them an extra bit of exp after they ding 88+ ... But that is kindof ghetto if you ask me

it certainly does sucks

[trevius]

Oh, maybe the total experience is exceeding the number allowed by an int32, which is what I assume exp uses. Does anyone know how much total exp you would have at level 88/89? The max allowed for int32 would be 4,294,967,295.

[Yeormom]

Well the subject is definitely out of scope for the actual trunk so this should probably be moved to custom code so you can at least begin your crusade if you so desire. You can definitely create a solution for this if so desired that won't affect the 32-bit integer cap.

[trevius]

There isn't any code in this thread yet, so I don't think it really needs to go in custom code yet. And even if there was, as long as a fix can be put in that is fairly simple and doesn't affect normal servers, I don't see why there would be a problem with having it included on the SVN. Live is getting really close to level 90 max already, so it isn't like it is way out of scope of the project or anything.

[Shendare]

The XP formula in EQEmu appears to be (Level - 1) cubed times LevelMod times 1000.

Level mod above 60 is 3.1.

So, Experience to get to the cap levels would be:

88: (87*87*87)*3.1*1000 = 2,041,359,300
89: (88*88*88)*3.1*1000 = 2,112,563,200
90: (89*89*89)*3.1*1000 = 2,185,403,900

The maximum value for a signed int32 is 2,147,483,648, about halfway between 89 and 90.

It looks to me like something in exp.cpp is using a signed int32 in its experience calculations.

I checked Client::AddExp(), Client::SetExp(), Group::SplitExp(), Raid::SplitExp(), and NPC::Death(), and didn't find an sint32 reference in any of them.

I thought at first there was a problem because I was seeing references to uint32 and int32, and assumed int32 was a signed int32, but I was mistaken. int32 and uint32 are both typedefs of unsigned int, according to common/types.h.

So further investigation will be necessary.

This unrelated code in SetExp, however, may need a review:

File: exp.cpp, Line 212 - SetExp()

//check_level represents the level we should be when we have
//this ammount of exp (once these loops complete)
int16 check_level = GetLevel()+1;
//see if we gained any levels
while (set_exp >= GetEXPForLevel(check_level)) {
check_level++;
if (check_level > 127) { //hard level cap
check_level = 127;
break;
}
}


- Shendare

[Shendare]

Oops, forgot to subtract one. Max sint32 value is 2,147,483,647, not that it matters for this purpose. :P

[trevius]

Nice work, Shendare! So, it sounds like we could just change the sint to a int32 and get quite a few more levels out of the int32. Using that formula, it should be able to go to level 112:

int32 max is 4294967295
112 (111*111*111)*3.1*1000 = 4239656100
113 (112*112*112)*3.1*1000 = 4355276800

How many levels are you needing to allow exactly, Secrets? If it is less than 113, then it sounds like the solution might not be too bad. If it is more than that, I am sure it could be worked out, but would probably take more work/code to do it.

[Shendare]

Actually, you must have misunderstood.

While I have identified that the problem is almost certainly an sint32 (or perhaps just an "int") somewhere in the code, I haven't found where it is yet.

[ChaosSlayerZ]

How many levels are you needing to allow exactly, Secrets?

I will take all 254 please :D
better do it just once and never have to worry about it again :D

[Secrets]

Nice work, Shendare! So, it sounds like we could just change the sint to a int32 and get quite a few more levels out of the int32. Using that formula, it should be able to go to level 112:

int32 max is 4294967295
112 (111*111*111)*3.1*1000 = 4239656100
113 (112*112*112)*3.1*1000 = 4355276800

How many levels are you needing to allow exactly, Secrets? If it is less than 113, then it sounds like the solution might not be too bad. If it is more than that, I am sure it could be worked out, but would probably take more work/code to do it.

I ended up writing my own formula to allow it, heh. But it is more than 112, but even then, this is a very nice advancement.

The solution was changing the 1000 multiplier to a lower number. It allows for a smooth progression.

[trevius]

I wonder if that multiplier should be made into a rule that defaults to 1000. Might not be a bad solution for the servers out there wanting to go higher. I know there aren't many, but a rule might not be a bad option. I am not sure on the details of how exp is sent to the client though, so not sure how changing that might effect leveling rates and such.

[Yeormom]

This is why I cried custom feature. :(

[KingMort]

Well the subject is definitely out of scope for the actual trunk

What are you talking about ??? This is Eqemu the max level on LIVE right now is 85... And will soon most likely be 90.. So this issue really should be looked into and fixed..

[steve]

What are you talking about ??? This is Eqemu the max level on LIVE right now is 85... And will soon most likely be 90.. So this issue really should be looked into and fixed..

Max level for Underfoot (next expansion) is staying put at 85. It'll be at least another year and a couple months before we get another level increase.

[trevius]

Either way, as long as it isn't hindering normal servers at all, and isn't a massive amount of extra code, I don't see any reason it couldn't be added in for servers wanting to make use of higher levels. We know there are at least a few out there that do want to or do already.

[Jobe123]

Sorry to sound like a tool here and uneducated, however just looking at this from an outsiders standpoint wouldnt it just be easier to set XP required per level to 50% and then just modify the XP rates down to 50% as well allowing for 188 levels without rolling over the numbers?

And for hitting 254 or 255 then couldnt one just reduce XP required to level down to say 15% of its current value and then reduce xp rates to 15% as well allowing more than enough room for the 254 levels without pssible rollover?

[ChaosSlayerZ]

yeah there is no reason to use 1,000 to represent XP from 1 to 2, when you could use say 100, or even 20
and then max level could be much much higher - isn't it?

[iggi]

That's a good option, but it would also cause current servers to change their config (oh no!!1).

Theoretically couldn't you just make this a "long long" type and therefore 64bits long allowing for over 18 000 000 000 000 000 000 or level 181,211 (given other restrictions allow)?

P.S.- This is just an observation from a novice, but isn't level^3*3.1*1000 additional CPU cycles, rather than 3100*level^3, no decimal and less operations?

[ChaosSlayerZ]

what ever it takes- I just need my lev 255 =)

[Secrets]

what ever it takes- I just need my lev 255 =)

Level 255 is a bad idea. If you make level 255, players can use spells regardless of class.

ChaosSlayer, why not check out the exp code from the x5 diff?

[iggi]

Secrets and I worked on this a bit tonight. It looks possible, with the exception of one area:

struct LevelUpdate_Struct
{
/*00*/ uint32 level; // New level
/*04*/ uint32 level_old; // Old level
/*08*/ uint32 exp; // Current Experience
};


Looks like it sends the xp to the client :( I am compiling the server as we speak to see if it will work with changing that as well to a long long. If this does not work, I will also try not sending the exp variable in the packets to the client, I think this may cause you to have to zone to update the level, but hey can't hurt to try (heck if it works I might have done something productive for once!).

[ChaosSlayerZ]

Guys- if you can get this to work- I will named npcs after you!!!
I can even make you Raid bosses! =)

[Astal]

So has this gone anywhere. I know akkadius has a way to get to atleast 90 on his server. I plan on asking him how its done. I would like level 100 on mine if possible for the time being.

[Vanicae]

Have you tried raising the Character:MaxExpLevel rule? The hard coded maximum of 127 is still in the code, and with the current formula, level 90 takes 2,185,403,900 exp, well within the range of the variable it's stored in.

If there is still any interest or need to go over 111 or so, it would need to be stored in a 64bit int, or the formula would have to be scaled down. The noted issue with LevelUpdate_Struct isn't an issue, the exp value sent to the client is a value 0-330, not the real exp value. The client displays exp in increments of 0.33% and doesn't care how it's calculated server side.

[ChaosSlayerZ]

i would love to have lev 200

[blackdragonsdg]

Well I was still testing this but I was able to max out at level 253 via experience before hitting a wall.


Required sql
update rule_values set rule_value = 239765 where rule_name = 'AA:ExpPerPoint';
update rule_values set rule_value = 254 where rule_name = 'Character:MaxLevel';
update rule_values set rule_value = 254 where rule_name = ' Character:MaxExpLevel';


This part is optional as it just mantains an exp scaling similar to what exists in the default peq database.

zone/exp.cpp
void Client::AddEXP(int32 in_add_exp, int8 conlevel, bool resexp) {

int32 add_exp = in_add_exp;

if(!resexp && (XPRate != 0))
- add_exp = static_cast<int32>(in_add_exp * (static_cast<float>(XPRate) / 100.0f));
+ add_exp = static_cast<int32>(in_add_exp * (static_cast<float>(XPRate) / 10000.0f));

if (m_epp.perAA<0 || m_epp.perAA>100)
m_epp.perAA=0; // stop exploit with sanity check

int32 add_aaxp;
if(resexp) {
add_aaxp = 0;
} else {

//figure out how much of this goes to AAs
add_aaxp = add_exp * m_epp.perAA / 100;
//take that amount away from regular exp
add_exp -= add_aaxp;



zone/exp.cpp
//check_level represents the level we should be when we have
//this ammount of exp (once these loops complete)
int16 check_level = GetLevel()+1;
//see if we gained any levels
while (set_exp >= GetEXPForLevel(check_level)) {
check_level++;
- if (check_level > 127) { //hard level cap
+ if (check_level > 254) { //hard level cap
- check_level = 127;
+ check_level = 254;
break;
}
}



zone/exp.cpp
// Note: The client calculates exp separately, we cant change this function
// Add: You can set the values you want now, client will be always sync :) - Merkur
uint32 Client::GetEXPForLevel(int16 check_level)
{

int16 check_levelm1 = check_level-1;
float mod;
if (check_level < 31)
mod = 1.0;
else if (check_level < 36)
mod = 1.1;
else if (check_level < 41)
mod = 1.2;
else if (check_level < 46)
mod = 1.3;
else if (check_level < 52)
mod = 1.4;
else if (check_level < 53)
mod = 1.5;
else if (check_level < 54)
mod = 1.6;
else if (check_level < 55)
mod = 1.7;
else if (check_level < 56)
mod = 1.9;
else if (check_level < 57)
mod = 2.1;
else if (check_level < 58)
mod = 2.3;
else if (check_level < 59)
mod = 2.5;
else if (check_level < 60)
mod = 2.7;
else if (check_level < 61)
mod = 3.0;
else
mod = 3.1;

float base = (check_levelm1)*(check_levelm1)*(check_levelm1);

- mod *= 1000;
+ mod *= 10;

return(uint32(base * mod));
}

[ChaosSlayerZ]

I have a proposition:

If variable size cannot be changed to a larger one, I would propose a work around:
-we add a table to DB called XP_curve
-in this table we have 3 columns: Level, XP_needed, XP_per_NPC

so for example: Level (2), XP_needed (5000), XP_per_NPC (500)

what this means, is that Lev 2 takes 5000 XP to achieve, and level 2 mob gives 500 XP.

This way, I can scale down entire table, lowering Xp need per level, and xp per npc lev, in order to fit MORE levels into XP variable so it doesn't roll over (why use 5000 and 500, when you can do 50 and 5?)

This will also allow LIVE-like servers to stay with live-true XP curve, while custom server can fine-tune their XP curve, and smooth out hell levels, or in fact add more of them, anyway they like

You could also create such things, as 0 XP per specific level npcs, using this table, if needed and so on.

[blackdragonsdg]

ChaosSlayerZ, some of what you are talking about is already possible to do. Changing the xp needed per level and the amount of exp an npc gives out is easy to achieve without adding new fields. Simply changing the modifiers in the source accomplishes that task. I can already level to 253 by experience. Maintaining a live like exp curve is possible but will take lots and lots of tuning of one of the modifiers.

I have read several times on these forums that some of the server administrators have already accomplished leveling to 100 and beyond. Exactly how they did it on their servers is unknown but I have already posted how I achieved that task. My method was not flawless but it does work.

However I do agree that it would be alot easier if it were possible to control those changes in the database.

[ChaosSlayerZ]

yeah that the problem - doing your own source changes puts a tremendous overhead on server maintenance.
and every time you want to stay up to date with Emu source improvements, you have redo all these changes manually and hope you don't break something.

Not to mention my one extra table, allows fine tuning of XP curve on the fly, without the need to ever touch the source and screw something up, given our primary devs would be willing to implement this feature 8)

My C coding skills are not at the level where I would feel comfortable, of running my own source, hence I am totally dependent on official Emu devs 8)

[Caryatis]

Nobody is going to add that table to the official source though as nobody would want to adjust exp levels on the fly as you suggest. Why? because screwing with the exp curve means all existing chars get messed up, either losing levels on death or losing levels when you ding, etc. Many things get messed up for existing chars when you change the exp curve.

Blackdragon posted a workaround for what you need and if you want you can adjust those levels as you see fit. Secrets has also posted his source on how he got to level 65k.

You can see people who wanted this change bad enough to learn the very basics of coding(look at what blackdragon posted, its not advanced enterprise level C++ coding, its basic 'if-then' statements, anybody can understand that), if you wanted this change on your server then it wouldn't be an issue for you to spend a few hours of your time to learn how to do it. Which is alot more effective than putting in your sig to get somebody else to do all the work for you and posting for over a year hoping somebody notices.

doing your own source changes puts a tremendous overhead on server maintenance.

As somebody who freely admits to not being knowledgeable enough to change his source code, Im curious how you can be knowledgeable enough to know how much effort is involved in keeping custom source updated(its not hard at all).

[blackdragonsdg]

Secrets has also posted his source on how he got to level 65k.


Where was that posted at? That could give me an answer to one of the problems I encountered changing the source to go to level 254.

[Caryatis]

https://code.google.com/p/mythic-edgev/source/detail?r=48

[blackdragonsdg]

Thanks Caryatis.

That confirmed what I already thought was occuring with maxlevel, check_level and there variable types. Now to scour over the rest to find that dern update that was causing the other problem.

[ChaosSlayerZ]

Nobody is going to add that table to the official source though as nobody would want to adjust exp levels on the fly as you suggest. Why? because screwing with the exp curve means all existing chars get messed up, either losing levels on death or losing levels when you ding, etc. Many things get messed up for existing chars when you change the exp curve.


not unless you starting off a fresh a server with no chars


You can see people who wanted this change bad enough to learn the very basics of coding(look at what blackdragon posted, its not advanced enterprise level C++ coding, its basic 'if-then' statements, anybody can understand that), if you wanted this change on your server then it wouldn't be an issue for you to spend a few hours of your time to learn how to do it. Which is alot more effective than putting in your sig to get somebody else to do all the work for you and posting for over a year hoping somebody notices.


This is a problem in Emu coding which wasn't addressed back in day cause no one cared for going over lev 70 at the time. Now, with all the catching up with SoF and SoD, the live cap has hit level 90, and you WILL have to change the code in order to catch up.
But if devs would have thought about planning one little variable like 5 years ago - we would not have this problem today.
So yeah, I do hope SOMEONE, from official devs, will finally notice this.



As somebody who freely admits to not being knowledgeable enough to change his source code, Im curious how you can be knowledgeable enough to know how much effort is involved in keeping custom source updated(its not hard at all).

while i do not work C code myself (oh I know C, I just choose never to mess with custom changes outside of official code), at THF we have lots of custom coding which makes its hard to keep up to date with official updates, and Lilu, our boss, as already pulling his hair out over this. So, trust me, I know what I talking about =P

[Secrets]

If I was a custom server starting fresh with the knowledge I know today, I would completely change the exp code. Why?

1) The exp code only gives support up to level 90 without rollover past deaths.
2) The exp code factors in NPC con too much.
3) It's based on exp count, not number of kills.
4) 2 and 3.

Why number of kills? It's pretty simple:

1) smaller numbers
2) less exponential growth to leave room for valid integers
3) it's not a float
4) easily tracked

You can do this one of two ways:
1) Extended profile
2) Gut the exp code and use perl

This leaves us with these results:
1) Level support up to 65535 (minus spells being scribeable below 250, but that can be fixed on the server)
2) Completely custom exp formula


I suggest 1. Good luck.

[Caryatis]

Not to mention my one extra table, allows fine tuning of XP curve on the fly

!=

not unless you starting off a fresh a server with no chars

If you are setting up a fresh server, then just edit the source. Considering that HoT client isn't supported at all, its not like a rush to make it so that level 90 is supported(and if/when the HoT client push comes, that will be one of the things that gets changed, although since we are only 1 level short of 90, would be easy to just alter the mod for level 90 so that it stays within the limits, as opposed to doing anything else).

[Secrets]

If you are setting up a fresh server, then just edit the source. Considering that HoT client isn't supported at all, its not like a rush to make it so that level 90 is supported(and if/when the HoT client push comes, that will be one of the things that gets changed, although since we are only 1 level short of 90, would be easy to just alter the mod for level 90 so that it stays within the limits, as opposed to doing anything else).

Even if you are working on an existing server...

changing it so when you log in, checking the level, setting the exp to getexpforlevel(level) then storing a boolean so that you know you logged in since you updated the server (in the extended player profile (m_epp)) *then* calculating experience afterwards would be the ideal goal. It would reset some progress into the level that they had, though, but you could tweak the entire exp formula this way.

[Secrets]

To further back my idea,


Index: common/extprofile.h
================================================== =================
--- common/extprofile.h (revision 1709)
+++ common/extprofile.h (working copy)
@@ -46,6 +46,7 @@

uint32 aa_effects;
uint32 perAA; //% of exp going to AAs
+ bool expchange;
};

#pragma pack()
Index: zone/client_packet.cpp
================================================== =================
--- zone/client_packet.cpp (revision 1709)
+++ zone/client_packet.cpp (working copy)
@@ -8586,6 +8586,13 @@
}


+ if(!m_epp.expchange)
+ {
+ SetEXP(GetEXPForLevel(GetLevel()), GetAAXP(), false);
+ m_epp.expchange = true;
+ }
+
+
////////////////////////////////////////////////////////////
// Task Packets
LoadClientTaskState();


Change EXP Formula, Add in code, ????, profit!

[blackdragonsdg]

If you change the modifiers in the exp code you will need a way to let the client/server know something changed or you will encounter one of the problems I did where a newly created character kills a level 1 npc and gains 100+ levels or a level 85 character dies then loses 7 levels instead of 10-15% of the current level.

I had been wanting to do something similar to what Secrets proposed but I simply do not have the needed skill to implement it.

[ChaosSlayerZ]

yeah thats why I am trying hard to get KLS attention to make this fix official :)

[Secrets]

If you change the modifiers in the exp code you will need a way to let the client/server know something changed or you will encounter one of the problems I did where a newly created character kills a level 1 npc and gains 100+ levels or a level 85 character dies then loses 7 levels instead of 10-15% of the current level.

I had been wanting to do something similar to what Secrets proposed but I simply do not have the needed skill to implement it.

The server is the only thing that needs to know the full exp data; the client is quite stupid and only displays a number between 1-100. I don't even think the rezexp stored on the corpse is used, though I could be wrong.



yeah thats why I am trying hard to get KLS attention to make this fix official

PEQ doesn't have this issue, therefore it'll never be 'official' until PEQ runs into this issue. Simple fix would be changing the data value to a float for now. If that's too much to ask, well, can't help you really.

However, I can tell you this: SVN checkout + svn update after modifications using tortoisesvn in windows is pretty easy. If you are using another SVN, use tortoisesvn's export function and check out the eqemu revision you stopped on. After that, paste your files into the eqemu folder you checked out. SVN update, resolve the conflicts (as long as you didn't change any major systems, this shouldn't be an issue. Or systems that get changed rarely IE exp.) and compile. Problem solved.

[blackdragonsdg]

I think I have figured out why I was getting massive exp loss on death. I always thought exp loss on death was just a varied percentage being taken away from the players current exp. I assumed that was the case which is a noob mistake. I should know better than to assume anything like that.

Yesterday I started looking for the code that controls death and exp loss and well I found it. There is a large modifier in that formula just as there was in exp gain. So I decreased the modifier by the same factor I used in the exp formula. Then I repeatedly killed a level 85 character as a test, the character only lost about 10% exp on each death instead of 7 levels per. Gonna test this some more but it is looking pretty good so far. I also changed the code for death by sacrifice that necros love using.

Are there any other death tricks in the code that I should look for?

[ChaosSlayerZ]

btw there is a rule which controls XP loss on death, you may want to take that into account when changing the modifier

[Astal]

So has anyone actually figured out what should be done exactly, I looked at secrets post on page 4 (im not good with C++) im gonna maybe try and implement it. All i need is level 100, but im getting a bug when i go past like 80ish.

When i attack a creature, my hp regens the exact amount ive lost when im higher than level 80 until my hp is at like 50% then it works as if it were normal



Edit:

Ok it seems to be a problem with the client i assume? Since live only goes up to 85 atm?

Anything past 85 bugs out on the display. I guess there is no way around that. Anything past 90 causes HP to regen back any damage taken until my hp is below 50% ish.

If anyone knows hot to fix this please let me know. Im trying to allow my server up to level 100

[blackdragonsdg]

Short answer is yes, it is possible to level to 100 and beyond. What I posted above will get you to max 253. There are other work arounds, one of which allows you to level up to 65535 I believe it was and it can probably be expanded beyond that if you really wanted to.

The hp flux sounds like an older emulator bug that was fixed. If your display is cutting off hp, mana and endurance values then mod the display to allow for larger numbers.

[Akkadius]

So has anyone actually figured out what should be done exactly, I looked at secrets post on page 4 (im not good with C++) im gonna maybe try and implement it. All i need is level 100, but im getting a bug when i go past like 80ish.

When i attack a creature, my hp regens the exact amount ive lost when im higher than level 80 until my hp is at like 50% then it works as if it were normal



Edit:

Ok it seems to be a problem with the client i assume? Since live only goes up to 85 atm?

Anything past 85 bugs out on the display. I guess there is no way around that. Anything past 90 causes HP to regen back any damage taken until my hp is below 50% ish.

If anyone knows hot to fix this please let me know. Im trying to allow my server up to level 100

You start opening a can of worms post level 86, I have ways of showing information to clients but it's not the most efficient way to handle it. You cons are also completely jacked.

Both two small things in my opinions that I could have generated in a utility window for players but just letting you know ahead of time it's not clean cut.

[Astal]

Yeah im probably not gonna mess with it right now. I dont really NEED post 85 levels. Was gonna do it if it wasnt a pain hahaha