The Dink Network

Ok, so I wanna create a cutscene where a sprite is talking, then I want to make that sprite larger, not to become larger immediately, but rather grow slowly to a bigger size (and shrinks later in the same manner). Kinda like:
...
say("random cutscene crap talk thought up by the author",&currentsprite);
wait(time needed to enlarge the sprite);
//enlarge the talking sprite command here
say("another random cutscene crap talk thought up by the author",&currentsprite);
wait(time needed to shrink the sprite);
//shrink the talking sprite command here
say("meow",&currentsprite);
...

Is there such a command? I'm sure I've seen it somewhere.

You could make e a callable function with a loop...
In this function you wait and then increment a variable by the amount you want the sprite to grow with (I think it's called sp_size())?

Do you a code example or is this enough?

Not really, but you can cheat.

Brain 12 resizes a sprite slowly, but when it's done it kills the sprite. So if you know how long it takes, you can:

- Create a new brain 12 sprite to do the resize.
- Make the original sprite invisible.
- When it's about to disappear, make the original visible at the target size.

I would do that last step a bit too soon, to be sure; if you're a bit too late, it flickers which is ugly. My guess is that showing it a little too soon is not noticable.

I'm still newbie, so I have no guesses of where to put loop command or how to stop it, so a code would be appreciated ( I suspect it will involve some IF cmds ).

By the way I have so many questions that you should make a sticky topic "Holding Cococacao's hand".

My second question is If I wanna make a cutscene, must I create every damn sprite in it with void (main)void, or I can create a scenery in WDE+ and continue scripting from there (and how to control which sprite is talking)?

Try this code snippet:

void main( void )
{
	
	sp_speed(¤t_sprite, 1);
	sp_base_walk(¤t_sprite, 130);
	sp_brain(¤t_sprite, 9);

	wait(100);
	increase_size();

}

void increase_size( void )
{

	//100 is default size
	int &size = 100;

    sizeLoop:
	if(&size < 300)
	{
		wait(250);
		sp_size(¤t_sprite, &size);
		&size += 10;

		goto sizeLoop;
	}

}

EDIT: cleaned up the code a bit.

"Bind" this script to your sprite.

Wait, I can make my own procedures? I didn't know that.

My second question is If I wanna make a cutscene, must I create every damn sprite in it with void (main)void, or I can create a scenery in WDE+ and continue scripting from there (and how to control which sprite is talking)?

Well this could be done in different ways. One way is to have a, like, main-script where you create local variables for your ¤t_sprites, and then just call them later in the script. You could also have global variables, which you later can refer to in different scripts.

Bind it? I think I get what you mean, but this is in a middle of a cutscene. I've no idea how to control, let's say 3rd sprite in a conversation unless I've declared him as a variable.

EDIT:

Then Ill stick to void (main)voiding everything

You could try it and see if that is what you were thinking off. I would suggest you declare your sprites as variables. It's one of the easiest way (my opinion) to control interaction between multiple sprites.

By the way, here's some more info from the DinkC reference:

#my_proc() [user-defined function reference]
# Category: Basic Syntax
# Example:
# my_proc();

This is how you run a procedure located in the current script. [It's the
primary way, anyway -- set_callback_random() is another way.]

[WARNING: It is difficult to create meaningful user-defined procedures in
DinkC:
(1) values cannot be passed to user-defined procedures;
(2) as noted in "return", user-defined procedures cannot return values;
and
(3) to a procedure invoked this way, local, "int" variables in the rest
of the script are out of scope!

Consider this example key-## script:

void main( void )
{
int &myvar = 11;
my_proc( 22 );
}
void my_proc( int &passval )
{
say("my_proc: myvar=&myvar passval=&passval story=&story", 1);
}

Name this script, say, key-45.c and press the Insert key. Dink will confirm
that my_proc() gets invoked, but that variables &myvar and &passval are
unknown. Only the value of the global variable &story is available to the
function. But if you get into the proc using a goto...

void main( void )
{
int &myvar = 11;
goto my_proc_label;
}
void my_proc( int &passval )
{
my_proc_label:
say("my_proc: myvar=&myvar passval=&passval story=&story", 1);
}

...&myvar remains in scope in this case. But then again, there is no need
for the extra function header when goto is used.

To be sure, a user-defined procedure may create and use its *own* "int"
variables, but their values are not available to the calling procedure.
For a procedure's own local variables and a subordinate procedure's local
variables to be out-of-scope to each other is certainly in keeping with
the philosophy of procedural languages, like DinkC tries to be. But the
lack of any means except global variables for DinkC procedures to
communicate with each other makes this a serious design limitation.

Additional information: this design limitation is shared by external(). A
script could use external() to run another proc within itself; unfortunately,
external() temporarily creates a new instance of the script it calls, and
that instance's variables are not shared with this instance. It is worth
noting that run_script_by_number() does not create a new instance of the
script. This fact may hold the key to overcoming this or other limitations.]

See also:
external(), spawn(), run_script_by_number
[to invoke functions in other scripts]
goto, set_callback_random() [for other ways to invoke code in this script]
return [for related information]

Like reading 'how to fix your rocket with a paperclip only'

Edit

I'm sticking to basic questions. Like how to create a static pig that is (seems) alive, but doesn't move anywhere, and doesn't change its direction...

holy duck, how and why are there so many replies already? i could've answered this one. :c

i think i've just had it something like -

whatever_the_command_is_for_resizing #
wait(1)
whatever_the_command_is_for_resizing #
wait(1)
whatever_the_command_is_for_resizing #
wait(1)
whatever_the_command_is_for_resizing #
wait(1)
whatever_the_command_is_for_resizing #
wait(1)

or something

I've no idea how to control, let's say 3rd sprite in a conversation unless I've declared him as a variable.

The "brain trick" works well for building cutscenes. I.e. in the editor, give each sprite a different brain. This allows you to pick them up easily in the script by using get_sprite_with_this_brain.

Example:

void main
wait(1)
int &bob = get_sprite_with_this_brain(20,0)
int &bobina = get_sprite_with_this_brain(21,0)
int &bobalina = get_sprite_with_this_brain(22,0)
int &bobinalinatrix = get_sprite_with_this_brain(23,0)
}

