Over 1 million

#1 It's a precision setting on the sprintf formatting in the engine, ultimately limited by the fact that the values storing the numbers are only 32 bits wide.

I had thought 1.4 core had increased everything to 64 bits and upped the formatting, but I guess that didn't happen if the latest TGB is exhibiting the problem. There are a few solutions:

1. If you can live with only one more digit (9,999,999) then you can easily go in and change the sprintf formatting from .%6f to .%7f without touching anything else. Search for dSprintf with formats of .%6f, primarily in compiledEval.cc, compiler.cc, and consoleTypes.cc and change them to .%7f instead.

2. Take a stab at converting everything to 64-bit and increasing the precision further (e.g. .%9f) everywhere. This had proved to be quite hairy when I tried it. There were so many places that relied on these variables that strange behaviors happened. I ended up rolling back my changes and going with option 1 above.

3. Artificially separate your score and do some extra math when you increment your score; basically have a high-order score value and a low-order score value, each only 4 or 5 digits wide. When increasing the score, add it to the low order value; if it crosses the digit threshold, zero it out and carry the overflow to the high-order score. This lets you have basically as many digits as you want (if you need more than 12, you could have three score-segments, etc.). Kinda klunky but functional.

#2 I'm actually not using a beta, so it might be fixed there. Thanks for the info, though. I didn't realize it was as simple as changing a printf statement. :) I'll give it a shot, and thanks again for the help!

#3 You are aware that any version of T2D / TGB is beta as it is the early adopter license? ;-)

#4 I think he means he's using the alpha still... I'm in the same boat and can sympathize. BTW Jason is good to see you're attempting a more... casual... game for this go around. Good luck with it. (I "betatested" Little Gods... )

-Tim

#5 Thanks, Tim. :) If you're up for beta testing this one, let me know. Could use your detail-oriented eyes on it. ;)

#6 Just wanted to confirm that this behavior is in RC3, in case anyone else is interested.

@Luke: I searched the whole solution for .%6f, %6f, etc. and found nothing. I'm not sure it's a formatting problem, but I don't know what else it would be. Is there some compiler setting to control default int output behaviors in C++?

Edit: I found quite a few instances of %d formatting, but I assume that would handle numbers with more than 6 digits.

#7 Looks like a lot has changed with TGE 1.4 integration; all my work is still on 1.0.2. I'm looking at Beta 4 right now (haven't downloaded RC3 yet but I'm betting its the same as Beta4).

You're probably looking for "%g" now (still in files such as consoleTypes.cc, consoleInternal.cc, console.cc compiledEval.cc, etc.) and you'll want to change those to %.7g instead. Unless of course you can find some global place to change the default formatting length for %g, which I'm not sure is available in the compiler.

#8 Oh and reading back to my first post, I totally pooched the formatting on that one (that's what I get for posting from memory!), it should definitely be %.7g, not .%7g, just to avoid any confusion.

#9 I didn't find any formatting with %g, either. [Correction: I found a bunch but none that specify number of digits.] I am not sure how I'll solve this problem. Thanks for your help, Luke. :)

Edit2: I think it is somewhere in the math output conversion, because if you echo an addition >= 1,000,000 it turns into hoo-haw.

#10 I just grabbed RC3, did a search-and-replace for %g to %.7g in the following files:

compiledEval.cc
compiler.cc
console.cc
consoleInternal.cc
consoleTypes.cc (there are some %g that aren't relevent, namely those used in TypeColor functions)
stringStack.h

And I was able to math on variables (as well as immediate w/ constants) up to 9,999,999. Some of these might not have been necessary to change, I didn't look very closely.

I also tried bumping it up one more decimal place, but the core support for floats is apparently still at 32bits because you immediately lose decimal accuracy on large numbers with %.8g or higher. Now that the cleaner 1.4 code is here, it might be an easier task than before to bring the float support completely up to 64bit where necessary to get much larger numbers. Maybe when I start working with something less archaic than 1.0.2 I'll give it a shot. :)

The issue you noted about the math is because the variables are typeless in Torque. Until you do some kind of math operation on the number, Torque considers "$test = 5000000;" to be a string, as far as I can tell. Which is why "echo($test);" works, but "echo($test + 0);" won't.

#11 Wow, thanks for that Luke! I'll give it a try. Let's hope the 64-bit support gets into the engine eventually to avoid these types of problems.

Edit: just rebuilt after search and replace, and it works. Thanks again for your help with this, Luke. :)