The Dink Network

It mentions in the Dink C reference that running in debug mode puts the text in the debug(); statement on screen, but I'm not seeing this running either freedink or the original dink.

The statements are added to the debug.txt file.

And that file is cluttered with

"Surface doesn't have a colorkey"

lines

What does that mean exactly?

I believe the debug mode is only one line, and the worthless clutter it outputs is overwriting it. (Also you have to specifically run the game in debug mode, either by enabling it in DFArc or hitting Alt+D in-game)

BTW,in Freedink you can also open the console to input DinkC commands by hitting Alt+C. I find it's generally a million times more useful for testing stuff than the debug log, which doesn't output anything useful a lot of the time.

Thanks I'll give that a try soon.

I ended up just adding a bunch of 'say' and 'say_xy' commands during procedures to see what was happening with various internal variables.

Discovered that the wait(X) command only takes integers as values and not variables.

And the scope of local variables depends on where they are defined. If not in the 'main' procedure then it seems their scope is restricted to the procedure they are defined in. I couldn't confirm this in the DinkC reference though.

It's not exactly used but you can add debug command lines to add custom debug messages for testing in scripts, as well - At least, that's my assumption based on the debug lines I've seen in start/main.c scripts.

Potentially useful? Uncertain.

Yes the console is super helpful as striker mentioned. Before FreeDink I think a lot of us were adding show_console() as a command on the tilde key to use for debugging purposes.

Yes the console is super helpful as striker mentioned. Before FreeDink I think a lot of us were adding show_console() as a command on the tilde key to use for debugging purposes.

Yep. Striker would also like to mention, the Alt+C console is even better than binding show_console to a button. You can use Alt+C even if Dink is immobilized, and freeze bugs are probably the most common bugs of all.

I have to disagree Scratcher, accidentally freezing yourself and having to restart the whole thing in the middle of testing is an integral part of the D-Modding experience.

EDIT: Oops accidentally said Striker instead of Scratcher, sorry

>"Surface doesn't have a colorkey"
If I remember correctly, that's some issue with FreeDink using SDL2's logging system, it's basically some SDL warning message that's not really relevant to us.

I think yeoldetoast fixed it in his fork of YeOldeDink? So maybe try that instead.

"And the scope of local variables depends on where they are defined. If not in the 'main' procedure then it seems their scope is restricted to the procedure they are defined in. I couldn't confirm this in the DinkC reference though."

Wait what. i don't have access to a PC right now so can't test but never noticed this before. As I rule I tend to declare locals in the main procedure anyway. But I'm pretty sure declaring a local in talk or hit or any of the usual predefined procedures should make them available to the entire script too? Weird.

Unless you're talking about custom procedures, they run on their own script number and don't share locals.

It might have been a custom procedure I was doing, not sure.

It seems most likely I was defining in a custom variable, as the predefined ones used by the engine seem to accept the global scope of the variable.

-----

After more mucking around, I observed this regarding variable scope and custom procedures/

Even variables that are declared in the main procedure don't seem to be recognized by custom procedures, at least not on the first pass through the procedure.

But if I just use a custom procedure specific variable that gets defined in procedure itself, then that is fine. If I can be bothered I should explore the whole arg passing stuff mentioned in the DinkC Ref, which as I read probably already explains about passing variables around and I just didn't get it. (God I hate scripting languages...>-) )

But global variables are modified within custom procedures, so that is something...

So, unless things have significantly changed since I last meddled in engine things about a gazillion years ago...

Local variables are stored per script instance number (check &current_script, and also the return value of scripts_used()). Calling a custom procedure, either through external("script","proc") or through proc(), creates a new script instance, with its own &current_script, and its own scope of local variables.

Globals work as normal. &current_sprite is a pseudoglobal which gets transferred over, if applicable.

If you know the script instance number (say, &number), you can run_script_by_number(&number,"proc") (which *doesn't* allow arguments, AFAIK), and all the locals that are known to &number will be available. But beware! This is pretty much a remote-goto. You're instructing script instance &number to forget what it's doing, and do proc() instead. Similar to how you can interrupt the execution of the talk() procedure if you leave Dink unfrozen, and you then trigger hit() instead. run_script_by_number(&current_script,"proc") is pretty much a goto, except you're using a procedure name instead of a label.