The Dink Network

In my newest DMOD I've implemented a part wich tests your reaction time. In the DMOD it means you should react to orders given on screen within a certain amount of time.

Now I thought it might be cool to make a stand-alone version of it, with possibilities to test your reaction time in different ways, as well as the possiblitity to set your difficulty level.

Give me some feedback on this idea, do you like the idea? Should I make it?

Yep Make it! That would be fun!

Hmmm... not many reactions. But atleast they're not negative, so I think I'll start working on it.
It shouldn't be much work, but you'll never know...

It sounds fine by me... At least, if you can play most reaction games from the start by using a menu... And maybe even a secret bonus game.

A secret bonus game...

I will consider it.

There is a "reaction game" in one of the DMODs of redink1 (in a place that has bones in the ground. Do not remember the name). I did not liked it because it was too difficult, and was required to continue the game, so I hated it.

Simple answer dont make it compusry, make it a bonus

But in a stand-alone version, it's rather compulsory, isn't it?

Actually it isn't. Because you don't have to download it.

And you have been warned.

And its another dmod

A new issue: What kind of music would you like in this DMOD? I'm trying to implement a system where you can choose wich midi's you want to play and wich you don't want to play, so there's got to be something for everyone. That's why I'd like to know wich music you like best for something like this.

I just wanted to prevent people from hitting a button too early. Because if I don't, people can just hit a button continuously and so have a very quick reaction time.

I had figured out a fix for it, but I found out that it didn't work because dink doesn't support multiple scripts running at the same time... (something for windemere?)

Now I'm just trying to figure out how to work around it...

there's blog spaces and development forums for this my friend!xx

I know, but I had opened this thread already, so I thought I could post it here.

Attach() it to sprite 0 maybe?

I don't think that will work. I've tried similar things before, (actually the script both scripts running where spawned so they should already be attached to sprite 1000).

I've tried to attach a script to sprite 0, but it didn't seem to make a difference. but it could have to do with my bad scripting.

If you set wait(0) for each script, and only those two scripts were running, would they cycle, or would they just not run each other?
And if you set it to something like 1 or 2, would the game just freeze?

Basicly the script works as follows:

I have a global called &early.

In the main script this is the idea:
spawn("early");
loop:
&early = 2;
wait(<a random amount of time> );
if (&early == 3)
goto loop;
&early = 1;
*the rest of the script*

The script attached to the script early is:
void main( void )
{
loop:
wait(50); //to prevent it from chrashing because the wait(); command is to short. (as Chrispy just mentioned)
wait_for_button();
if (&early == 4)
kill_this_task();
if (&early == 2)
&early = 3;
goto loop;
}

When I run this it just doesn't look like it does anything, it won't go back to the loop when I press the button early. (or perhaps it returns only once, I'm not sure... (But this seems illogical too)) So I blamed it on the limitation of the dinkengine not being able to run two scripts at a time. Both scripts have a wait(); command so it shouldn't be a problem, but it is...

I'm thinking of not fixing the bug and release it anyway untill someone finds a fix. This shouldn't be a mayor pain, because it's unlikely that you would have much (unfair) advantage from using this problem anyway. (and having a disadvantage is impossible so...)

Why not combine the two scripts into one no need to spawn a new script.

wait_for_button() freezes the entire script until a button is pressed, or stop_wait_for_button is called in another script. So this code won't work:

loop:
wait(1);
&wait += 1;
wait_for_button();
if (&result == 2)
{
say_stop("Reaction time: &wait",1);
return;
}
goto loop;

It'll stop at the wait_for_button();

That wouldn't suffice for an other reason too. &wait would be much lower then your actual reaction time. This is (I think) due to the fact that it takes time to run all of these procedures. (In my scripts it actually made a difference of a factor 27)

But has anyone got any clue why this doesn't work as it is supposed to do? (the script I just explained)

Then I wonder how you are wanting to measure reaction time. But to answer your question why it fails.

early.c:

void main( void )
{
&early = -2;
wait(5000);
&early = 0;
timerloop:
//Replace this by whatever method you use to measure reaction time. I re-use &early in this case.
wait(5);
&early += 5;
goto timerloop;
}

void kill( void )
{
kill_this_task();
}

//*script before
int &timer = spawn("early");
loop:
wait(1);
wait_for_button();
if (&early == -2)
{
say("you're too early",1);
goto loop;
}
say("your reaction time: &early",1);
run_script_by_number(&timer, "kill");
//*script after

In this case, I've put only the timing in early.c. The main script still handles being too early. I don't what could go wrong initially. Perhaps you should add { and } to if-statemens. I know they shouldn't matter with just one line following, but then, they just might.

Looks interesting, I'll try this script.

EDIT: I've just tried this system. And it works!
I had to totally edited them to fit into my scripts, but in the end I got them to work. (Actually you can hardly recognise anything from the scripts magicman proposed in my scripts...)