I’ve got a hub of transition markers set up at the beginning of an event. A “start” parameter with a range of 0 - 1 is defaulted to 0.50, and is also randomizing 100%. This hub throws the playhead elsewhere on the timeline in order to play a random ambient track.
If “start” = 0.00 - 0.33, go to A.
If “start” = 0.34 - 0.65, go to B.
If “start” = 0.66 - 1.00, go to C.
Out of curiosity, I set the parameter manually as 0.335, so as to land “outside” the ranges I’d set up. Sure enough, the playhead ignores all the Transition Markers.
I think this happened once during actual playback in-game, but I can’t be sure. It’s an extreme edge case in terms of randomness, but still I’m curious what decimal place the random value rounds to. Should I just set it up like…
Parameter values are stored as floating point variables, and so the number of decimal places they use varies. (If you’re not familiar with floating point arithmetic, the short version is that it involves storing the location of the decimal point separate from the significant digits of the number; As a result, the more pre-decimal places a number needs, the fewer post-decimal places it is calculated to.) In the case of a parameter than runs from zero to one, as in your case, parameter values will always be calculated to seven decimal places.
Your proposed solution should work just fine.
Incidentally, when there are two active transition markers at the same timeline position, the one that is in the ‘higher’ logic track position takes precedence. In the event shown in your screenshot, A is highest, and so will always take priority when active, even if the other transition markers are also active. I therefore recommend removing the parameter condition from C; It is unnecessary (as the cursor will only ever transition through C if it fails to transition through both A and B) and allows C to catch edge cases where the parameter has a value you did not expect, as in your “0.335” experiment.
