Custom procedures
Looking at these and getting my head around such things as local variables scope is excluded in custom procedures unless variable is defined in that exact procedure, plus the availability of &arg1 thru to &arg9 as parameters that can be passed to a custom procedure - you can only return a single integer value, right?
And if you use set_callback_random("procedure", xxx, yyyy); on a custom procedure you have to activate its own callback at the end of the procedure code, if you want it called again after the last call.
Although is "void target (void)" as used in the original en-drag.c a custom or a Dink Engine predefined procedure? As this doesn't call on itself at the end.
And if you use set_callback_random("procedure", xxx, yyyy); on a custom procedure you have to activate its own callback at the end of the procedure code, if you want it called again after the last call.
Although is "void target (void)" as used in the original en-drag.c a custom or a Dink Engine predefined procedure? As this doesn't call on itself at the end.
void main( void ) { int &fsave_x; int &kcrap; int &fsave_y; int &resist; int &mcounter; int &mtarget; screenlock(1); sp_brain(¤t_sprite, 10); sp_timing(¤t_sprite, 66); sp_speed(¤t_sprite, 1); sp_nohit(¤t_sprite, 0); sp_exp(¤t_sprite, 400); sp_base_walk(¤t_sprite, 200); sp_base_death(¤t_sprite, 210); sp_touch_damage(¤t_sprite, 10); sp_hitpoints(¤t_sprite, 80); sp_defense(¤t_sprite, 8); preload_seq(202); preload_seq(204); preload_seq(206); preload_seq(208); preload_Seq(70); preload_Seq(166); set_callback_random("target",500,2000); } void target( void ) { //get new target &kcrap = random(9, 1); if (&life < 1) &kcrap = 2; if (&kcrap == 1) { sp_target(¤t_sprite, 1); return; } &mtarget = get_sprite_with_this_brain(16, ¤t_sprite); if (&mtarget > 0) { &mtarget = get_rand_sprite_with_this_brain(16, ¤t_sprite); sp_target(¤t_sprite, &mtarget); } }
In the case of set_callback_random it will return the index number of the callback for ending it manually later on. Otherwise, it should run forever as per the specified interval so i'm not sure if I follow.
target() is not called from within the engine, and shouldn't be confused with the "target" sprite property which has no relation.
Also, there might be a bug in yedink in which returning a value from something like that causes a crash on occasion.
target() is not called from within the engine, and shouldn't be confused with the "target" sprite property which has no relation.
Also, there might be a bug in yedink in which returning a value from something like that causes a crash on occasion.
Yes, you can only return 1 value from a custom procedure. If you're calling a custom procedure you get &arg1 to &arg9, if you're calling via external you only get up to &arg8.
For the single return value thing, a workaround is you can save as many values as you want without extra variable use by using sp_custom values attached to Dink.
sp_custom("return1", 1, ###);
sp_custom("return2", 1, ###);
Etc...
Then retrieve whenever you want. There's no limit to sp_custom values. You can store as many as you want with Dink, and they'll survive screen changes. They just don't save with save game. They are also I think the only value you can set/retrieve in DinkC that is instance specific. Meaning they also survive through loading a save game... If you set a sp_custom value on Dink, load a save game and retrieve it, it'll be the value you set before you loaded. You only lose the "memory" of sp_custom values on Dink when the game is closed.
For the single return value thing, a workaround is you can save as many values as you want without extra variable use by using sp_custom values attached to Dink.
sp_custom("return1", 1, ###);
sp_custom("return2", 1, ###);
Etc...
Then retrieve whenever you want. There's no limit to sp_custom values. You can store as many as you want with Dink, and they'll survive screen changes. They just don't save with save game. They are also I think the only value you can set/retrieve in DinkC that is instance specific. Meaning they also survive through loading a save game... If you set a sp_custom value on Dink, load a save game and retrieve it, it'll be the value you set before you loaded. You only lose the "memory" of sp_custom values on Dink when the game is closed.
I'm not convinced that set_callback_random actually calls itself infinitely until the script that has it is killed.
I've been testing a callback function that checks if an enemy sprite is trapped in the bottom right hand corner, and if so, break out of that with a move in direction 7 to x co-ord 300. This works if I have a callback command at the end of the custom command, and was something I remember Paul Pliska did for his enemy sprite script that could fire off magic missiles at Dink which I used for my enemy at the end of story 2 of SOB
That's the code from Paul and his comments
I've been testing a callback function that checks if an enemy sprite is trapped in the bottom right hand corner, and if so, break out of that with a move in direction 7 to x co-ord 300. This works if I have a callback command at the end of the custom command, and was something I remember Paul Pliska did for his enemy sprite script that could fire off magic missiles at Dink which I used for my enemy at the end of story 2 of SOB
//It seems that I have to re-set the callbacks //evrytime it is hit or attacks or shoots. // ************ CALL BACKS ************* &cbsnd = set_callback_random( "sound",1000,8500); //for Lich sound. &cbfire = set_callback_random( "fb",500,4500); //for FIREBALL &mcounter = random(6000,2000); sp_attack_wait(¤t_sprite, &mcounter); }
That's the code from Paul and his comments
Well, I view it as a different issue in which any actual callback i.e. something run automatically by the engine such as hit() or push() rather than a wait, will interrupt whatever's currently going on in a script.
In an old thread by Kyle it is suggested that this behaviour was changed between 1.06 and 1.08, but I am not certain of that.
In an old thread by Kyle it is suggested that this behaviour was changed between 1.06 and 1.08, but I am not certain of that.
I know that this works:
But I don't know when &crap is changed in the child script, its value is affected in the parent script as well. Maybe you can test and check if you can return multiple values that way.
Edit:
Forgot that this runs in parallel, so dang...
void whatever(void) { int &crap = 0; int &sprite = create_sprite(...); sp_script(&sprite, "some_script.c"); } // some_script.c void main(void) { // &crap is available here if(&crap == 1) { // ... } }
But I don't know when &crap is changed in the child script, its value is affected in the parent script as well. Maybe you can test and check if you can return multiple values that way.
Edit:
Forgot that this runs in parallel, so dang...