Icons are able to have certain icon_states labeled as movement states. These special animations play when an atom is moving around the map. Since movements can happen at any time the movement animation doesn't always start on the first frame, it remains looping in the background and pops in at whatever frame according to the global frame counter.
This has worked just fine for most BYOND games over the years. Player sprites usually have a 4-frame walking animation, two frames of the character standing straight with the other two frames having either leg extended. It doesn't really matter what frame these animations start on because they look the same either way.
This isn't the case with more complicated animations. Walking cycles with a full stride or long animation sequences look very awkward when starting mid-step. What I'd like is a way to force movement animations to always start on the first frame of their animation sequence.
I realize this may break older games which is why I'm submitting this as a feature request rather than a bug report. This would probably be easiest to implement as a global setting, but it doesn't really matter to me how it's accomplished. As long as it's in I'll be happy.
ID:120775
 Nov 4 2011, 8:13 am
|
|||||||
| |||||||
|
Nov 5 2011, 5:41 am
|
|
El Wookie
 |
Would the movement states also be added as a variable, so we could dynamically set a player to something like movement_state[3] in the case of player-broken animations (Such as turning quickly on the spot).
|
If it was a simple true/false setting which caused the animation sequence to reset whenever changing directions that would fit in just fine.
Anything else would probably be outside of the scope of this feature request. | |
It was a long stretch, but I can live without it. Regardless this is a good idea.
| |
I completely support this request. I have had a few projects in the past where this drove me nuts.
| |
So, any chance of this getting added in? It would really help me out a lot.
| |
I completely agree. This is something that has bugged me since I started using DM back in '04. What's the point of even putting the animations in order?
| |
I've ran into another real-world use case for this feature which made me think it over again.
I have a flamethrower weapon which shoots out fire projectiles. The visual effect is they're sprayed out of the gun quickly as small flames which bulk up in size as they travel away from the weapon. It looks kinda okay right now but it could look much better if this feature was added. What I do now is set the icon_state to the loop animation and flick() the intro when the flame projectile spawns. What I would like to do is have the loop start from the first frame of the loop rather than a random frame out of the four depending on what server tick it is. To do this the feature would have to be able to start any animation on the first frame rather than just movement animations. The simplest way for developers to make use of this feature would be to have it toggleable for each individual icon_state. | |
I've wanted this for a long time, although I would rather have it able to start an icon animation from any state (flick(target, state, frameNumber)) instead of just the beginning one. Either way, I support this.
| |
DivineTraveller wrote:
(flick(target, state, frameNumber))flick()'s argument order always annoyed me. Almost everything else takes the atom being affected as the first argument, but flick takes the icon_state first, and then the Ref. | |
I believe flick() is supposed to be structured similar to view() where you could just use flick("animation") just like view(5) and not have to worry about putting src there.
| |
error: flick: expected 2 arguments (found 1)
It's a global proc, you have to provide an object to change. | |
Well, I guess that explains that. I guess DT's idea of flick(target, state, frame) would be a nice change.
| |
Doing that would break many games, however. If the change could be implemented as an optional thing, that would be great. If we can use DM to tell if an argument is an object or a text value, I'm sure that the compiler can (Although I know nothing about making a compiler, I'm just going off of what makes sense to me). Make the order unnecessary and it would solve the breaking problem.
| |
it would not break anything;
currently the syntax is: flick(Icon,Object) if you change it to flick(target, state, frame) all the compiler or whatnot would have to do is check if args[1] is is an icon or text string; use the first syntax if it's an atom, try to use the second syntax. | |
Super Saiyan X wrote:
it would not break anything; This is essentially what the end of my last post was suggesting. | |
theoretically, it could also be
flick(icon/state, target, frame) flick has always allowed either an icon or a state for the first argument; object/target as the second, so only a new third argument would be needed, and nothing else would have to be changed. there is also the possibility of named arguments, where the order would not matter, but the arg names would. if Lummox/Tom would go through the hastle of adding support for it. flick(icon = 'poop.dmi', icon_state = "smelly", target = src, frame = 3) | |
I would like it if every time you set the icon_state of an object, that icon_state's animation played from the first frame. I've had a ton of trouble with this.
Let's say you have a ten frame animation for an attack. You can could set the icon_state to the animation and watch it play from a random state. Or, you could use flick() to play it in order, but then you have another issue. What happens if the attack is interrupted at frame five, or three, or shit, one? There's actually another issue, one that I reported in the old bug reports forum quite a few years ago. flick() doesn't play animations to players that are not currently able to see it. Meaning that if I flick() a long animation of a girl dancing, someone who's walking around, and walks into view of the girl, will not see the dance. Honestly, I just wanted to throw my rant out here because I'm starting to have troubles in animation again. | |
That's a pretty complicated issue, Hiro, but I can see how it's related to this. If you broke the problem down to its core components you'd probably have to: 1) Begin flick() at any frame of an animation 2) Have the server be aware what frame flick() is at for every animation going on and 3) Inform new clients which frame of flick() the animation is at then begin flick() on their end.
Seems like a simple thing to add once this feature is in. All the server would have to do is keep track of flick() animations then make use of this feature any time a client walks in view of a flick() animation already in progress. | |
It's always annoyed me. Having an eight frame animation for movement, there is no -good- way to use it. It starts on a random frame. If you try to flick() the movement, you have no way to stop the animation when you stop moving.
| |