ID:134241
 Jan 9 2007, 1:48 am (Edited on Jan 9 2007, 1:57 am)
|
|
Right now, as flick() covers up the used atom's icon state, there isn't a way to stop flicking and "uncover" it (I don't think). Couldn't there be a way of stopping it by using something like flick(-1, src)? It'd help a lot for games that use flick() a lot.
| |
I'm not sure, as I'm not familiar with flick(), but I believe you can cancel it with
flick(null,usr) | |
Well, I was probably wrong when I said a lot of games would need it. The reason I posted was really because of my new game that uses a lot of long animations that need flick() to work. It's a platform game, and it uses flick() as soon as the character falls, but if the character hits the ground while it's still flicking, then I'd want to cancel it. I actually tried using flick(src.icon_state, src), but if you're moving while the icon state's animation ends, then it resets at a random (well, not exactly random, it's just how far the user's client has got with the frames) point in the animation, causing it to jump as few frames.
Anyway, I guess you're right. I should really be coding it in myself, it's just that I thought it'd help my game and maybe even a few others. (Also, I don't think I have flicked more than once per tick, because flicking more than once per tick wouldn't do anything, because you can't make animations last for less than a tick anyway.) Edit: And falling isn't the only thing that uses flick(). Jumping does too, and whenever I'd want to glide (which changes the icon state), it'd still be flicking the jumping state. I would also have the problem with hitting the ground, because I'd bounce back down if I hit a roof while jumping, and if the roof is low, then I'd hit the ground almost instantly. | |
Are you using a movement state? You might considering using a flick instead of a movement state (see http://www.byondscape.com/ascape.dmb/ Shadowdarke.2002-0330/#AT; I personally hate movement states.)
As soon as you flick a second state it will override any previous flicks(), except if the icon_state is "" and you flick "". (I think the exception is a bug.) | |
Yeah, I am using a movement state. I guess I could use flick() for movement states, but BYOND moves the atom slowly while you're moving, so I'd need to have a certain amount of frames in my animation, otherwise it would mess up (although I haven't looked through the code on the page you shown a link to yet, so I may be wrong). And yeah, I know that flick() can cover up other flicks, but that's only if you're flicking an actual icon state. I think it'd be easier if you could use it without an icon state to flick, because that'd make more sense if you could cancel it.
(I guess a moderator should move this topic now, because it doesn't seem like the feature is going to be added, and it's kind of moving on to things about my own game now.) | |
It only "covers" the icon_state through one cycle of animation, so it shouldn't be a problem at all unless you are flicking a very long animation.
[Edit: Oddly enough, this works for any icon_state except for "".]
I've never seen flick() become a problem in a game. Are you calling flick more than once per tick for an atom?