Having a lot of issues with big numbers

So, in one of my projects, I have been having a lot of issues with big numbers. The first time it was rounding causing it to become an integer, which made the numbers overflow in the billions range. I stopped rounding the numbers, but found that they would still overflow somewhere in the quadrillions to quintillions range.

I attempted to make a workaround by having a stand-in variable that represents a quadrillion of the previous number, but that seems to have only made things worse. I have several screens of code dedicated to making the math work every single time I need to use this variable, and it is extremely prone to having unexpected errors due to just the sheer volume of how much code I need to write every time I use that variable.

I am wondering, if anyone else has dealt with this kind of issue, is there an easier way to handle numbers large enough to cause overflow?

I stopped rounding the numbers, but found that they would still overflow somewhere in the quadrillions to quintillions range.

It sounds like you are rounding somewhere. The maximum 64-bit integer lies in that range.

For display purposes, you can 'split text using , as separator' to get a list. The first element of the list will be the "rounded" number, but represented as a string instead of a floating point number.

Unfortunately, since Stencyl uses one "number" type attribute, it'll be harder to control whether the "number" is a float or an integer. What I'd do in this scenario is either write an extension or a 'code mode' behavior to handle all of my math.

Unfortunately, I don't have any experience with code mode or extensions. So, I'm not sure where to begin with writing one to prevent the math from becoming an integer.

I tried to remove all the rounding in the game as best as I could. Which is how I was able to get past the billions. I'm not sure what might still be forcing the variable to turn into an integer...

If it's rolling over in the quintillions then somewhere you have conversion 64-bit integer. The max 32-bit float is in the undecillions, and the max 64-bit float has 308 digits. (I can't get the number name for it).

I looked at the Haxe code generated from a design mode behavior--all of the "number" attributes are declared as Float. Where I suspect you might be running into trouble is either somewhere you're rounding that is overlooked, or where you store a value in a Dynamic type variable, which is then converted to an integer instead of Float. One example I'm thinking of is retrieving and storing values from a list. One trick to force representation as a Float is to multiply a number by 1.0. I don't know if this works in Haxe, but it works in Python, Mathematica, Maple, and some other high level languages. If you're storing values in a list, try multiplying them by 1.0 when you store them... e.g.

add (number x 1.0) to list

I'm not adding anything to a list either. Does it convert the variable type if the rounding happens without storing the result? For example, if I take Variable X, and tell it to set Variable Y to the round of Variable X divided by 100, would that cause Variable X to still turn into an integer?

Working on trying to re-convert things to normal and I hit this compile error:

./src/scripts/Design_1537_1537_WillpowerConversionandDisplayBackup.cpp(220): error C2177: constant too big

Which refers to the behavior which converts the large variable into readable units (1,000,000 to 1.00 M, 1,000,000,000 to 1.00 B, etc up to decillions. Did some testing and it gives the error when the math involves the quintillions. So, even if the numbers can "reach" the undecillions in theory, it seems that it can not actually use those numbers.