The Dink Network

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

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
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