Parameter Velocity bug?


I’m trying to have a parameter go from 1 to 0 automatically when the event is triggered. Therefore, I’ve set the “Initial value” to 1, and I’ve set the “Velocity” to -0.50/s. This makes the parameter go from 1 to 0 over 2 secs, and it works fine in the event editor. However, when testing it out in game and the sandbox, the velocity doesn’t seem to be doing anything, and the parameter value holds at 1. “Hold value during playback” is not checked. Am I doing something wrong, or might I have found a bug?

I’m using Studio version 1.10.11.


Hi Sean,

Velocity is applied once the event instance is started. How is the event instance started? Is there anything else setting the parameter? Can you capture a profiler session of this happening and see if you can see if the parameter value is being set or if the velocity is kicking in sooner than you think.


Thanks, Richard. I did a profiler capture of the event playing in the Sandbox, and the parameter appears to behave correctly the first time I trigger the event. But, if I hit stop in the Sandbox (double or single click), and then hit play again, the parameter starts/holds at its destination value of 0, instead of starting at 1 again and advancing to 0 (at -0.5 units/sec). If I “remove” the event from the sandbox, and then trigger/re-add it, it behaves correctly again.

I should note that, for either scenario, I don’t see the parameter change in the Sandbox. I.e. when the profiler shows the parameter changing as expected, the Sandbox does not. Should it?

If what I’m seeing in the Sandbox/profiler is expected, is there a way for the programmer to trigger an event such that it will behave like how it behaves in the Sandbox (i.e. when I triggered it the 2nd time without removing it)? I’ll check how our programmer is triggering the event, but I don’t believe they’re doing anything special. I’ll also double check that they’re not manipulating this parameter, but I asked them to simply read the value and pass it to another event.


Hi again, Richard. The programmer looked into this further and discovered that they needed to use EventInstance::getParameterValue to obtain the parameter value (that was being modulated by the velocity). They had been trying to use EventInstance::getParameter to get a ParameterInstance and then ParameterInstance::getValue, but that approach didn’t return the ‘final value’, just the ‘user value’. Whereas EventInstance::getParameterValue returns a ‘final value’. So things seem to be working correctly now.

Aside from that, I’m still curious if the Sandbox behaviour is as-intended?

Thanks again,

It looks like the profiler has an issue with correctly displaying parameter values when using velocity. And you have mentioned that you needed to get the final value (user value is the value that has been set, final value is the value that is currently is taking automation, modulation, seek speed, and velocity into consideration).

The behaviour in the sandbox is a little bit different from the behaviour in a game. I have raised a bug in our tracker to get it fixed as this should be as close to the runtime behaviour as possible.

Thanks, Richard.