Number field displaying above 999999?

[kirbol]

Is there a method to allow a number field to display a number great than 999999? I can't seem to come up with anything.... The exp field I have keeps going to scientific notation once I go above that, though the tool tip for unspent exp can show values in excess, as well as the /die 1000000 command, for instance.

[Moon Wizard]

Is this only occurring in v2.7 or in v2.6.5 as well?

By default, floating point number textual output converts to exponential notation at about that amount.

Cheers,
JPG

[Moon Wizard]

Interestingly enough, there apparently is no easy way to output a floating point number to a string in C++ such that I get it the exact way I would like. The current method appears to be the best given the situation.

FG uses the %g format to output the string. If you do it like the tooltips, then it only works for numbers without any decimal positions. (%.14g format per LUA number to string conversion) If you do it with a straight float conversion, then you have to specify the number of decimal places which is not easy to calculate, or you always get the default of 5 decimal places (%f format).

I'll be taking a look at fixing up large number displays if I can find some good code, but it may not make 2.7 cut.

Cheers,
JPG

[kirbol]

I found it originally in 2.6.5, and it also happens in 2.7. I was thinking on this a big, and just wondering if the numbercontrol or numberfield control could have a formatting flag, (something like <bigint /> or something, so you could specify that this particular field might get very large.

I'm not particularly skilled in C++, but I thought there was a way to use the %f in something similar to %8.2f if you wanted 8 digits and 2 decimal...

Another though could be a flag for the number control, of something like format where you could specify this...<numformat>8.2f</numformat> or <numformat>8i</numformat> (perhaps for an integer, or just 8.0)

Just a couple quick ideas.. and thanks again for the feedback:)

[Griogre]

Interestingly enough, there apparently is no easy way to output a floating point number to a string in C++ such that I get it the exact way I would like. The current method appears to be the best given the situation.

You might try using sprintf out of the C library.

[Moon Wizard]

Actually, we are using sprintf. The problem is that none of the built-in formats are sufficient for what FG needs.

%g - What we're using now, displays the shortest possible version (including exponential notation).

%.14g - Used by LUA, works great for big numbers, but terrible for decimal places. (shows 14 decimal places after point)

%f - Display is very good, but it's all or nothing for decimal places. That means every number field would display 2 decimal places (or whatever number we chose).

Basically, I would need to build our own custom float to string conversion function to get exactly what we need. (Show all places before the point regardless of size, and show any decimal places but show the minimum necessary)

Cheers,
JPG

[kirbol]

Just sort of thinking aloud... along similar lines to my previous post....

Could it be set up in such a way, that the number control defaults to the %g, but if an xml tag (say <format></format>) exists, it could replace %g with %f, or %8.2f, %3.1f, and so on? I've not used sprintf in C++ much, but I've done similiar thing in php, perl, etc, etc...

Something like (pseudo coding):
format = "%g";
if formattag != "" {

<sanity checking>
format = formattag;
}
numToDisplay = sprintf(format, numberFromFG);

I figure there would need to be a fair amount of sanity checking, or specific values that translate into predefined sprintf formats.

By defaulting to the %g which is currently what is used, would hopefully mean no issues for existing rulesets that rely/expect this behaviour, and which is prefectly usable for most items, but an override could be specified for those few cells in a sheet where numbers could be expected to become very large (experience, copper coins... ;) )

Hoping to help,
-kirbol

[Moon Wizard]

I could do that, but that would put more burden on the ruleset developers. I'm thinking that I basically need to write my own ftoa() function that outputs floating point numbers into the format I expected.

The only tag I think might be worth adding is one that forces a number of decimal places to be visible when not editing. I'm not sure if that is even worthwhile though without a specific ruleset that requires it.

Cheers,
JPG

[kirbol]

I was thinking more for large integers... Currently if I type a number of say 1234567, the field displays 1.23456e+006

Another instance was in weight calculations. The encumbrance in Earthdawn is calculated in lbs, though some items weight in as ounces. While entering these, I converted them to decimals. Lua did some strange things to these, so I had to add a rounding function to some, or end up with 1.237272834 type numbers.

Being able to specify that I only wanted 2 decimal places simply would have been very nice, I ended up having to put in a script that cleaned up and rounded the decimals to keep the display reasonable. (seemed to happen most often with 10oz, 0.63 lbs items..)

-kirbol

[Czarisyn]

I had this issue before when one of my players decided to type a large number in the experience field. I ended up having to edit the db.xml to fix it.