EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Development::Feature Requests (https://www.eqemulator.org/forums/forumdisplay.php?f=612)
-   -   Ability to level past 89ish? (https://www.eqemulator.org/forums/showthread.php?t=28822)

Secrets 07-08-2009 08:41 PM

Ability to level past 89ish?
 
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 07-08-2009 09:08 PM

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 07-09-2009 03:10 AM

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 07-09-2009 04:20 AM

Quote:

Originally Posted by trevius (Post 173871)
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 07-09-2009 11:06 AM

Code:

#define HARD_LEVEL_CAP 127
The definition EXP_FORMULA is not preventing you from exceeding level 89.

Secrets 07-09-2009 07:14 PM

Quote:

Originally Posted by Yeormom (Post 173883)
Code:

#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 07-09-2009 07:33 PM

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 07-09-2009 08:42 PM

Quote:

Originally Posted by KingMort (Post 173925)
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 07-10-2009 05:48 AM

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 07-10-2009 11:08 AM

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 07-10-2009 11:26 AM

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 07-10-2009 11:27 AM

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()
Code:

        //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 07-10-2009 11:35 AM

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

trevius 07-10-2009 11:42 AM

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 07-10-2009 11:44 AM

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 07-10-2009 11:57 AM

Quote:

Originally Posted by trevius (Post 173990)
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 07-10-2009 03:50 PM

Quote:

Originally Posted by trevius (Post 173990)
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 07-10-2009 04:24 PM

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 07-10-2009 04:52 PM

This is why I cried custom feature. :(

KingMort 07-11-2009 03:37 PM

Quote:

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 07-11-2009 04:26 PM

Quote:

Originally Posted by KingMort (Post 174077)
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 07-11-2009 04:33 PM

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 08-29-2009 05:55 AM

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 08-29-2009 06:59 PM

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 11-22-2009 02:28 PM

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 11-22-2009 04:23 PM

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

Secrets 11-22-2009 09:49 PM

Quote:

Originally Posted by ChaosSlayerZ (Post 181368)
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 11-26-2009 02:28 AM

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

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 11-26-2009 03:01 AM

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

Astal 09-13-2010 09:06 AM

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 09-13-2010 07:04 PM

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 09-19-2010 04:43 AM

i would love to have lev 200

blackdragonsdg 09-19-2010 04:13 PM

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


Required sql
Code:

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
Code:

        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
Code:

        //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
Code:

        // 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 10-24-2010 01:40 PM

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 10-24-2010 07:29 PM

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 10-24-2010 08:00 PM

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 10-26-2010 04:59 PM

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.

Quote:

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 10-26-2010 05:26 PM

Quote:

Originally Posted by Caryatis (Post 193706)
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 10-26-2010 05:30 PM

https://code.google.com/p/mythic-edg...ce/detail?r=48

blackdragonsdg 10-26-2010 05:40 PM

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.


All times are GMT -4. The time now is 07:27 PM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.