The Dink Network

bugs introduced by v1.08 and some stuff that probably should be in the help file

February 23rd 2008, 08:47 AM
fairy.gif
Someone
Peasant He/Him Australia
 
While I was writing MouseDink I made a list of bugs I came across in v1.08, as well as some things I felt were missing from the help file (since I used it so extensively). I emailed Redink about it but seeing as he has passed the "crown" on and never replied I doubt he's planning on updating them. (Not that I think he has to - he's already done far more than anyone can ask of him.)

So I'm just gonna dump it here as developers would probably be interested in it (especially if they wanted to update dink.exe or the help file).

Bugs in v1.08:

- Having external as the last line of a function (perhaps anytime before a }) will sometimes randomly cause the DinkC interpreter to continue past the } and into code afterwards.
- make_global_function is buggy. I had one and it worked, then I added 3 more, and the first one didn't work anymore, until I removed those 3.
- sp_custom doesn't interpret variables in its key (UGHHHHHH) WHY? WHYYY. e.g. sp_custom("blah&i",2,3) when &i=1 will store it with key blah&i not blah1. Did you do this on purpose just to smite Dinkers thinking to exploit sp_custom to make an array??
- sp_pframe is apparently broken; changing from one frame to another with a different hit box doesn't update the hit box, however it does work when its sequenced. I saw this with Red Shield and I'm sure it worked before. (I'm not talking about hardness, though its the same hardbox.)
- I'm not sure if its a bug, but in Red Shield I clipped some sprites to nothing in DinkEdit, but they are visible in v1.08.
- The operator /= is buggy. If you use a function as the divisor it will divide by the LAST function to have been calculated, not the one you want. *= works in that circumstance, though, and so does /.

And some info that isn't in the help file:

- say_xy & say_stop_xy: create text sprite at x+320,y not x,y. (I'm assuming it is 320.)
- wait(X) will call back the script in X ms is more definite than "wait at least X ms"
- random with a range of zero crashes Dink, so the script in "Combat" will crash Dink if sp_strength is zero or one.
- map_tile tile_index doesn't range between 1 and 4428. I have gotten values higher than that.
- get_next_sprite_with_this_brain example has &var++ in it.
- sp_active does not kill immediately; some of the standard dam- scripts have sp_active(&current_sprite,0) and code underneath, which runs. It seems to be equivalent to sp_kill(&current_sprite,1). I haven't looked at the source, though. Both the script and the sprite seem to survive: i put an sp_active(&somesprite,0); and then an infinite loop and the sprite didn't disappear (except when I put a wait() between the sp_active and the loop).
- the reference file doesn't mention global functions can take variables
- or that local functions can too...
- scripts_used page has it as "script_used" (it's scripts_used)
- editor_seq & frame are "get or set", probably editor_type as well
- automatic killing of shadows with the shadowing sprite as mentioned in sp_brain doesn't seem to work so well- seems lagged - better to use kill_shadow when you can (the .c files for the main game do for fireballs, and probably arrows too)
- setting move_x or _y to a magnitude >50 does not work, I was getting errors like "bad pic, sequence 306, frame 307"
- It might be worth noting you can "comment off" large sections of code using if (1 == 2) { .. }. Certainly I've found that useful. (Or by using a return; before the code.)
- Might be worth mentioning that it is a bad idea to use &return for more than one line -- most internal functions return something, and will change it
- I don't think it's mentioned that you can use a function in an if statement if comparing it to a number, but not a variable
- script_attach says it's version 1.00+, but it's different in 1.08: previous versions left &current_sprite as the old number (apparently, since I had to change that in Red Shield)
- In the 1.08 patch, a DinkC called local function does not have access to the variables declared previously in the same script but outside of its own function.
- External functions also kill their own variables when they finish (is this new in v1.08?) This and the above should be mentioned somewhere, I think.
- the function restart_game() is absent in the listing
- The required global variables page has &update_status as "if set to 1, the status bar will be updated", which sounds like it will be updated and set back to zero, but this doesn't seem to be how it works. It seems like (I haven't looked at the source) that when it is 1 the status bar will be allowed to update when called internally or by DinkC. I know that its set to zero in dinfo.c to stop dink.exe continually calling dinfo.c.
- With set_callback_random, the callback will be killed if you call a function with that script number by DinkC (does not occur if the function is called internally). Actually I used run_script_by_number and stumbled upon this, it might not happen with local function calls?
- It's worth mentioning in sp_custom what happens when you request a key's value when the key doesn't exist (seems to crash if there are no keys for that sprite, or give the last key if they are).
- sp_script doesn't mention it will execute the script's main function and return immediately
February 23rd 2008, 09:51 AM
fairy.gif
GlennGlenn
Peasant He/Him Norway
GlennGlenn doesn't want a custom title. 
Nice list Someone, you sound like a guy who knows what you are talking about. And all I can say is that maybe you can have a go at fixing these bugs yourself? Dan posted the Dink Smallwood v1.08 Source Code once the update was released.
February 23rd 2008, 02:59 PM
dinkdead.gif
Something I can add I think:

I can't get sp_clip_xxx() to work. sp_clip_bottom() doesn't do anything and the rest act like sp_nodraw().
Also, _right and _top in DinkC ref. refer to _left in the explanation.
February 23rd 2008, 03:12 PM
duck.gif
Tal
Noble He/Him United States
Super Sexy Tal Pal 
Interesting.

I'm going to sticky this, because... well... I can.
February 23rd 2008, 03:57 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
I remember that I had to clip a sprite in the editor to get the sp_clip_xxx() to work.

Edit: A post on having trouble with sp_clip_xxx().

Also, as I mentioned not too long ago, load_palette() seems to be buggy.
February 23rd 2008, 05:02 PM
wizard.gif
Chrispy
Peasant He/Him Canada
I'm a man, but I can change, if I have to.I guess. 
Posting in a sticky!
because... well... I can.
February 23rd 2008, 09:10 PM
dinkdead.gif
Hmm, that might be helpful, thanks.

Though I can't remember why I wanted to use it in the first place now...
February 24th 2008, 06:33 AM
knightg.gif
cypry
Peasant He/Him Romania
Chop your own wood, and it will warm you twice. 
- say_xy & say_stop_xy: create text sprite at x+320,y not x,y. (I'm assuming it is 320.)
I don't think this should be changed, because it would mess up all the D-Mods done so far.
February 26th 2008, 01:51 AM
farmer.gif
Beuc
Peasant He/Him France
 
I added those to my TODO list for FreeDink

I'm not sure we can so much "fix" the existing DinkC engine without further breakage in existing D-Mods. I'm thinking of leaving the current DinkC engine untouched, and implement a new, similar and fixed script engine with a different file extension.
February 26th 2008, 06:13 PM
dinkdead.gif
"make_global_function is buggy."

I tried to use this and it didn't work.
See here and here.
March 27th 2008, 11:27 PM
bonca.gif
Christiaan
Bard They/Them Netherlands
Lazy bum 
Not really a bug introduced by Dink 1.08, but it isn't fixed while it wás fixed at some point...

DinkC Reference 4.0 says about kill_cur_item(); "Strangely, in 1.07 and earlier, the game would stop executing the script once this command was called. This has been fixed in 1.08."

However, I noticed that it still stops executing the script once the command is called. It's pretty annoying, because you can't let Dink say something now before the item dissapears.

March 27th 2008, 11:35 PM
dinkdead.gif
I couldn't get it to work at all, or kill_cur_magic().
April 17th 2008, 03:51 PM
bonca.gif
megadog
Peasant He/Him New Zealand
Woof! 
(to rabidwolf9's post) How do you make a pallate?!?
July 21st 2008, 01:35 PM
dinkdead.gif
"sp_active does not kill immediately; some of the standard dam- scripts have sp_active(&current_sprite,0) and code underneath, which runs. It seems to be equivalent to sp_kill(&current_sprite,1)."

I've been experimenting...
sp_active(&current_sprite, 0) kills the script at the next wait() only, but the sprite at the next wait(), say_stop() or the like.
sp_kill(&current_sprite, 1) kills both at the next wait(), say_stop(), etc.

To test, put this in a hit/talk proc and comment out one or the other:

sp_active(&current_sprite, 0);
//sp_kill(&current_sprite, 1);
say_stop("1", 1);
say_stop("2", 1);
say_stop("3", 1);
wait(1);
say_stop("4", 1);

With sp_kill Dink will say 1, with sp_active he'll say 1, 2 and 3.
If you change sprite 1 to &current_sprite, odd stuff happens. With sp_kill, 1 will flash briefly above where the sprite was, which is more or less expected. With sp_active, it says 1, 2 and 3 but in the top left corner of the screen while the sprite disappears - seems the sprite is gone but not the script.
September 21st 2008, 02:36 PM
girl.gif
joshriot
Peasant They/Them United States
keep it real 
sp_kill_wait doesnt work, or doesnt do anything that i can tell
July 21st 2009, 12:16 PM
slayer.gif
rabidwolf9
Peasant He/Him United States
twitch.tv/rabidwolf9 
These problems have been around for awhile and aren't exclusive to v1.08, but here's a few freezing bugs and a bomb bug.

If you have an NPC or something of the like..

void talk ()
{
freeze(1);
say_stop("Hiya, I'm frozen when I talk!", 1);
unfreeze(1);
}

void hit ()
{
say_stop("`2 If you hit me while you're talking to me, then you're gonna be stuck!", &current_sprite);
}


Dink will be frozen forever if the NPC or whatever is hit while Dink is talking. While this probably isn't a normal case, it is quite acheivable especially with a magic like acid rain that continuously hits. Until this is fixed, the best prevention is to just not have a hit procedure on things that freeze Dink.

The next one deals with stacking choice commands.. mainly the levelup choice that uses stop_entire_game() and any other one like this. There is a sort of failsafe for the levelup that holds off the levelup until your done with the current choice box you're on, but if you accidentally bring one up while the levelup chimes, you will get frozen. Also with this, if you have two choice boxes stacked, after the first one is closed, the levelup box will popup resulting in freeze.

The normal player wouldn't have many problems with this I don't think, but it is bothersome.

The bomb bug is that when you lay a bomb (or a few) and change screens, you will get sprites changing x,y coord and frames (from the spark) and others blowing up (from the bomb)
July 21st 2009, 03:46 PM
bonca.gif
Christiaan
Bard They/Them Netherlands
Lazy bum 
Isn't that freeze problem easily fixed by putting an unfreeze(1); at the end of the hit procedure?
September 13th 2009, 10:35 PM
knights.gif
Androrc
Peasant He/Him Austria
 
From what I have been experiencing, it seems that when using the "hurt" command inside a hit void, it has a chance to call on the next command, which may result in calling the sprite's die procedure, even though it's not dead.

I solved this by adding an empty talk void between the hit and die voids:

void talk( void )
{
}
September 13th 2009, 11:47 PM
spike.gif
I'm familiar with that problem too. Not sure how closely related it is with hurt() (it can happen with other procedures, and probably other commands as well) but it's annoying for sure. Adding a return; at the end of the procedure also works to prevent it from skipping to the next one.