Irritating Weird Things
Sorry I have to bug you guys again with one of my messages 
. But while creating my Evil Hero DMod, I encountered some irritating weird things (hence the title):
I've got a var called &boss. This one stores the number the boss is, because it appears and disappears, flies in the air and such... Then, I created the var &bosspoint, to store the amount of life it has. I couldn't use sp_hitpoints() beacause, well, this guy appears and disappears. But it seems that, when I want something to say the value of &bosspoint it says in fact 3point (&boss was 3). It cost me a while to figure that out! Irritating, and weird...
And then this: if you make a goto-loop, it will hang if you don't wait() a bit. Dang!!
The last thing: in the cave I'm creating, Dink will warp from map to map, to make sure he couldn't visit a specific place before he hits all buttons. This script doesn't work if you don't wait() in it's main(). You'll then see the screen he really is, and after some time, the screen he goes to. Weird. (Oh, instead of a wait(1), I used a fade_up() without a fade_down() it costs less time.)
Does someone know what's going on here???
PS. My entry will be very Zelda-like. I'm currently freaking on the Wind Waker.
. But while creating my Evil Hero DMod, I encountered some irritating weird things (hence the title):I've got a var called &boss. This one stores the number the boss is, because it appears and disappears, flies in the air and such... Then, I created the var &bosspoint, to store the amount of life it has. I couldn't use sp_hitpoints() beacause, well, this guy appears and disappears. But it seems that, when I want something to say the value of &bosspoint it says in fact 3point (&boss was 3). It cost me a while to figure that out! Irritating, and weird...
And then this: if you make a goto-loop, it will hang if you don't wait() a bit. Dang!!
The last thing: in the cave I'm creating, Dink will warp from map to map, to make sure he couldn't visit a specific place before he hits all buttons. This script doesn't work if you don't wait() in it's main(). You'll then see the screen he really is, and after some time, the screen he goes to. Weird. (Oh, instead of a wait(1), I used a fade_up() without a fade_down() it costs less time.)
Does someone know what's going on here???
PS. My entry will be very Zelda-like. I'm currently freaking on the Wind Waker.
You've stumbled upon the Dink's variable name bug. Try calling &bosspoint something else, like &hp_boss. The problem only happens when a variable name starts with an existing variable, like your &bosspoint and &boss.
Is it a base script? Base scripts (which are attached to screens) don't display anything until you 'wait'.
Is it a base script? Base scripts (which are attached to screens) don't display anything until you 'wait'.
Tyrsis, I believe that does not matter, that bug will still occur, and it is a rather annoying one...Seth should die.
But it does matter. If &boss is global and &bosspoints is not, you have this glitch. Just make them both global - and it's OK
Negatory, that wotn work, the a varible can not start with the name of another varible, it causes the dink engine to go wack.
You don't need a global tho, because if dink is still on the screen, you can store it in the enemy script... In fact, you should be able to use the regular hp
How do you have him disapear?
Why don't you just use sp_nodraw or even easier, just move him offscreen and freeze him, then move him back on when you want him to reapear... you would just use the regular hp that way.
How do you have him disapear?
Why don't you just use sp_nodraw or even easier, just move him offscreen and freeze him, then move him back on when you want him to reapear... you would just use the regular hp that way.
The only reason why &magic_level is immune from the bug is because it is created before &magic, not because it is a global. If you created a new global variable called &magic_fun after you created &magic, the bug would be quite evident.
In the original dink &magic is created before &magic_level and &magic_cost, and &lifemax before &life.
To be free from this bug they should be either both local or both global
To be free from this bug they should be either both local or both global
At the moment that doesn't matter though, magicman just needs to rename one of them.
The reason why the &magic baribles are fine is because they are in the hard code of the dink engine.
Hrm... I was looking at the main.c of my current D-Mod, where &magic was after &magic_level and &magic_cost... I must have simply switched the order a while ago to prevent disaster.
Though after doing some testing, I must assure you that I'm correct
The global-ness or local-ness has little factor in the variable name bug (nor are the required variables exempt as WC suggested): the primary factor is when the variable was created.
*Test 1*
I changed the script for the table in Dink's first room to _magic.c. In it, I had say("&magic_level",1); in the main procedure. Upon starting the game, Dink says "0_level" before the cutscene. To make sure, I exited and re-entered, and Dink still said "0_level". Both &magic and &magic_level are global, and they suffer from the variable name bug.
*Explanation*
So how does &magic_level and &magic_cost work without interference from &magic? Quite simply, the variable name problem is not a problem with assignment operations, but most other operations (comparable, say, etc).
I think with my work on FIAT, I couldn't get if (&magic_level > 5) to work. So all I had to do was initialize a temporary variable to the value of &magic_level, and do all comparisons and such from there. &temp = &magic_level; works fine, and so does &magic_level = 4; and so on. And, most &magic_level and &magic_cost code is done within the Dink engine itself, so DinkC can't screw it up too much.
Though after doing some testing, I must assure you that I'm correct
The global-ness or local-ness has little factor in the variable name bug (nor are the required variables exempt as WC suggested): the primary factor is when the variable was created.*Test 1*
I changed the script for the table in Dink's first room to _magic.c. In it, I had say("&magic_level",1); in the main procedure. Upon starting the game, Dink says "0_level" before the cutscene. To make sure, I exited and re-entered, and Dink still said "0_level". Both &magic and &magic_level are global, and they suffer from the variable name bug.
*Explanation*
So how does &magic_level and &magic_cost work without interference from &magic? Quite simply, the variable name problem is not a problem with assignment operations, but most other operations (comparable, say, etc).
I think with my work on FIAT, I couldn't get if (&magic_level > 5) to work. So all I had to do was initialize a temporary variable to the value of &magic_level, and do all comparisons and such from there. &temp = &magic_level; works fine, and so does &magic_level = 4; and so on. And, most &magic_level and &magic_cost code is done within the Dink engine itself, so DinkC can't screw it up too much.
I tested it too. You are right: the order is the most important. The variable with the longer name should be created first. But if &m is created before &m1, they work OK in calculations, it's just say() and debug() show wrong results.
