Only with onboard symbol timeline, symbol action and key frames
@jonathan As I also started playing with the ideas in Decorators I suddenly realized that Hype itself offers many possibilities to override out of the box. One has to fiddle a bit with the key frames and timeline in the Symbol. Mainly create a symbol timeline for a named symbol override and record changes on the first frame of said timeline. On the main timeline one now uses the symbol action to choose the override. The only thing after publishing the runtime seems to be buggy and not render the desired outcome. The Hype IDE preview is fine, though. So, that great built-in potential is not usable or am I doing it wrong?
I moved some things around, tried a few things (I did see that the Symbol action didn't trigger on preview) but then when I put it back to how you had it, all of a sudden it worked. We'll see if we can dig into why this isn't reliable.
I am sure this is not really new though, I thing we or myself anyway just preferred targeting the timeline via JS, so this way just gets overlooked. It is useful in itself though.
Yeah, would be interesting why it didn't work for me… but when it works (reliable) it basicly offers everything for Symbol Overrides native in the IDE. That is pretty fascinating and as demonstrated it allows to use further timelines to have shared animations etc. So, the rule of thumb to manager which properties are for overrides and which are for shared actions. Even easier is to dedicate layers for override and groups holding them for shared actions and name them accordingly.
See how both now share a "wiggle" timeline but have distinct override states.
Including color rotation and inner HTML. I even triggered the wiggle with a slight offset to show that triggers are independent of each other even states are shared. Not a single line of code needed.
Me too… as seen. I love coding, but this serves as a reminder that much is already in the grasp of the regular IDE specially for the "No Code" fraction here and to myself when being quick at some lines of code rather than looking at what is there already. That said, Symbol Override and Decorating (week) is far from over… as code has many benefits too.
Interesting approach too! I don't think I had strongly considered using the symbol actions as property setters like this before. It probably works best when there are a few, known-ahead-of time, items to override.
When I look at your original document, it appears that the main timeline of the scene has both symbols instances set to have their symbol action run the main timeline. I'm pretty sure you meant for one of them to run a different timeline. (At least there's nothing I see that even triggers the Scene's Override timeline?)
One thing I ran into is a strange behavior in Hype. When I override some values in a symbol timeline and then go back to the symbol main timeline and change the same value (lets say visibility) it inverses or breaks my override set in the other timeline. Does Hype actively go in there and do some "Clippy" magic? Please, don't.
The final issue you hit at the end where the keyframe changed value is a sort of bug.
As a conceptual review: When modifying properties, Hype has "on keyframe" and "off keyframe" behaviors. If your playhead is over a keyframe when you modify a property, then it only adjusts that keyframe's value and nothing else. If the playhead is off a keyframe, then it will offset every keyframe's value across every timeline by the amount of change.
The question comes about: when "off keyframe" how do you offset a non-scalar value like the on/off display (or other items like a border style or text alignment)?
When faced with this decision in the early 1.0 beta days, for whatever reason, I thought maybe the first keyframe of other timelines should be replaced. Perhaps it was under the notion something was better than doing nothing to try to be consistent with scalar values. I suspect the thinking was that it should change the "initial value" and therefore needed to also change the initial keyframe (perhaps not thinking about the affect on multiple timelines). My comment, still in the code, illustrates that I did not know what to do:
//!! I'm not positive setting the first frame makes complete sense
Generally I only use //!! for the very rare times when I need to revisit something later (which I guess is now).
There weren't many non-scalar animatable values in earlier versions of Hype, so this oddity probably didn't matter much.... until Display was introduced in v3.5.
Secondarily to that all, Hype's notion of animations is that there's a start and end keyframe, so there may be a few other quirks in behavior when there's just a solo keyframe on a timeline.
Generally I only use