Feb 4 2014, 2:47 am
In response to Ter13
|
|
Albro1
  |
My intended purpose was exactly for once-through animations, as explained with my "attacking" example. I wouldn't want walking to be sped up as much as I may speed up their attacking (Although I suppose you could only change this variable in question when attacking and then change it back, but that seems like it could crop up some issues).
|
+bump
| |
Bump, I'm still really hoping for this one.
| |
Just replying to say I do support this addition. Seems like it would be useful.
| |
Bump again. :o
| |
Bumping this again. Still waiting for Lummox to take notice and hopefully pitch his comments in! :)
| |
I'm programmer and I agree.
| |
I suppose if this were implemented at all, Ter's suggestion of using an appearance var for scaling the time would make the most sense. Considering I'm already planning a batch of appearance features for 509, maybe that'd be sensible.
| |
So as far as just increasing the speed of the "attack" state, for example, we would have to resort to just increasing the speed of the entire atom's appearance, and have to calculate how long this change has to last based on how short the "attack" animation becomes from speeding it up?
Or am I just overthinking things, and it would actually be much simpler with appearances? | |
Doing this on a per-state basis doesn't make sense to me. On a per-flick basis I guess I could see it.
| |
Doing this on a per-state basis doesn't make sense to me. Playing repeating animations faster/slower, like running/walking animations? It'd be neat for a slow effect. Though, it'd require the client to know the entry time into the state for each state change rather than using the world timer. | |
Bump-a-rooni.
Could still do to see this implemented. | |