ID:260196
Jul 15 2006, 4:22 am
|
|
I find it quite annoying that when you use flick(), the program does not wait untill the icon has ...flicked, why not make it like Alert()? If it is done flicking, then the code continues its execution.
I understand that this could work against several programmers, so why not make it optional. Something like flick(icon,obj,wait=0)(default being 0). Because there are quite some situations in which I (and I doubt I'm the only one) don't want the code to execute while the icon is not done flicking.I don't see the harm of this, so I hope it will be added! O-matic | |
|
Jul 15 2006, 4:53 am
|
|
Airjoe
 |
in the meantime, you can sleep() for the amount of frames in the state times the delay between frames.
|
Why can't you just sleep the amount of time the animation is? sleep(frames*delay)
| |
That used to work great, until someone came up with the bright idea of making animations work on like 1/12th seconds or something that isn't in sync with the tick rate.
| |
Last time I tried that, it appeared that the duration of one frame is not entirely exact the same as one tick...
O-matic | |
Along with my other post, I'm not sure if the animation speed is actually different from the tick rate (I recall reading a post about their changing it a long time ago but can't find it now), or whether its just that animations are client-side and ticks aren't... well, what it says here: ID:217762
| |
It can't possibly work because flick() is a client-side visual effect, while you're talking about making the server wait. The best you can do is make a guess as to how long it will take the client to complete the effect based on the number of frames in the animation. But even then, there may be unanticipated lag which makes the client finish late, or even early if the server is lagged.
If we made the client send a message back to the server to indicate that it's finished the flick(), the same problem still applies. There will be at least a partial-second lag depending on the latency of the network connection. It's very easy for developers to handle this in DM, achieving results at least as good as anything we could implement as part of the language. If you want the icon to have a new state after the flick is done, simply set that state immediately after calling flick(). The client will continue the flick and then set the icon to the new one you specified. If you want something to programmatically happen after the flick, just insert a sleep() call immediately afterwards. This isn't any harder than inserting a wait= parameter to the call itself, and it gives you more flexibility. | |
Mike H wrote:
This isn't any harder than inserting a wait= parameter to the call itself, and it gives you more flexibility. Not only that, but you could actually program it in yourself if you still wanted the wait bad enough. proc/flick_wait(icon, object, wait = 0) | |
Unless you change the animation delay for the icon, they are supposed to be pretty much the same, yes. Although, as has already been said, a tick is not completely reliable and is not always exactly a tenth of a second.
| |
I say you listen to this guy, Mike. Or at least literally twist the arms of the people working on the Dream Maker/Seeker so that they do it.
And don't stop just because they give in; keep going until their arms are red. That will teach them not to wait so long next time we need something. | |
Too bad this cannot be added. sleep() Will do fine then, I guess. Thanks for the information.
O-matic | |
In the old days, way back then, the animation rate was in fact not synchronised, but that bug was fixed. The funniest part is, after the fix, a lot of people complained that their animations were faster because they were animating at their proper speeds. ;-)
My testing yielded 1.4 seconds per 10 frames (hosted locally, 0% reported CPU usage) before the inconsistency was fixed. | |
