The Dink Network

How exactly do these work?? I've noticed that sometimes you don't even need them at all, and sometimes they're just as important as you think.

Magic voodoo.

The DinkC script parsing is not very understandable. My advice is to code as best as you can, and use curly braces everywhere.

My general policy is that if you only have one statement below the "if()", you don't need brackets. Any more than that, and I use them. I have yet to have a problem with this method.

Well, when the body of the if-statement is only one command/expression/whatever, you don't necessarily need them because that's part of the syntax. But the body can also have more commands/expressions/etc and then you need them because otherwise, the engine/compiler doesn't know they're all part of the body of the if-statement

We're doing that @ uni these days so that's why You can consistently use brackets only when necessary (so not when there's only 1 thing in the if-statement's body) but on the other hand, it's generally better to use them everywhere because you can see at all times what starts and ends where (and, if you wanted to add something else, you'd need to add those brackets again to make sure it functions properly - and, when you forget that, you'd wonder why it's not working right )

That works, except when assigning variables.

This doesn't work:

if (&bob == 3) &bob = 4;

What about?

if (&bob == 3)
&bob = 4;

Magic voodoo.

Hmm, yeah, I was just wondering after realizing scripts with only main() didn't need

void main()
{
}

I use that policy too. It's annoying using brackets especially for multiple if()'s and one-liners in a row. I get the feeling my script's more bound to randomly crash without the brackets, though. Superstition... may be. ^^

I don't remember... I was just looking through a DinkC script, and I used something very similar, but it worked.

So I could be spreading falsehoods out to corrupt the minds of Dink developers, hmm.

Hmm, if

if (&bob == 3) &bob = 4;

doesn't work, then Striker's example shouldn't work either because it's basically the same syntax except using 1 more line - you could write a whole program (not a DinkC script, DinkC is very limited ) on 1 line but that wouldn't be readable for us Or perhaps DinkC has odd logic and redink1's example doesn't work, and Striker's example does

Or perhaps DinkC has odd logic and redink1's example doesn't work, and Striker's example does

Yeah, when you put them on separate lines it works. Multiple commands on the same line don't work nearly as often.

Yeah in Dinkc.txt Seth writes the following:
DinkC PARTLY supports multiple commands per line, but later I decided not
to pursue it.. was eating up too much processer time with my slow searches..
So this is a large difference between C and DinkC.

Something I noticed by accident is that any code left at the end of a script, outside of define procedures that do have opening and closing brackets can also get called.

Not sure why, or what the circumstances are, but I have a script with a main(), hit() and a touch() procedure that still calls some other code I have outside of these procedures, kinda like a set_callback_random(). This was code I originally had in the touch procedure designed to move the sprite somewhere, that I decided to see what would happen if I removed it. So I thought, I'll just cut and paste that and stick outside of any defined procedures in case I want to bring it back later.

Then when I went to test the script in DinkHD, that orphaned code was still getting executed even though it sits within it's own opening/closing curly brackets outside of the three defined procedures. This also occurred in YOD.

If I give this code a custom procedure name, like void badcode(void) then it stays isolated and un-used.

Oh wow, I can't believe I was already chafing against stupid brackets 20 years ago.

My current understanding is that brackets to open and close procedures do literally nothing. Any code that's outside them is still treated as belonging to the procedure above it.

void main
say("hello, I'm main",1)

say("hello, I'm overwrite",1)

set_callback_random("boob",5000,0)

void boob
say("I'm booby",1)
sp_kill(&return,100)

void main( void )
{
say("hello, I'm main",1);
}

say("hello, I'm overwrite",1);
}
}
}
}
}
}}}}}
{
}

set_callback_random("boob",5000,0);

void boob( void )
{
say("I'm booby",1);
sp_kill(&return,100);
}

Both of those scripts should just skip straight to "hello, I'm overwrite!" and call the boob procedure. In the first script, though, the sp_kill() command should not work; that's because the last line in a script never seems to run. However, if you pressed enter a few times so the last line in the script is blank, it would work again.

Ah curious... and curious-er

Good to know.

Something else that seems weird to me is that variables declared in the main procedure, which can get used in predefined procedures like touch() hit() etc, become unrecognized if you use a custom procedure to call a predefined procedure.

I really wish variables in scripts had true script local value, i.e. if declared in the main procedure, then accessible to all procedures after that in the script, both standard/defined and custom procedures.

Yeh custom procedures run on their own script number.

I imagine it would be straightforward enough to bypass variable scope issues by using parameters such as gold or even custom data, for sprite scripts anyway.

Yes, I'm trying out different things with sp_gold() and now sp_custom(), and although sp_custom() is great as you can create as many "key" storage slots as you may want, you do need a variable to retrieve a sp_custom value into I think.

Plugging sp_custom("key", &current_sprite, -1) doesn't always seem to work in if statements unless it is assigned to a variable before the if statement and that variable used as a place holder = as far as I can tell.

Something I learnt from Seseler recently is that it's possible to get the value of DinkC's returnint directly as a variable named &return in 1.08 and later. This means that anything that retrieves a value that will then be used immediately won't need an intermediary var.

"Something I learnt from Seseler recently is that it's possible to get the value of DinkC's returnint directly as a variable named &return in 1.08 and later. This means that anything that retrieves a value that will then be used immediately won't need an intermediary var."

A trick I used extensively in Broken Windows.
It's very useful for short throwaway things, for example I wanted some text to show for 5 seconds:

// startmen.c
say_xy("Type!", 0, 280);
sp_kill(&return, 5000);
say_xy("Press escape to exit.", 0, 310);
sp_kill(&return, 5000);
say_xy("(Only letters, space, return, full stop and comma work)", 0, 340);
sp_kill(&return, 5000);

Though it may not always work. I don't know why. See the slightly incoherent comment at the start of solitar.c