The Dink Network

To make a sprite follow Dink, and whenever Dink turns around to face the sprite, it disappears for a few seconds, before appearing behind Dink again?

So essentially, Dink never gets to see it, though he comes very close...

: To make a sprite follow Dink, and whenever Dink turns around to face the sprite, it disappears for a few seconds, before appearing behind Dink again?

: So essentially, Dink never gets to see it, though he comes very close...

Yes, but I use the difficult way:

ghost:

void main(void)

{

blablabla ( base_walk and such )

int &facelook;

int &xdink;

int &ydink;

int &xme;

int &yme;

checker:

&facelook = sp_dir(1, -1);

&xdink = sp_> 1, -1);

&ydink = sp_y(1, -1);

&xme = sp_> &current_sprite, -1);

&yme = sp_y(&current_sprite, -1);

if (&xdink < &xme)

{

//dink is west of the sprite

if (&facelook = 6)

{

sp_nodraw(&current_sprite, 1);

}

}

if (&xdink > &xme)

{

//dink is east of the sprite

if (&facelook = 4)

{

sp_nodraw(&current_sprite, 1);

}

}

if (&ydink < &yme)

{

//dink is south of sprite

if (&facelook = 8)

{

sp_nodraw(&current_sprite, 1);

}

}

if (&ydink > &yme)

{

//dink is north of sprite

if (&facelook = 2)

{

sp_nodraw(&current_sprite, 1);

}

}

//Ok, this is done, we made him invisible

//but now change him back

if (&xdink < &xme)

{

//dink is west of the sprite

if (&facelook != 6)

{

sp_nodraw(&current_sprite, 0);

}

}

if (&xdink > &xme)

{

//dink is east of the sprite

if (&facelook != 4)

{

sp_nodraw(&current_sprite, 0);

}

}

if (&ydink < &yme)

{

//dink is south of sprite

if (&facelook != 8)

{

sp_nodraw(&current_sprite, 0);

}

}

if (&ydink > &yme)

{

//dink is north of sprite

if (&facelook != 2)

{

sp_nodraw(&current_sprite, 0);

}

}

wait(100);

goto checker;

}

BUT REMEMBER< this will use the cpu, because it checks dink and the ghost every 0.1 sec.. hehe

Wow, this took long for me to solve...

How much do you reckon that will destroy a persons computer? I might try it, but I guess it won't be any use it annihilates everybodys CPU's...

But cheers anyway. And can I use that portrait from TNH?? I have edited it...

: How much do you reckon that will destroy a persons computer? I might try it, but I guess it won't be any use it annihilates everybodys CPU's...

: But cheers anyway. And can I use that portrait from TNH?? I have edited it...

you mean that guy in the weaponshop, sure, no prob

Cheers, it's for something cool for "SpookHouse"

: Cheers, it's for something cool for "SpookHouse"

Cool, btw, call it "the haunted"

: How much do you reckon that will destroy a persons computer? I might try it, but I guess it won't be any use it annihilates everybodys CPU's...

Nah, don't worry about it. As long as there's a wait command, even wait(1), you really don't have to worry about one script hogging the CPU. Without a wait of course, a loop will totally lock the computer.

: : How much do you reckon that will destroy a persons computer? I might try it, but I guess it won't be any use it annihilates everybodys CPU's...

: Nah, don't worry about it. As long as there's a wait command, even wait(1), you really don't have to worry about one script hogging the CPU. Without a wait of course, a loop will totally lock the computer.

I'd like to respecfully disagree

If you have a loop that is wait(1); and it runs a while, you will notice things will get rather jumpy and so on.

And no-wait loops rock. You have to be careful not to make them infinite, but if you have it create 50 sprites at the same time or something, it pauses for a bit, but then they all appear on the screen at the same time.

: : : How much do you reckon that will destroy a persons computer? I might try it, but I guess it won't be any use it annihilates everybodys CPU's...

: : Nah, don't worry about it. As long as there's a wait command, even wait(1), you really don't have to worry about one script hogging the CPU. Without a wait of course, a loop will totally lock the computer.

: I'd like to respecfully disagree

: If you have a loop that is wait(1); and it runs a while, you will notice things will get rather jumpy and so on.

: And no-wait loops rock.  You have to be careful not to make them infinite, but if you have it create 50 sprites at the same time or something, it pauses for a bit, but then they all appear on the screen at the same time.

Ya, no wait loops own. But uh, for things like the wait(1); loop...just use wait(25); Because...you don't notice a quarter second..

