📧 Message Board Archive

Craziest Dink bug ever. Help!
Okay, I'm using a "supervar" to store 4 values.  It's not directly based on redink1's but it's the same idea. The values repesend a location on a 4 dimensional grid en theory, but in practice it's simply a passcode.



Now here comes the crazy part: There are seleval scripts that need to extract the 4 values from the global they're stored in, (eg one where they tell dink the code, one that checks if he did it right, etc.) I use a local temporary variable. But the script fails if it uses the same name for the temporary variable as one of the other scripts.



At least if they run at the same time. I'm not sure on that part. If so I guess it makes a little sense, but never the less, locals should not interact in any way.



So why is it doing this to me? Here's the script in case anyone feels like checking it out, but I think the real bug is to be found in dink's source code.



//my scroll



void use( void )

{

   if (&castmode == 2)

   {

       &castmode = 0;

       say_xy("You go ahead and throw it away.", 20, 370);

       kill_cur_item();

   }

   if (&castmode == 1)

   {

       &castmode = 0;

       say("I can't think of anything else to do with this.", 1);

       return;

   }



   &bunk = &planerghc;



   &row = &bunk;

   &bunk / 125;

   &bunk * 125;

   &row -= &bunk;

   &bunk / 125;



   &col = &bunk;

   &bunk / 125;

   &bunk * 125;

   &col -= &bunk;

   &bunk / 125;



   &pan = &bunk;

   &bunk / 125;

   &bunk * 125;

   &pan -= &bunk;

   &bunk / 125;



   &sph = &bunk;

 

   say("It reads: layer &row, column &col, pane &pan, sphere &sph.", 1);

}



void disarm(void)

{

   debug("disarming fungus");

 

   kill_this_task();

}



void arm(void)

{

   init("load_sequence_now graphics\dink\walk\ds-w1- 71 43 38 72 -14 -9 14 9");

   init("load_sequence_now graphics\dink\walk\ds-w2- 72 43 37 69 -13 -9 13 9");

   init("load_sequence_now graphics\dink\walk\ds-w3- 73 43 38 72 -14 -9 14 9");

   init("load_sequence_now graphics\dink\walk\ds-w4- 74 43 38 72 -12 -9 12 9");

 

   init("load_sequence_now graphics\dink\walk\ds-w6- 76 43 38 72 -13 -9 13 9");

   init("load_sequence_now graphics\dink\walk\ds-w7- 77 43 38 72 -12 -10 12 10");

   init("load_sequence_now graphics\dink\walk\ds-w8- 78 43 37 69 -13 -9 13 9");

   init("load_sequence_now graphics\dink\walk\ds-w9- 79 43 38 72 -14 -9 14 9");

 

   init("load_sequence_now graphics\dink\idle\ds-i2- 12 250 33 70 -12 -9 12 9");

   init("load_sequence_now graphics\dink\idle\ds-i4- 14 250 30 71 -11 -9 11 9");

   init("load_sequence_now graphics\dink\idle\ds-i6- 16 250 36 70 -11 -9 11 9");

   init("load_sequence_now graphics\dink\idle\ds-i8- 18 250 32 68 -12 -9 12 9");

 

   init("load_sequence_now graphics\dink\hit\normal\ds-h2- 102 75 60 72 -19 -9 19 9");

   init("load_sequence_now graphics\dink\hit\normal\ds-h4- 104 75 61 73 -19 -10 19 10");

   init("load_sequence_now graphics\dink\hit\normal\ds-h6- 106 75 58 71 -18 -10 18 10");

   init("load_sequence_now graphics\dink\hit\normal\ds-h8- 108 75 61 71 -19 -10 19 10");



   int &bunk;

   //weird, the script fails if I call this "&junk"

   int &row;

   int &col;

   int &pan;

   int &sph;



   debug("fists armed");

}



void pickup(void)

{

   Debug("Player now owns this scroll.");

   kill_this_task();

}



void drop(void)

{

   Debug("scroll dropped.");

   draw_status();

   kill_this_task();

}



Lastly, I realize it'e not that bad since it does work if I use different names, but it just doesn't make sense, and it makes me worried my scripts are leaking bytes all over the place.
Re: Craziest Dink bug ever. Help!
Yes, I can say that I've hit the same problem.  I use like 10 supervars (Thanks redink!!) and if you disect a supervar using a set of variables, you can't disect another supervar using the same variables.  



After i figured it out it hasn't been a problem, as i'm pretty much done with all the supervar stuff...but man, it sucked for that week or so when i had no idea why it wasn't working..heh...good luck!
Re: Craziest Dink bug ever. Help!
Is it supposed to be base 125 or base 5?  If the latter, I think you have more serious problems.
Re: Craziest Dink bug ever. Help!
: Is it supposed to be base 125 or base 5? If the latter, I think you have more serious problems.



Is what base five? Care to explain any more? &pan, &col, etc should each be a value from 0 to 124.



But anyway I assume "it" is not, since the script works fine save for that other nasty problem.
Re: Craziest Dink bug ever. Help!
And this will probably screw over half of my scripts.



*sigh*
Re: Craziest Dink bug ever. Help!
Your question is out of my league. :(



But I did remember I had some wierd problems about local variables even using normally.



The first one is that total number of local variables you can use at the same time (or in a screen, not the same time) is 200 (I guess). That's fine, unless you want to have a lot of scripted sprites (monsters) in one screen.



The second one is weird. I suppose that you can use the local variables defined in main in the other procedures (like talk, hit,..), but it turns out that they can'T, at least not in all procedures! Since DinkC allows a script to call a procedure from another script (run_script_by_number), it is very likely that local variables are NOT that local! It seems to me it's a big hole here!
Re: Craziest Dink bug ever. Help!
: Okay, I'm using a "supervar" to store 4 values. It's not directly based on redink1's but it's the same idea. The values repesend a location on a 4 dimensional grid en theory, but in practice it's simply a passcode.



: Now here comes the crazy part: There are seleval scripts that need to extract the 4 values from the global they're stored in, (eg one where they tell dink the code, one that checks if he did it right, etc.) I use a local temporary variable. But the script fails if it uses the same name for the temporary variable as one of the other scripts.



: At least if they run at the same time. I'm not sure on that part. If so I guess it makes a little sense, but never the less, locals should not interact in any way.



: So why is it doing this to me? Here's the script in case anyone feels like checking it out, but I think the real bug is to be found in dink's source code.



: [Script]



: Lastly, I realize it'e not that bad since it does work if I use different names, but it just doesn't make sense, and it makes me worried my scripts are leaking bytes all over the place.



Yeah, local vars interact somehow.  It sucks.



I noticed this somewhere in FIAT's development... I really can't remember in which scripts.  Changing the names was the only thing I could think of that fixed it.



Time to yell at Seth :)
Re: Craziest Dink bug ever. Help!
: Yeah, local vars interact somehow. It sucks.



: I noticed this somewhere in FIAT's development... I really can't remember in which scripts. Changing the names was the only thing I could think of that fixed it.



: Time to yell at Seth :)



ick. I guess I'll just have to do that then. (change the names, not yell at Seth.) Funny that iit hasn't come up before though.
Re: Craziest Dink bug ever. Help!
: : Yeah, local vars interact somehow. It sucks.



: : I noticed this somewhere in FIAT's development... I really can't remember in which scripts. Changing the names was the only thing I could think of that fixed it.



: : Time to yell at Seth :)



: ick. I guess I'll just have to do that then. (change the names, not yell at Seth.) Funny that iit hasn't come up before though.



why do you just have four items in each box? in fiat there is room for 5. is there any reason for making it badder than earlier "technology"?