sp_kill_wait() - broken?
Maybe this is just Dink Smallwood HD but the command
sp_kill_wait(sprite);
doesn't seem to really do what it is supposed to, which is don't wait for anything for that sprite - usually number 1, Dink, and is usually used in magic or item scripts for spells or weapons animations.
But I've noticed sometimes that the missile sprite is created and off flying before the magic/hit animation even starts. This anomaly doesn't occur every time, but enough to be annoying.
I don't remember seeing this in the old game engine, but maybe it was there back 20+ years ago.
Or maybe it's my scripts, but I'm pretty sure I've seen this with the standard fireball magic, which I haven't changed.
sp_kill_wait(sprite);
doesn't seem to really do what it is supposed to, which is don't wait for anything for that sprite - usually number 1, Dink, and is usually used in magic or item scripts for spells or weapons animations.
sp_seq(1, &basehit); sp_frame(1, 1); //reset seq to 1st frame sp_kill_wait(1); //make sure dink will punch right away sp_nocontrol(1, 1); //dink can't move until anim is done! &magic_level = 0; draw_status(); &mholdx = sp_x(1, -1); &mholdy = sp_y(1, -1);
But I've noticed sometimes that the missile sprite is created and off flying before the magic/hit animation even starts. This anomaly doesn't occur every time, but enough to be annoying.
I don't remember seeing this in the old game engine, but maybe it was there back 20+ years ago.
Or maybe it's my scripts, but I'm pretty sure I've seen this with the standard fireball magic, which I haven't changed.
Not sure if the bug you mentioned is indeed DinkHD specific, but I believe it might have been fixed in TheNewGuys script improvement pack. Might wanna test that(I think it's a small demo mod so you can test it without replacing the scripts in your Dmod), and check if it is indeed fixed. Then can just grab whatever it change he made to fix it. I recall thenewguy saying he fixed a delay that shouldn't be there with animations and such.
Thanks, I think that fixes it... well for me at least with item-fb.c as I can easily add x3 new global variables for the script to work and add the new improved fireball spell script without any impact.
My other scripts are a bit of a mess, so not sure if I want to mess with them, but I will see in the final test/run through I plan to do for the ReDux version of SOB before its release in the next week or so.
I also noticed on Seth's website that HD version of the engine now supports 1300 sprite slots and unlimited SET_SPRITE_INFO lines, which is nice to know.
My other scripts are a bit of a mess, so not sure if I want to mess with them, but I will see in the final test/run through I plan to do for the ReDux version of SOB before its release in the next week or so.
I also noticed on Seth's website that HD version of the engine now supports 1300 sprite slots and unlimited SET_SPRITE_INFO lines, which is nice to know.
Funny thing is a while ago I tested spawning a sprite in main.c to use init to declare a bunch more set_sprite_info lines and it seemed to work with no issues. Just couldn't have extra ones over the limit in dink.ini or they were ignored. Lol.
The DinkC reference states "The wait time is the internal counter that determines when the next frame of animation will be displayed" which is flat-out wrong, as the time when the next frame appears is of course determined by the "frame delay" parameter.
Instead, it relates to the "timing" value, which the reference states is the interval when the brain functions will next be called. This is set to a random value for ducks and pigs to make them idle a bit after they've been walking.
The easiest way to see what "timing" does is to set it to something large like 5000 or more on a brain 6 sprite, which will then wait at the end of its sequence for 5 seconds before restarting. If you were to set the wait timer to zero during this interval with kill_wait, it would start animating again, overriding the timing value.
thenewguy writes about it here, and says it doesn't do anything, which is true, as by default the player sprite has no timing value set. I can't think of any reason why it was used in the original scripts at all. The best attempt at an explanation is in BigTed's annotated dinkc.txt:
[This explanation is pure nonsense to me. I have no idea what it means or
what this function does. Nor does looking for example uses of this command
help. The only example I can find is this line in every weapon's item-xxx
script: sp_kill_wait(1); //make sure dink will punch right away
If this command were not there, under what circumstance might Dink not "punch
right away?" If anyone knows, I'm listening.
Instead, it relates to the "timing" value, which the reference states is the interval when the brain functions will next be called. This is set to a random value for ducks and pigs to make them idle a bit after they've been walking.
The easiest way to see what "timing" does is to set it to something large like 5000 or more on a brain 6 sprite, which will then wait at the end of its sequence for 5 seconds before restarting. If you were to set the wait timer to zero during this interval with kill_wait, it would start animating again, overriding the timing value.
thenewguy writes about it here, and says it doesn't do anything, which is true, as by default the player sprite has no timing value set. I can't think of any reason why it was used in the original scripts at all. The best attempt at an explanation is in BigTed's annotated dinkc.txt:
[This explanation is pure nonsense to me. I have no idea what it means or
what this function does. Nor does looking for example uses of this command
help. The only example I can find is this line in every weapon's item-xxx
script: sp_kill_wait(1); //make sure dink will punch right away
If this command were not there, under what circumstance might Dink not "punch
right away?" If anyone knows, I'm listening.
That description of sp_kill_wait was carried across from the old DinkC ref, I haven't changed it.
EDIT: removed this part cause it was wrong, I was thinking of sp_attack_wait
EDIT: removed this part cause it was wrong, I was thinking of sp_attack_wait
In that excerpt by BigTed, I omitted the original Seth-written description of it:
This is the delay created by sp_kill. Sometimes you want to change this to
0, so a sprite will react immediately.
Which is also wrong, as it never intersects with the kill timer at all...
A wild development process Dink's must have been.
This is the delay created by sp_kill. Sometimes you want to change this to
0, so a sprite will react immediately.
Which is also wrong, as it never intersects with the kill timer at all...
A wild development process Dink's must have been.
