Rework Experience Calculation logic #547
No reviewers
Labels
No labels
Area-Assets
Area-Backend
Area-Conduits
Area-Datapacks
Area-Lang
Area-Mod Compat
Area-Parity
Area-Rendering
Good first issue
MC-1.19.2
MC-1.20.1
MC-1.20.4
MC-1.20.6
MC-1.21
MC-1.21.1
Modtoberfest
P-0-High
P-1-Medium
P-2-Low
Status-Awaiting Response
Status-Behind-Flag
Status-Blocked
Status-Cannot Reproduce
Status-Duplicate
Status-Help Wanted
Status-Incomplete Report
Status-Invalid
Status-Needs LTS Backport
Status-Needs Updating
Status-Stale
Status-To Implement
Status-Triage
Status-Wontfix
Status-Wontmerge
Type-Backport
Type-Bug
Type-Documentation
Type-Enhancement
Type-Question
Type-RFC
Type-Suggestion
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Team-EnderIO/EnderIO#547
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dev/rewrite-xp-logic"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Changes the xp calculations to remove recursive calls and use much straightforward formulae
(Closes issues indirectly by removing all stack overflow recursions)
Closes #543
Closes #313
I have also tried to clean function names, but it still requires some work. Let me know if you would like me to change docs/names
#363 will require an update if this PR is merged first (else the other way around)
If the fluid xp use int type can only contain about 4000 levels. maybe it's a problem?
Maybe it is smart to switch to long in some places, similarly to #329
Overflows should not happen anymore, as we don't use recursions anymore. Switching to long may not fix anything as vanilla max level is an INT
Stack overflows are avoided, yes however if we overflow an integer then we might find ourselves dealing with weird negatives
I will change the places where we store raw experience points into longs. The levels need to stay as an integer so that it is compatible with vanilla.
@ -1,6 +1,5 @@package com.enderio.base.common.util;any chance to make this long? and accept long in
getTotalLevelFromXp, as usually xp is just used as levels + the xp, so this method breaks faster than actual levels you can get, and I still think that for heavy modded moddpack we really need to start going away from ints, so many issues in so many mods as people just keep going higher.This breaks at 21863+ level, that is very high, but i feel like its doable with how many weird mods this can be combined with
@ -1,6 +1,5 @@package com.enderio.base.common.util;Yeah that is the plan. The only issue
Player#giveExperiencePointstakes int input. I will replace rest of the values with longs@ -1,6 +1,5 @@package com.enderio.base.common.util;Another issue that fluidStacks used to store XP use integers as well.
@ -1,6 +1,5 @@package com.enderio.base.common.util;Ah, didn't notice existing comment, sorry, using long for this would allow to easier future proof to hopefully improve containers later too, but for now would at least give easy way to check if XP will overflow and limit operations to only fill containers up to int max and not worry about it overflowing when calculating
@ -1,6 +1,5 @@package com.enderio.base.common.util;Any suggestions on how I should do that ?
@ -1,6 +1,5 @@package com.enderio.base.common.util;I think i had that in my older PR https://github.com/Team-EnderIO/EnderIO/pull/329/files#diff-f063d8fbab0bf1ca6d6fe016dbb81cd1fd3609a4bcc9d7d4ca8112f8b966dee1R103 but for sure need to check more places in code where xp is used.
@ -1,6 +1,5 @@package com.enderio.base.common.util;Looks good! I will convert them over :)
This looks great, thanks a lot to both chonky and GotoFinal for working on this issue!