Reply to Re: AI & Missiles
If you don't have an account, just leave the password field blank.
September 28th 2011, 11:51 AM
shevek
While this wait is in progress, any hit/talk/push the sprite triggers will stop the callback from occuring.
Now I suddenly understand what Seth means in DinkC.txt where he (and the annotator) writes
Same as say_stop, but will not let the PLAYER skip things by hitting space
- if the player may be talking to someone else while this is called, (like
two girls talking in the background) you should use this...
[Seth's explanation up to this point makes perfect sense. But then he goes
on to say:]
...it is safe. Otherwise callbacks may conflict.
[This part is totally enigmatic. What does he mean by "callback" in this
context? What would be "unsafe" about two girls talking in the background?
Oh, never mind. Maybe I just answered my own question...]
[Kidding, ladies, I'm kidding. Sorry 'bout that.]
The unsafe part would be that a callback into the script is required when pressing space to make the girls continue talking, and another one when for the other conversation you're trying to have. I think Seth was a bit confused anyway, as this doesn't seem to be a particularly good example for the problem, but I think I finally understand what problem he's talking about.
The equations are easy to derive with simple algrebra but the problem is the exact equations cannot be solved with Dink's fixed point integers.
Not sure how easy it is to implement in dinkC, but in general, you should remember the starting point and the intended target (which is static if you don't want homing; if you do, things are much more complicated in a way (and easier in another)), and for performance also the total distance between them (sqrt(a**2+b**2), eh, yes, that's a square root... an approximation will do, I suppose...) Then every step you need to compute the next position: fraction=current_distance/total_distance; pos=pos_begin+(pos_end-pos_begin)*fraction. Don't forget to multiply at the start and divide at the end, to simulate using fixed point instead of integer computations. Otherwise fraction is always 0.
Once you know the current position and the position for the next step, and you know how to move in arbitrary directions, things should be easy to make.
Now I suddenly understand what Seth means in DinkC.txt where he (and the annotator) writes
Same as say_stop, but will not let the PLAYER skip things by hitting space
- if the player may be talking to someone else while this is called, (like
two girls talking in the background) you should use this...
[Seth's explanation up to this point makes perfect sense. But then he goes
on to say:]
...it is safe. Otherwise callbacks may conflict.
[This part is totally enigmatic. What does he mean by "callback" in this
context? What would be "unsafe" about two girls talking in the background?
Oh, never mind. Maybe I just answered my own question...]
[Kidding, ladies, I'm kidding. Sorry 'bout that.]
The unsafe part would be that a callback into the script is required when pressing space to make the girls continue talking, and another one when for the other conversation you're trying to have. I think Seth was a bit confused anyway, as this doesn't seem to be a particularly good example for the problem, but I think I finally understand what problem he's talking about.
The equations are easy to derive with simple algrebra but the problem is the exact equations cannot be solved with Dink's fixed point integers.
Not sure how easy it is to implement in dinkC, but in general, you should remember the starting point and the intended target (which is static if you don't want homing; if you do, things are much more complicated in a way (and easier in another)), and for performance also the total distance between them (sqrt(a**2+b**2), eh, yes, that's a square root... an approximation will do, I suppose...) Then every step you need to compute the next position: fraction=current_distance/total_distance; pos=pos_begin+(pos_end-pos_begin)*fraction. Don't forget to multiply at the start and divide at the end, to simulate using fixed point instead of integer computations. Otherwise fraction is always 0.
Once you know the current position and the position for the next step, and you know how to move in arbitrary directions, things should be easy to make.