Like my mana system...every 1/4 second it checks your mana and screen, and updates if necisary.. so while its not hogging the cpu too much...you still don't notice the delay.. you could even go to 1/2 second maybe...

But i suppose i should test my scripts on a slower computer sometime...but meh

: Ya, no wait loops own.  But uh, for things like the wait(1); loop...just use wait(25);  Because...you don't notice a quarter second..

: Like my mana system...every 1/4 second it checks your mana and screen, and updates if necisary.. so while its not hogging the cpu too much...you still don't notice the delay.. you could even go to 1/2 second maybe...

: But i suppose i should test my scripts on a slower computer sometime...but meh

Hmm, odd. It is always noticeable when I use low-wait loops that loop essentially 'forever'. Generally (for me), anything under 100 is noticeable. And I have a 1.4 GHZ.

And wait(25); is actually a fourtieth of a second, wait(250); is a quarter of a second.

And wait() isn't really wait at all. All wait() does is allow other scripts and processes to run, and presumably sleep during excess time left, as Dink doesn't truly multitask (it can keep several scripts in memory, but it can't run them at the same time). Which is why a no-wait infinite loop is so danging.

So if you have lots of other things going on, wait(1) is long, whereas nothing else is going on wait(1) should be shorter.

Yes, but it shouldn't be done with sp_follow(&the_following_sprite, 1); because if Dink moves diagonally he starts to go in directions 6,2,6,2,6,2,6,2,6,2,6,2, and is left long behind. It looks stupid, too.

: Hmm, odd.  It is always noticeable when I use low-wait loops that loop essentially 'forever'.  Generally (for me), anything under 100 is noticeable.  And I have a 1.4 GHZ.

: And wait(25); is actually a fourtieth of a second, wait(250); is a quarter of a second.

: And wait() isn't really wait at all.  All wait() does is allow other scripts and processes to run, and presumably sleep during excess time left, as Dink doesn't truly multitask (it can keep several scripts in memory, but it can't run them at the same time).  Which is why a no-wait infinite loop is so danging.

: So if you have lots of other things going on, wait(1) is long, whereas nothing else is going on wait(1) should be shorter.

Ya, wait(1); is easily noticeable.. but it doesn't screw the world if there's a knight following Dink, and when Dink walks to the next screen the knight isn't there right away.. It's only a beauty problem, really.

I don't understand.. 'Dink can't run several scripts at same time', do you mean two loops or two scripts overally? Two scripts work, I've never needed two loops at same time.

BTW, how is it possible to create a no-wait loop, that doesn't only re-run when the screen is changed, story changes etc. I found loop without wait(); only to tilt my computer..

: Ya, wait(1); is easily noticeable.. but it doesn't screw the world if there's a knight following Dink, and when Dink walks to the next screen the knight isn't there right away.. It's only a beauty problem, really.

: I don't understand.. 'Dink can't run several scripts at same time', do you mean two loops or two scripts overally? Two scripts work, I've never needed two loops at same time.

: BTW, how is it possible to create a no-wait loop, that doesn't only re-run when the screen is changed, story changes etc. I found loop without wait(); only to tilt my computer..

Read DinkC Reference v3.0 under the wait command for a better understanding of Dink's ability to multi-task.

Here is an example of a no-wait loop:

&mydumbvar = 5;

loop:

&gold += 4;

&mydumbvar -= 1;

(&mydumbvar > 0) goto loop;

So basically, in order for a no-wait loop to work, you have to have the end of the loop happen because of something happening within the loop. &mydumbvar will eventually become less than 0, because it decreases from within the loop.

However, if you had the loop above, except making the execution of the loop like:

(&story == 45) goto loop;

Then it would freeze, because &story will never change, because Dink will only run the the code that is in the loop.

: Here is an example of a no-wait loop:

: &mydumbvar = 5;

: loop:

: &gold += 4;

: &mydumbvar -= 1;

: (&mydumbvar > 0) goto loop;

Ahh, but doesn't that add 20 gold pieces to Dink immetdiatly, then proceed down if there's something more in the script? And does that work this way:

: loop:

: &mydumbvar = 5;

: &gold += 4;

: &mydumbvar -= 1;

: (&mydumbvar > 0) goto loop;

,so you could have it loop forever. I think that Dink doesn't understand infinite- mark?

: Yes, but it shouldn't be done with sp_follow(&the_following_sprite, 1); because if Dink moves diagonally he starts to go in directions 6,2,6,2,6,2,6,2,6,2,6,2, and is left long behind. It looks stupid, too.

You can make him brain 16, moves all directions.