Pixel Crushers Forum

Hi there,

This is not a big deal, but I'd like to know if there's a way to get the output I'd want.

I'm using [var=xxxxx] to get the value of a number variable in some debug dialogue text.

Let's provide some images...:




Now, seeing that above, I'd figured I'd get a "66.67%" text, right? But I got this instead:



And I can't figure out why this is happening. I mean, the Watcher is already saying it's 66.67, and I'm pretty sure the value is that before DS reached that dialogue entry.

Any clues? Maybe it was fixed after my version?

Hi,

The Unity editor is probably shortening the 66.669999... to something that's easier to read, but the C# code in the [var] tag is giving the accurate floating point value. You can format it to 2 decimal places by using the [lua] tag:

AngryPct=[lua(string.format("0:N2", Variable["CurrentDay.Customers.AngryPct"]))]

I didn't tell you I'm already making the rounding with a PlayMaker action, before setting the DS number variable...:






So that 66.67 value is supposed to be legit. It's what I'm passing to DS as a Float.

But to make a cleaner test, I've made a video that shows it's still happening even when modifying the value directly at the Watcher tab:



Sorry about the resolution, but you will be able to see that there's a long stream of trailing decimals even when I set the value to 66.6. Only when I make it an integer (66) the unwanted decimals disappear.

It's important to note that those lines on-screen are the result of setting the TextMeshPro text component to the output of a Get Variable action as a string. That is, it's getting the current value in the Var[] table, after it's changed to 66.6 or set to 66.67 by the above PlayMaker actions. That's why I said I'm "pretty sure" the value I passed to DS is 66.67.

Also, after I made this video I tried adding more sixes but the Watcher tab ignored the sixth onwards. That is, the value read 66.66666. However, I still got trailing decimals at the end.

In short, it as if it never accepts that a number with decimals could have a finite number of them and always modifies the value in the very var[] table.

Of course I'm not sure about all this, but only showing you the weird behavior in the hopes of finding out what's happening.

Now, it's not that I need atomic precision with these things, but if I store a 66.66 float in DS, it's gonna be important it respects the two decimals instead of converting them to .5999..., because if afterwards I check if that number if 66.66 or more, I'll receive a false instead of a true.

It's very situational, granted, and now that I'm aware of this I'll try to take it into account, but I'm still curious about why this is happening.

Thanks.

Edit: I have other variables with decimals that don't experience this issue...:



...so this must be a very specific problem. Maybe I'm even causing it on my side, tbh. So let's not throw too much time into this. You have better things to do than troubleshooting my game.

I suspect this is happening because the Dialogue System's Lua implementation uses double types, but Unity uses float types. The process of converting between doubles and floats may be introducing a little bit of floating point drift. (This is the reason that Unity's C# API has a Mathf.Approximately() method, to check for approximate equality in case of slight drift.)