[Solved]Issue with Actuate (rotation) if -final flag used

Hello, I found a bug with actuate when I use the -final flag (HTML5 compilation).

Take a look at this simple example (click in any number to display the animation):

Without -final

With -final:

As you can see when I build it everything tweens ok except for rotation.

the actuate command used is:
Actuate.tween(panioApuestas, 1.3, {x:504, y:510, rotation:90, scaleX:0.65625, scaleY:0.65625} ).ease(Linear.easeNone);

Any help would be appreciated.


Maybe you should open a bug report? https://github.com/openfl/actuate/issues

-final does DCE (dead code elimintaion), and Haxe can remove unused properties.
Is panioApuestas regular Sprite, or custom one?

For custom one try to add @:keep meta to rotation property.

Thanks. Yes, it is a custom one. I tried to add


before the class definition but with no luck. Am I doing right?

Best regards

Made a coupple of tests more. I set a rotation of 10 to the “panioApuestas” sprite, to make sure it will be a used property. It makes the initial rotation correctly but when It makes the tween thru actuate it ignores them completelly.

Any other ideas?


I’m not sure, but probably @:keep(openfl.display.Sprite.rotation) will not work as desired.

I set a rotation of 10

For non-flash platforms rotation is actually getter and setter. By setting rotation to 10 you keep just setter, but Actuate need both.

Try add following:

#if !flash

override private function get_rotation() : Float {
    return super.get_rotation();

override private function set_rotation(value : Float) : Float {
    return super.set_rotation(value);


looks ugly, but I don’t know better way.

Magic…!!!seems to work ok now!!!

Thanks a lot!!

Best Regards

Hey guys, any recommendations for a solid fix? Should we just @:keep DisplayObject, or something like that?

As far as I test, there are no problem with actuate and position and scale. Only with rotation, so as simple solution I will add @:keep for rotation in the displayObject class. Not sure if using macros you should be able to evaluate which properties are needed by actuate and keep only that ones. But that exceeds my knowledge with haxe (for now ) :slight_smile:


Hi guys,
Any cleaner fix issued for that problem?
I’ve been running into the same problem today, but this time with a classic openfl Sprite, not a custom one.


EDIT: I can make it work by setting my Sprite rotation to its own rotation + any value, then setting it back to 0, but that’s definitely an ugly workaround :smile:

An alternative is to add this somewhere:

@:keep private static function callGetterAndSetter():Void {
    new Sprite().rotation += 0;

By calling the setter, you let DCE know not to remove it. You don’t even need to call callGetterAndSetter() at runtime; it just needs to be there at compile time.

The alternative is to open up DisplayObject.hx, and add @:keep above the class declaration.

Ok thanks for the answer !
I figured out something like that might work, I was just looking for something cleaner and in a more centralized place :slightly_smiling:

Wouldn’t it be nice to have a dead code elimination list of packages we want to keep or that we absolutely don’t need?
We would specifiy there classes or packages that we know we need / don’t need and the dce would parse that and act accordingly…?

You can use initialization macros for both things. Normally you’d add them in the command line, but I think in OpenFL’s case, you’ll be able to use a <haxeflag /> tag.

To stop DCE from removing a class:

--macro keep("openfl.display.DisplayObject")

To prevent a class or package from being generated, potentially causing compile-time “type not found” errors:

--macro exclude("openfl.media.Video")

For more information, see the list of available functions.

1 Like

That is helpful, thanks a lot ! :slightly_smiling: