Speed built-in parameter question

[joseph]

@Wilhelm_Scream

I started wondering whether it was possible that the ‘relative to that of the listener’ part meant that the parameter took the Listener’s 3D attributes under consideration as well, but even though this makes perfect sense in, say, the Distance built-in parameter’s case, I failed to see how the Listener’s position would have anything to do with any other gameObject’s Speed. If that really were the case though, it might mean that the Speed value of my event would always be 0, as the Player’s feet, on which I had attached the event, stayed in the same relative position to its parent gameObject, which in turn contained the Listener.

That’s correct: “Relative to the listener” means that if the listener is moving in lockstep with the emitter, the speed parameter’s value will remain at zero.

@Wilhelm_Scream

I created a cube in Unity, and added some basic animation to it. Then I removed the event from the Player’s feet, attached it to the cube, and pressed play. The cube was moving (at different speeds and across all three axes), the feedback sound with it.

How exactly were you moving the cube in Unity?

If you used transform.position then the speed parameter remaining at 0 is totally expected, because that function doesn’t “move” an object so much as “change its location.” It bypasses Unity’s physics engine, and thus Unity’s calculation of object velocity, and so the object’s speed never rises above 0. Changing the location of an object this way is useful if you truly do want it to be in a different location without having to travel there - teleportation and motionless space-warping are features of many games - but it’s not appropriate for objects travelling through normal space.

If you want an object to have velocity, you need to move it using some function that works within Unity’s physics system, such as Rigidbody.position or Rigidbody.MovePosition.

@Wilhelm_Scream

On a side-note, why is it that built-in parameters cannot be global? That would come in handy if, for instance, other events needed to know the Distance/Elevation/etc of a certain event. And making that information global (without the use of code) cannot even be achieved indirectly, by automating a global parameter based on a built-in parameter, since global parameters “can only be automated by a global parameter”.

A parameter based on a global parameter is, by definition, set to the value of that global parameter. A built-in parameter is, by definition, set according to the 3D attributes of the event instance. A parameter cannot be both global and built-in because such a parameter would have to be set to two different values simultaneously.

You’re right that it might sometimes be useful to know the value of a local parameter globally. It’s already possible to get the value of a parameter via the FMOD Studio API, but I’ll investigate and see whether there’s any ways we might make this easier to use through FMOD Studio.