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?) |
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 =) |
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 |
Quote:
And no, it's not related to raid addicts for a change. It's a secret project! |
Code:
#define HARD_LEVEL_CAP 127 |
Quote:
|
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
|
Quote:
|
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.
|
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.
|
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.
|
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 |
Oops, forgot to subtract one. Max sint32 value is 2,147,483,647, not that it matters for this purpose. :P
|
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. |
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. |
Quote:
better do it just once and never have to worry about it again :D |
Quote:
The solution was changing the 1000 multiplier to a lower number. It allows for a smooth progression. |
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.
|
This is why I cried custom feature. :(
|
Quote:
|
Quote:
|
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.
|
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? |
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? |
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? |
what ever it takes- I just need my lev 255 =)
|
Quote:
ChaosSlayer, why not check out the exp code from the x5 diff? |
Secrets and I worked on this a bit tonight. It looks possible, with the exception of one area:
Code:
struct LevelUpdate_Struct |
Guys- if you can get this to work- I will named npcs after you!!!
I can even make you Raid bosses! =) |
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.
|
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. |
i would love to have lev 200
|
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'; 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) { zone/exp.cpp Code:
//check_level represents the level we should be when we have zone/exp.cpp Code:
// Note: The client calculates exp separately, we cant change this function |
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. |
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. |
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) |
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:
|
Quote:
|
|
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.