It works rather less well in Windinkedit than Dinkedit (because you can't assign non-existing brains in WDE), but it can done with the default brains, as long as you remember to change the brains after picking the sprites. (A townsperson with a duck brain isn't a pretty sight)

That's an interesting approach. I always just use the sp() function. The editor will tell you the number of the last sprite you touched. So....

int &bob = sp(11); //or whatever the sprite number happens to be
int &bobina = sp(14);
etc...

I always just use the sp() function.

That also only works well in (free)dinkedit, AFAIK, because WDE doesn't give you the sprite number? I've never used WDE, so I could be wrong. In my editor, I actually give names to sprites and pass those to sp(); the preprocessor turns the names into whatever number gets assigned to the sprite and it all works.

The other popular approach, aside from the brain trick, is to assign current_sprite to a global in the sprite's main function, but I think you were referring to that originally.

For cut scenes, you can also create the sprites in the script, using create_sprite. That returns a number (just like get_sprite_with_this_brain() and sp() do), which you can then use in move(), say(), etc.

I had no idea about sp(), I'm downloading the DinkC reference again [sp for sprite i get that]. Problem with brains is that usually ppl talk, so they have the same brain value. Controling several sprites in a cutscene conversation is easy when you create them from scratch, but they dissapear (I guess) when the screen is left. I needed this for some situations where I need to use existing ones. I'll poke around some other dmods some more.

Here's a few more questions:
1)
I've put a duck in the intro (&duck => brains = 0 brains, basewalk 5, no preloaded sequences). The duck is in the intro talking some nonsense, and at some point I need it to change direction toward north-west (or 7). So here's a piece of a code:

say("blahblah",&duck);
wait(300);
sp_dir(&duck,7);

Problem is, duck never turns. I've tried every number. This can be solved with move_stop command me thinks, but I'm still curious why sp_dir() doesn't work.

2)
How to change cutscene screen. Fadeout at 'nn screen' and continue on 'xy screen'?

@scratcher

Bob => Bobalina =? bobaliforgot... Where are you from?

Mmh...
How is it made in cc2 (Lord Duckington) ?
I think the duck there has the brain 10 and not the normal duck-brain (3).
Does this make any difference?

I think sp_dir is ignored for things without a real brain (that is, brain 0 or something unknown). If you give it a duck brain, I think it should work, but I didn't test it. Make sure to freeze() it first, otherwise it will continue walking around with its brain.

move_stop also doesn't use base_walk for brain 0 sprites AFAIK.

Anyway, I could be wrong about this; in that case you can use sp_pseq() to just force the sequence to your base_walk+7. That definitely works without a brain.

For the fadeout, the simple (but incomplete) answer is:

fade_down();
&player_map = 123;
load_screen();
draw_screen();
fade_up();

However, there are two problems: first, this kills all running scripts, including the one that tries to do this. So you need to protect it, by attaching it to 1000. Note that this invalidates &current_sprite, but the sprites gets destroyed anyway, so that shouldn't be a problem.

The second problem is that dink gets unfrozen, which is most likely not what you want during a cutscene. So to fix both of them, you do:

fade_down();
&player_map = 123;
script_attach(1000);
load_screen();
draw_screen();
freeze(1);
fade_up();

