ID:1857904
 May 24 2015, 11:21 am
|
|||||||
| |||||||
I think it would be amazing to get some updates related to icons, at the moment we can not change an animation's speed while playing, I think it'd be great to create slow-motion scenes and so on, plus there's no way to get the time it takes for an animation to happen, I realize we can check that by ourselves but it'd be really helpful if we had something like that on BYOND.
| |||||||
|
May 24 2015, 8:59 pm
|
|
Oondivinezin
 |
I am all for this. I think there's some way to do it, but I wouldn't know how.
|
I actually tried to check if there was any proc to get an animation delay, but I found nothing.
If we could at least have something like that, and another proc to create animations with a specified delay, then we'd be able to customize animations delays in run-time, but that's not available. Anyways, Lummox has mentioned in the past that it's pretty difficult to update the way the animations work, however, it'd be really really helpful to achieve this, as many games would use that to animate stuff (effects, slow-motion scenes, buffs that make you attack/w.e. faster, etc). | |
Bump.
| |
Better reading of icons is definitely something I want to add, so that the server can interact with all aspects of the icon's format.
Altering animation speed at runtime for an existing icon is not on my list. | |
Lummox JR wrote:
Better reading of icons is definitely something I want to add, so that the server can interact with all aspects of the icon's format. What would be the point of obtaining the icons' frames duration if you can not alter them with another proc? | |
What would be the point of obtaining the icons' frames duration if you can not alter them with another proc? Rather than harcoding animation delays, you'd be able to interpret them from the icon itself, thus allowing you to change animation delays in the icon file without having to update your code. I agree though, animation control would be P sweet. | |
There's 3 ways to do this already and all of them are shit.
Way #1 is unraveling your movie into individual icon states and handling animations yourself by incrementing a counter and updating the icon_state var. This is slow and limited by world.tick_lag (from what i gather you cannot sleep for less than world.tick_lag) Way #2 is the same as #1 but with using animate, which is better because it'll do it clientside but with the downside that you can (to my knowledge) only run one animation on an object. Way #3 is using an icon proc to make your own movie-type icon_state and you can have full control over your frame delays but don't do that ever. even just an animation_speed var on things with appearance would be gr8 and seems like it would be a really simple thing to implement. | |
I know, I am not talking about making it so you can change the delay on each icon state animation, it could be all of them. But sadly BYOND doesn't seem to support that.
The other ways are quit laggy and can not be used within few seconds. | |
I've got a solution to this in my head that would be fairly simple.
The best animations are all set with the same fixed tick value for each frame. Smaller tick value = faster animation. So just having a way to adjust the animation value for all frames on an individual mob's avatar and only apply it to that avatar shouldn't be too difficult to manage. I'll try making something like that. Make a run function, where clicking it doubles my glide speed and drops my animation tick value by 1. | |
Bump.
I'd really like to see this feature request reconsidered. Without it things like movement speed and attack speed changes look ugly. You're either moving too slow/fast for the movement animation, and your attacks are too slow/fast for the attack animation. There are also many other things this would help improve. | |
Lummox JR wrote:
Better reading of icons is definitely something I want to add, so that the server can interact with all aspects of the icon's format. +1 | |
Bump
| |
super bump
specifically, I support adding a method to control icon state animation speed | |
Four years later, this would still be P sweet.
| |
I would like to alter animation speed in run-time, it would help me to place things in map like some effects, I could c see how better will fit in the map, because current map editor dont help me a lot with that, trying to make a run-time map editor, so I grab the informations and change in the real map editor
| |
Bump
| |
I wrote a proposal for roughly how the math/properties should work in a simplified backend.
I ran the idea by Lummox in BYONDiscord earlier today. Here's a copy of my demo environment testing the math I jammed out: Demo The client already keeps track of the last_touch time of atoms. In order to make the server control which frame an icon_state animation is on, as well as the play rate, the client also has to be told to track the frame that the icon_state was on at the last touch. The server should not be able to know which frame that an atom is currently on, but it should keep track of the current play_rate. Because only the client is really aware of the current frame an atom is showing, this introduces some challenges for implementation. Here's my first pass at detailing how this feature works from the developer end. atom Changes to atom.play_rate will internally notify the client that the play rate has changed from the current frame on the client. Changing atom.play_rate will affect icon_state animations only. Changing atom.play_rate in animate() will *not* interpolate. The changes will be instantaneous at the time of the animation step. Because the client is now aware of the frame that the icon_state is on, we should also be able to specify a change to that frame. For this, I suggest changes to flick() and animate(). flick(Icon,Object,Rate,Time) Flick()ing an object will only *temporarily* alter an atom's play_rate as a purely visual effect on the client. Time specifies the starting point in the icon_state we're flicking. animate(ref,state_time=4,play_rate=-1.0,time=0) Animate()ing an object will allow you to pass the starting time offset for the current icon_state alongside a change to play_rate, or no change to play_rate, or if you change the icon_state too, you can pass the state_time along with it. Changes to state_time only assume the object's current play_rate. Simplified backend math for state/frame changes: Calculating the current frame on the client: old: (world.time - creation_time) % state_animation_length new: var/delta_time = time - creation_time Changing the play_rate: creation_frame = getFrame(time) //see above calculation Changing the frame: if(new_frame<0) Changing the state (currently how touches work): state_animation_length = new_length | |
2022 and we're still waiting for this.
| |
bump
| |
