- Joined
- Jul 10, 2007
- Messages
- 6,306
With default xp settings, at level 6552, the xp is at 2146584576. The reason 6553 turns into 10,000 is because the xp overflows (2^31, or 2147483648 is max).
xp is stored in an unsigned int. If you look at a level 9268, you see this
4294734080 out of 693248
unsigned limit: 4294967296
so it overflows. The real value is 693248+4294967296
If you added 233216, it shows
0 out of 693248
What this means is that in order to get actual required xp for a given level, you have to do it in this format
xp+4294967296^power
However, because integers are signed
xp+(2^31)^power1+(2^32)^power2
so you'd have 3 values to represent proper xp.
When adding xp, it bugs due to overflow errors. If you were to add 2^31-1 xp to a level 1, it would go to level 10,000 due to overflow errors. We saw that level 9268 required 4294734080 xp.
2147483647 out of
4294734080
Clearly, the unit with 2147483647 is not even at level 9268.
10,000 requires 704825856 xp (bugged overflow). In order to see how wc3 handles the max level, I now add 704825856-1
resulting level: 3754
I now add 704825857
resulting level: 3754 with 704825856 xp
What this means is that you can only safely add hero max level xp at a time up to when it overflows. However, because it overflows at a level that requires less xp than 2^31, this means that wc3 was coded stupidly. wc3 uses integers when computing levels but stores the actual xp in an unsigned int. This would explain why when adding 704825856 many times results in a level 6502 that is not into its level at all (adding -xp just sends it to minimum xp for level) whereas adding it 3x results in a 6502 that is almost level 6503.
What this means is that a couple of my own libs do not currently work correctly
-> UnitStatePercent
-> SetHeroLevelX
I will be fixing them though =).
Now, the next bug to address is why UnitStripHeroLevel gives more -regen than necessary. If you continue to strip down from 10,000, your hero will eventually have -xp (very, very, very strange considering the ints should be unsigned, unless ofc they have an extra bit for the sign).
xp is stored in an unsigned int. If you look at a level 9268, you see this
4294734080 out of 693248
unsigned limit: 4294967296
so it overflows. The real value is 693248+4294967296
If you added 233216, it shows
0 out of 693248
What this means is that in order to get actual required xp for a given level, you have to do it in this format
xp+4294967296^power
However, because integers are signed
xp+(2^31)^power1+(2^32)^power2
so you'd have 3 values to represent proper xp.
When adding xp, it bugs due to overflow errors. If you were to add 2^31-1 xp to a level 1, it would go to level 10,000 due to overflow errors. We saw that level 9268 required 4294734080 xp.
2147483647 out of
4294734080
Clearly, the unit with 2147483647 is not even at level 9268.
10,000 requires 704825856 xp (bugged overflow). In order to see how wc3 handles the max level, I now add 704825856-1
resulting level: 3754
I now add 704825857
resulting level: 3754 with 704825856 xp
What this means is that you can only safely add hero max level xp at a time up to when it overflows. However, because it overflows at a level that requires less xp than 2^31, this means that wc3 was coded stupidly. wc3 uses integers when computing levels but stores the actual xp in an unsigned int. This would explain why when adding 704825856 many times results in a level 6502 that is not into its level at all (adding -xp just sends it to minimum xp for level) whereas adding it 3x results in a 6502 that is almost level 6503.
What this means is that a couple of my own libs do not currently work correctly
-> UnitStatePercent
-> SetHeroLevelX
I will be fixing them though =).
Now, the next bug to address is why UnitStripHeroLevel gives more -regen than necessary. If you continue to strip down from 10,000, your hero will eventually have -xp (very, very, very strange considering the ints should be unsigned, unless ofc they have an extra bit for the sign).
