The duration of an event is always just that single frame for which it was keyed. However, events have properties that let you encode data
Events - Spine User Guide: Properties

You could simply set the integer or float property to the duration of the camera shake you want. Your devs can then read that value and apply it to the camera.

benny_benny escribió

I'm assuming that the number in the integer property represents the number of frames?

No, the integer field serves the purpose that you can pass a number to your own code. It still is a single event without any duration. You need to write your own code to do something with it then.

Perhaps an easier solution would be to have one event shake-start and one event shake-end following it, which you can then place precisely in the animation timeline.

Glad it helped, thanks for getting back to us.

I need to do something similar. However, in my case, having just a start and end event would be insufficient, as I need to exactly know what portion of the way through I am, like with a keyed interpolated property, even when adjusted for timescale, pausing, or anything else.

The context is that entities can jump or slide from its starting position to the targeted enemy as part of melee attack animations, and the game needs to know how far through the jump/slide it is so it can position the visual appropriately. (And I can't use some kind of constraints to do the whole movement through Spine, as there are things involved in the runtime outside of Spine). I can imagine other uses for such a durationed event as well, such as other visual effects that are handled in the runtime outside Spine.

One typical solution to such animation target adjustments like a jump to a custom target position would be to use root motion delta compensation. The approach is to scale your root motion bone's movement accordingly so that when you have setup your jump from x=0 to x=2, and want to jump to position x=3 instead, it scales root motion by factor 3/2 to end at the target position.

The spine-unity SkeletonRootMotion component provides a simple AdjustRootMotionToDistance method which adjusts root motion scale accordingly.
spine-unity Runtime Documentation: SkeletonRootMotion

goldenPiGames escribió

(And I can't use some kind of constraints to do the whole movement through Spine, as there are things involved in the runtime outside of Spine).

Cold you describe why you can't use a constraint here? It would be a common solution for such a task. A typical setup would be a jump target position constraint, which moves a position-base bone from 0 to the target position over time, by increasing the constraint mix value from 0 to 1 over the animation time. This would all be setup within the Spine Editor and can be paused and resumed at any time.

goldenPiGames escribió

Entities are positioned at varying x and y positions, so a linear scale wouldn't work.

But a bilinear scale would. That's why the RootMotion component offers independent root motion scale parameters for x and y. You need to animate your character with change in x and y direction (e.g. jumping right and up), then you can scale both axes via root motion delta compensation. A difference of 0 in y direction can unfortunately not be scaled to match any target value.

Using a positionable jump-target constraint as described earlier also should work well for this situation.

There may be other objects, like a particle effect that follows the player but is handled outside of Spine, so I'd need to know and control the base position

You could just use a normal BoneFollower component to let your particle effect spawn positions follow a target bone.

Harald escribió

component

I'm not using Unity. I'm using Ceramic, which uses spine-hx, which is "automatically converted from the official Java/libgdx runtime"

I see. Then I would suggest using the constraint-based solution described as an alternative above. You can separate the vertical part of the "jump-arc" (animated normally) from the horizontal movement towards the target, with the latter being done via animating the mix value of the transform constraint from 0% to 100%. The hierarchy would then have a vertical movement bone as child of the horizontal movement bone, the latter being controlled via the constraint that drags it towards the constraint-target. Then you can adjust the constraint-target as needed. This is one solution that comes to my mind, I'm sure there are other ways to solve this.