Huh, for multiple sprite conversations, I almost always just spawn my extra sprites and assign them a variable with create_sprite() in the first sprite's (or the script attached to the screen itself) void main() procedure. That way I don't have to have to muck around with making sure everything is set right in the editor.

I used to do it that way more too. I actually find it more convenient to use the editor, but create_sprite works great for NPCs.

Where I have run into occasional problems is with dynamically created hard sprites. I've noticed that sometimes the hardness doesn't get drawn correctly. It was an intermittent problem. It would work properly 80% percent of the time (or so), but other times dink could walk right through it. It would draw only partial hardness. But if I made the sprite hard in the editor and invisible with a script, the hardness would always work 100% correctly. Then I can remove the sprite's hardness with a different script addressing the sprite with the sp() function. I don't know why the draw_hard_sprite() function failed at times in freedink, but it did. Only once in a while though, but I found it unreliable. It works great for removing hardness though. Well that's been my experience anyways.

I ran into this issue ages ago wth BFTG, but found the solution after extensive debugging. Just use preload_seq(# of sequence you want to use) before creating the sprite. That will ensure that the hardness gets drawn correctly every time.

How to change depth in script?

How to change depth in script?

You mean what is in front of what? The engine calls that the depth que, or just que (That's not English, Seth made it up).

sp_que(sprite_number, new_value);

If the value is 0, it will use the Y coordinate of the sprite. Otherwise, it will use the value you specify. That means this doesn't work well for moving sprites (because their que value won't change).

Higher ques are in front of lower ques.

The engine calls that the depth que, or just que (That's not English, Seth made it up).

You're right. XD Never thought about that. It's some sort of unholy DDC-induced conjoining of queue and cue. (in all fairness, queue is an awful word)

au contraire, it's sethian for the star trek character.

I hadn't realised that preload_seq() loaded hardness. I thought it was just a vvisual thing. That's interesting.

I've also figured out my image problems. I messed up with converting images into the dink palette with GIMP. I can fix this now. I'm not going to bother redoing all my D-Mods because that's too much work and I don't know what other issues 1.08 has. But I can fix my artwork and upload graphics packs which should work fine on all engines and it will all be in the Dink palette. I have already had the chance to test some of my repaired artwork on 1.08 on an actual windows pc now. Hopefully someone can make use of it. I've improved some of my sprites even since Echoes. Coming very soon......

Still working on the freaking intro, and I think Shevek is already losing his sanity when he sees the number of PMs. So I'll bug you guys some more.

I need Dink in a cutscene, so I created him via:

int &dink = create_sprite(x,y,1,14,1);
freeze(&dink);

It's a sequence where he is looking to the left. The problem is, he doesn't move. I don't need him to obey move_stop command (hence frozing), I need frame looping from sequence 14, so that he looks alive, not like coloured statue.

What should I do to make him breathe Frankensteins?

This would also explain me how to start a sequence (for fire and, magic puffs and overall special effects).

I think Shevek is already losing his sanity when he sees the number of PMs.
It takes more than that. But posting here is a good idea anyway, because having technical discussions here is fun.

I don't need him to obey move_stop command (hence frozing)
Freezing does not affect that. Actually you usually freeze sprites before doing moves, otherwise their brain may choose to go somewhere else (I think that never happens during the move, but I'm not even sure of that).

I need frame looping
If you want something that doesn't move, but does animate, use brain 6. You don't even need to freeze him, because brain 6 never makes the sprite move.

For puffs and other things that need to disappear after they are done with their animation (brain 6 will just repeat endlessly), you need brain 7 instead.

I assume that instead of 'x' and 'y' you are going to use either actual values, or a proper variable, right?

When you use create_sprite, you still need to set the brain and sequence even though it should already be set in the function. For some reason you still have to set those independently. Also, why are you attempting to use a 1 brain. To just repeat a sequence, you need a 6 brain.

int &dink = create_sprite(..., ..., 6, 14, 1);
sp_brain(&dink, 6); //necessary even though it should be set by create_sprite
sp_seq(&dink, 14); // also necessary

edit: Shevek answered at the same time I was answering. He has your back.

Doesn't work still
And a game crashes at the point where I've put a little longer text
edit:
wait, I didn't see brasses post

sp_brain(&dink, 6); //necessary even though it should be set by create_sprite
I've never had that problem; what does it not do if you omit that? I never noticed anything missing.

sp_seq(&dink, 14); // also necessary
Yes, this is required; the brain sets it based on base_* values, but it doesn't do it all the time, so if you don't do it, it may take a while before the correct graphic is used.

However, brain 6 does set sp_seq all the time; I don't think you need to do it explicitly in that case, but I could be wrong about that.

He is alive. HE IS ALIVE. Finally!
I didn't knew about sp_seq() and sp_brain() little necessities. Boy, I'll rewrite the introduction for dmod making when I'm done with this.

Ehm, move_stop works under brain 6?

Well....yes, but.... First you would have to set sp_speed(...). But it won't 'walk', it will just move while swaying back and forth which probably isn't what you want.

Perhaps you could explain a bit better about what it is that you are trying to accomplish. You might be going in a strange direction. Do you already have dink set up? You can walk around and hit things etc...? Why is it that you want to create another dink graphic?

It's hard to advise you without understanding what you are attempting to do.

My god, sp_speed...

Now he reaches destination but keeps pedaling in the spot...

My cutscene starts with two pigs eating dragon's corpse, so I don't need Dink, up until later. When he appears, he is there for a cutscene (which is on a differnt screen), and won't be controllable until the cutscene is finished, and yet another screen changed. Therefore, I declared him as &dink while writing sp_nodraw(1,1) and freeze(1) to eliminate original Dink. But this might be the more complicated approach. However, I'm still glad I've took it, 'couse I've learned about some unexplained (and forgotten) basics about DinkC. Maybe a moonwalking potion is on the way

Oh I see. Why not just do a sp_nodraw(1, 0) when you want him to appear again, and then do the move_stop using a 1 for the sprite number. (Just don't unfreeze him until you are ready. Then you don't need the &dink bit at all.

Yes, I also just remembered that sprites created with create_sprite have speed 0, so you need to set it to what you need.

The rest is also more complex than I thought:
The only brain that uses the base_idle sequence is 16, the "smart people brain". Others will simply never use it. However, even brain 16 will not use it when frozen; they will not animate at all. So setting sp_base_idle() is only useful if you care about the sprite standing still as a person while walking randomly through the screen.

What you need instead is to use brain 6 and explicitly set the sequence you want all the time; use move_stop, and after that sp_seq to to idle sequence in the direction you need.

The way you describe what you're doing with the sprites sounds good; that's how it should be done. Brassweasel's approach of using dink's own sprite for the cutscene probably also works, but you need to change his brain to make him do the idle animation.

holy phuck dood. so many posts in the 12 seconds i was gone. is this going to be the popularest

How to give a sprite a specific number? Sprite number, not editor sprite number.
or, how to use sprite editor number in command ex:
sp_nodraw('sprite editor number here', 1);

and no conversions please [&sprite = sp(&sprite_editor_num);],
as somehow that doesn't work. I want to grab a sprite, pull him up to my face and yell:
"Your sprite number is ## bitch!"

"Your sprite number is ## bitch!"
The engine does not support that. You can choose the editor number, and you can get the sprite number from that with sp(), as you wrote. Why does it not work? If you place a sprite and in its own script and do:

int &sprite = sp( <insert editor num here> );
say_stop("current: &current_sprite, computed: &sprite", 1);

What numbers does it give you?

26.
Will try one more time. It's really messy when you have to check sp number this way.

Which is right, current or computed?

Now there are 2 sprites that have value 34. Or other sprite changed his value since I moved them around so I can talk to them. This is of no use then. I'll try with sp() witin command

Which is right, current or computed?
The actual number is irrelevant and may change; what is important is that they are the same.

sp() works from any sprite script, so if you want to use the number of some other sprite and you know its editor_num, the fact that it gives you the same number twice means that it works.

So if you use that and what you try doesn't work, something else is wrong with it.

Or other sprite changed his value since I moved them around
Yes, that is possible. Never think that you know the number of a sprite; always get it from sp() or &current_sprite. The editor_num you can know, the active sprite number does not follow defined rules (which means that if you predict it, even if you are right this time, it may break at any time, so don't do that).

I don't know if WDE+ changes its editor_nums when you do things to the sprites; I wouldn't be surprised if it did, which would mean using those is also fragile (because it can break when you edit the map). It might be good to check that. Or does someone know about this?

No. They stay the same. As far as I saw. I know some of those numbers too damn well, considering how much I've spent checking them. By the way, that extra line for sp_nodraw worked. Thanks.
It's just frustrating when you have to make 2 commands for single purpose.

It's just frustrating when you have to make 2 commands for single purpose.
Tell me about it. I was so annoyed by it I wrote a preprocessor, which turned into a full blown editor.

40 posts long help thread, and 80 PMs between me and Shevek. I've sent him a first glimpse of my dmod... with one screen finished....

I bet he is loading his revolver, smacking the table, and crying to heavens "WHY?!"

Back to the original subject. Resizing sprite
Whenever I change sprite size in WDE+, edges and shadows become white, and make the sprite ugly. This can be avoided by putting sp_size in void main(void), that way the sprite resizes normally. But is there any way or fix for this WDE+ bug? It's just annoying that I must resize the sprite this way.