Hi

When debugging i just found that because of money multiplier upgrade (which I won’t remove) The reward goes crazy high and the text field starts to showing it negative. I don’t mind in to going it in E and all but i dont want then negative

Numbers will overflow to negatives if they get larger than the biggest value. Under the hood, numeric arithmetic is just simple bit wise manipulation. If you numbers may overflow, then you need to trap this in your code.

Yeah, that kind of happens. It turns out ints are actually finite, in fact it’s only 31 bits (plus the signed bit). If you only want positive numbers then you can get the full 32 bits of range using a uint (unsigned integer), or you can get your money’s worth by using a long which is 63 bits.

Sounds like maybe you’re exceeding the maximum value that a signed integer can hold. A temporary fix would be to use an unsigned integer, but a true fix might be either to scale down your money so that you don’t approach the limits of numeric data types… or you can write a system of string numbers.

change 1000 to be “1000” and when you’re doing math, do it 1 place at a time like you would by hand. Then you don’t have to worry about limits.

Examples!

```
string cost = "1000";
string wallet = "2000";
Debug.Log(strSub(wallet, cost, 0));
public int strSub(string a, string b, int place)
{
return int.Parse(a.substring(place, 1)) - int.Parse(b.substring(place, 1));
}
```

Have methods to add and subtract from different places in your string, ultimately looping through and adding or subtracting each place. In the example I posted, if you subtract “4” and “3” you would get back 1, and you can put that in the string at the string index that was being subtracted. If you subtract “4” and “5” you will get back -1, so you know you need to handle a carry over.

Implement a string math system like I have in some projects and your number limit will be the maximum length of a string

Check out the BigInteger class. Just use with caution, its plausible to run out of memory this way.

As an alternative you can chain ints together. Or you can use the int64 if you just need a little bit more precision.

I did that for a game once. The first integer was the enemy health, the second integer was the number of health bars this enemy had, and the third integer was the number of those sets. So…

Monster health was ~30,000

Monster could have ~30,000 bars of health that were ~30,000 each

Monster could have ~30,000 sets of ~30,000 bars that were ~30,000 each

I found string math to be a more interesting solution.

My chaining was pretty similar. Each int64 represents 18 digits. If you go over on an individual int64 then you add 1 to the next int64. Limiting it to 18 digits meant you still had space to detect the overrun.

My implementation is still over on Answers if anyone wants to try their luck with the search engine

Hitting the limit is poor game/logic design.

Manipulating strings for math is also poor design.

I just converted int to int64 and it worked!

edit- now i will need to test app again as if i do not clear the save the int64 won’t read normal ints. I saved them with ToString. and loaded from Convert

ok now when i try to multiply reward it gives me that i am missing a cast. I tried most of them.

I am multiplying a int64 to a float

don’t ask me why

solved!

i just discovered a bug int 64 do not save in inspector

That’s probably a feature, not a bug. I doubt int64 would be serializable by default.

I also thought so. But i made it a serializeable field still the same result

SerialiseField doesn’t make something serializable. You will also need a property drawer and maybe serialisation call backs. There is probably scripts around for it already.

You could also just use smaller numbers.

Why are you multiplying to a float? A float only has seven digits of precision and you will be losing most of your number in the process. You should try multiplying to a decimal. It has about 28 digits of precision and is intended for financial math.

https://msdn.microsoft.com/en-us/library/364x0z75(v=vs.80).aspx

leave it its solves and my game is working

I could also just use larger number

I don’t consider math results where you lose entire parts of the number to be working.