Decimal Display

Thanks for confirming! If you have any ideas about the best workaround to display 4 decimal places where the fourth is rounded, I’m all ears. I’ve seen people trying different ways to do this. 

Actually @matthew I just emailed you instead.

It is actually even more mysterious. Let's say you have your number you enter as 1.1399. Once this gets into the SL variable, it's rounded to 1.14. BUT it is not the actual number stored in Storyline, it is just the number DISPLAYED. 

You can test this by multiply the number (supposedly 1.14) by 1000 in JavaScript and you get 1139.9. That means SL keeps the actual 1.1399 number in the variable, it just doesn't show it.

So i wanted to figure out where exactly in Articulate's code the decimal's get rounded.
Unminifying and doing some tests in slides.min.js i found that in fact internally there is a spot where with multiple decimals is calculated.

At some lines this is set:
   S = function (t) {
       return parseFloat(t.toPrecision(7));
   };
And indeed when logging this you will see a 7 decimal precise number. Changing this to a higher number you will see internally Storyline calculates with that higher amount of decimals.

So now to find where this value is returned to and used ( and in the end converted to a 2 decimal one )
After some searching i pinpointed the spot where the conversion from the multi-decimal Number is changed to a 2-decimal Number...

At some point there is this code, a parseVars function...
  parseVars: function () {
    var t = this.props.model;
     return o.parseVectorText(t, this.updateVarText(t));
 },

Adding some code here to see what is happening...
    parseVars: function () {
        var t = this.props.model;
        var tVars = o.parseVectorText(t, this.updateVarText(t));
        var obj1 = JSON.stringify(t);
         var obj2 = JSON.stringify(this.updateVarText(t));
         console.log("parseVars: "+obj1+" |updateVarText: "+obj2);
      return o.parseVectorText(t, this.updateVarText(t));
   },

And you will notice that obj1 still has the multi-decimal variable in it... whereas after 't' has been worked on by the function 'updateVarText( )' it is changed to a 2-decimal variable and rounded.

I cannot yet find where that function does its work...but gonna dive deeper into it.

Well...now breaks my wooden shoe...that is a Dutch saying ( 'Nu breekt mijn klomp' ) stating as much as im perplex and very surprised by something... due to wooden shoes seldom or never breaking ;-)

Working some more on the decimal thing...
If you in your console run...

var player =GetPlayer(); player.GetVar("_player.testNum");

Being testNum your custom numeric variable you save the multiple decimal value into when entering it into a Numeric entry field...to my big surprise the console gives back your numeric entry with ALL decimals. Watch the _player in front of the testNum...

So clearly Storyline only changes it visually on the frontend. Developers really should fix this and give the user the possibility to use 2 or more decimals.

I would love to have the Storyline option simply to set the number of decimal points points you want to display, and whether or not to round up only, down only, or no rounding. Has anyone requested this feature for future development?

After reading several posts I wasn't sure if I should post a new topic or try here, but here I am.

Do any of these JS options allow for increasing decimal places on triggers with conditional values on numeric variables?

Made-up example:

User needs to input a measurement between .5005 - .5015. When they click next it will take them to one of three places, dependent on the variable entered (over tolerance, under tolerance, or in limits).

The problem I have is not that the the user inputted value is cut short or rounded, rather the conditional triggers only allow entry up to the second decimal place for numeric variables, so I end up with the following three trigger conditions: between 0.5 and 0.5, under 0.5, and over 0.5.

(I did type them in accurately to the forth decimal place in the trigger wizard and verified that on top of the displayed conditional value being rounded to the first decimal place in this instance, it also functionally rounds to this as well.) SEE ATTACHED FILE

Obviously, this rarely yields an accurate outcome. I have several applications that require accuracy up to the 5th and 6th decimal place and the inability to control this would unfortunately be a deal breaker for my use case.

Thanks for reading,

Adam