The Dink Network

After few years of trying to make a dmod on bugged computer, WDE+ is finally working. So I'm gonna try to make one. But I'll need help with that dang scripting, and if I fail to release my dmod one day, I'll blame you guys... sorry, life is tough, so I need my conscience to be clean .

Anyway, I'm having problems with my first 'a bit more complicated script'. I know I've done something wrong, but I cannot figure out what. I've created a bookshelf, and I wanted few books readable on it. So it's a choice meny, and it goes like this:

Void hit(void)
{
say("something offensive said towards inanimate bookholding object", 1);
}
Void talk(void)
{
freeze(1);
choice start();
set_y 240
set_title_color 15
title_start();
Choose a book from bookshelf.
title_end();
"Magic skulls"
"Futuristic homes"
"Nonsence"
"Leave"
choice end();
if(&result== 1)
{
say_stop("`%few lines of blah blah about magic skulls", &current_sprite);
}
if(&result== 2)
{
say_stop("`%same goes here, only for futuristic homes", &current_sprite);
}
if(&result== 3)
{
say_stop("`%few lines containing product of my boredom", &current_sprite);
}
if(result== 4)
{
unfreeze(1);
}
}
//script end
When I talk to bookshelf, Dink just freezes there and nothing else happens.

Your script says Dink should only unfreeze if the choice picked is number 4, so there's a problem. Just remove the

if(result== 4) [<-- missing an &]
{
}

check entirely, and only have unfreeze(1) there.

As for why the bookshelf won't say anything, it's probably your lack of spacing in the if check. Try writing it as

if(&result == 1)

or if it still doesn't work, as

if (&result == 1)

EDIT: You're also missing an underline in choice_start() and choice_end().

Hyo,

There are 2 problems with the script, what makes may be confusing when trying to figure what is wrong with it ^^

First:

if(result== 4)
{
unfreeze(1);
}

You add unfreeze(1); inside the variable 'if (&result == 4)' that way, Dink will go unfreeze ONLY if player chooses option 4 (Leave) anything else will keep Dink frozen.

Try this:

if(&result== 3)
{
say_stop("`%few lines containing product of my boredom", ¤t_sprite);
}

unfreeze(1);

}

Unfreeze is outside the choice thing, so whatever the player picks, at the end Dink will unfreeze.

Second then, the choice command, choice start(); and choice end(); need an " _ ":

 choice_start();
choice_end();

]

The wrong syntax made choice not to come up, and due to the misplaced "unfreeze(1);" Dink kept frozen

EDIT: I did post the same time as Scratcher xD But we said the same thing, except that
if(result== 1) (with space) works anyway.
I didn't knew that would work anyway. *surprised* O.O"

Fixed. There is hope for me yet. I'll try not to bug much, I've figured almost everything except intro and cutscenes, basically, places where you don't control Dink)... and putting weapons, items and magic in the game... and creating some effects... and many other stuff... which is hardly almost everything... dang...

One by one I guess. I'll ask if I cannot figure out myself. Thanks.

Edit: I've figured out myself when he pointed that out. I'm not sure aboud syntax (with or without spaces), but problem was in lack of underline on choice_start(), and end.

Mistyped variables and missing underscores?

Looks like you need a useful file such as this!

It comes with my totally unbiased and completely impartial recommendations

This is going to be even harder than I thought, and I don't want to make tons of threads asking stupid noob questions. If there is somebody who is willing to help me with scripting via PMs, I would appreciate that... or I can post in this thread about stuff I need.

So far, I've been having problems with next things:

1) sprite scripts in 'dink' folder have '.d' extension, not recognized by WDE+ (the usual '.c' extension) so when I try to open them, I cannot see a script code attached, which could be useful.

2) Picking up objects from ground (for example, pig feed sack), and storing them to itemscreen using 'touch' procedure.

3) Hitting a specific object, with a specific weapon, while story variable has specific value (what a specific problem ), and doing so makes progress to the story (I think I can handle last part in here)...

I'll answer number two right now because it's relatively simple compared to the other two.

This is just for picking the item up. If you're adding new items of your own creation you'll have to create the scripts for them.

void touch(void)
{
//This is for pig feed
say("WHOLOOOLOOOO", 1);
add_item("item-pig", 428, 2);
sp_nodraw(&current_sprite);
kill_this_task();
}

I'll answer number one right now because it's relatively simple compared to the other two.

You can find the .c versions of the same scripts in: C:\[whatever]\Dink Smallwood\develop\source.zip

If you like, just get rid of the .d scripts and put these in the story folder instead, it makes it easier when you want to look at them from the editor or whatever.

I'll improve the answers to numbers one and two right now, because the answers are relatively incomplete compared to the other one. Or wait... Ah well.

1. If you find dmods with .d scripts, there usually isn't a ready-to-download place for the .c files. However, .d is a (lousy but) lossless compression method, so it can be decompressed into the original .c file. The freedink source has a utility "d2c" for that. Not sure how easy it is to get it running under Windows. If you want source for a specific dmod, let me know and I'll run d2c for you and send you the .c files.

2. Killing an item with sp_nodraw (to stop it being visible) and kill_this_task (to stop it doing things) works. Actually, the same result would be achieved by using the single command sp_active(&current_sprite, 0); However, this doesn't prevent it from reappearing the next time you enter the room. In other words, this is fine for generated objects (like loot from killing a monster), but usually not enough for stuff placed in the editor. For that, you need to deactivate the editor-sprite as well:

int &crap;
&crap=sp_editor_num(&current_sprite);
// Type 1 means kill it completely, see dinkc.txt for other values.
editor_type(&crap, 1);

Note that you need the sp_editor_num, because editor_type needs the number given by the editor, not the run-time number given by the engine.

Also note that this code must be before kill_this_task/sp_active, because after any of those commands, the script is killed so the rest is not executed.

&;current_sprite

Wait, what? I didn't type that semicolon. And it shouldn't be there, either... Hey, I can prove it, too! Click on "view source" and you'll see that it isn't there.

I'll answer number 3 right now as it is relatively unanswered compared to the other two.

You can check whatever weapon has hit your object by:

int &var = compare_weapon("<script>");

This will return 1 when the object was hit by a weapon with the script <script>. So, for example when Dink would need to hit something with his fist <script> would be item-fst. You can use the &story variable to check if the story requirement is met to get something like this:

void hit(void)
{
if (&story == 2)
{
int &var = compare_weapon("item-fst");
if (&var == 1)
{
//Do whatever you want here...
&story += 1;
}
}
}

This script would then be attached to the object Dink has to hit with his fists.

EDIT: Also, feel free to ask in this thread about all your questions. I won't always have time to answer every question by PM, but I don't mind answering some questions here from time to time.

One thing to be careful about with hit scripts is that they are called when any sprite hits the sprite in question, not only Dink, so if there are enemies on the screen it's a good idea to add an extra check to make sure it's Dink doing the hitting:

void hit(void)
{
 if (&story == 2)
 {
  if (&missle_source == 1)
  {
   int &var = compare_weapon("item-fst");
   if (&var == 1)
   {
    //Do whatever you want here...
    &story += 1;
   }
  }
 }
}

(I think that's right, haven't used it in a while...)

And shevek reminded me, WDE+2 can also decompress scripts from .d to .c.

How many enemies will have 'item-fst' as their weapon do you think?

it's a good idea to add an extra check to make sure it's Dink doing the hitting

Actually, you want more checks:

Is dink doing the hitting? -> &enemy_sprite == 1 (I think).
Is dink hitting with a weapon (as opposed to magic)? -> &missle_source == eh, 0? You should check this.
And in your case, is &story the right value?

if (&missle_source = 1)

The misspelling of missle_source is correct. The single = sign is not.
And it doesn't check what you want to know, I think (but didn't check either). This checks if dink himself was fired at the object. It should be possible to do this, but I don't think it's ever useful... Maybe for a very special "transform into a fireball"-type of attack.

How many enemies will have 'item-fst' as their weapon do you think?

Ah, but you are mistaken about the meaning of compare_weapon. It doesn't compare the current enemy's weapon, it compares the weapon which is currently armed by Dink. If you only use that for opening a chest, for example, it would also be opened when shooting a fireball at it while having the fist armed, and even when a bonca attack hits it while Dink has the fist armed.

I did go into all this in some detail at one time but can't remember it now...

Because there seems to be some overlap between &enemy_sprite and &missle_source. According to the DinkC Reference it seems that they are identical in the case of "normal" hitting (eg punching) and differ regards missiles only.

And as I can't remember all the details I'm just going to stop here unless I get a chance to check my old scripts and find out

"The single = sign is not."

Oops Too much time spent with VB.

Edit: Found it. Read through that for details

Edit2: There are too many 's in this post. Shows what state my brain is in...

How many enemies will have 'item-fst' as their weapon do you think?

Ah, but you are mistaken about the meaning of compare_weapon. It doesn't compare the current enemy's weapon, it compares the weapon which is currently armed by Dink. If you only use that for opening a chest, for example, it would also be opened when shooting a fireball at it while having the fist armed, and even when a bonca attack hits it while Dink has the fist armed.

Uh... Tadada... I never said a word...

*Looks around innocently...*

Because there seems to be some overlap between &enemy_sprite and &missle_source. According to the DinkC Reference it seems that they are identical in the case of "normal" hitting (eg punching) and differ regards missiles only.

I think this is new in v1.08. Before that &missle_source only worked for missiles, since 1.08 I believe it indeed works as Sparrow describes. Before v1.08 you could actually get away with not declaring &missle_source if you didn't intend on using missiles. I remember that it caused quite a few old DMODs (made before skeleton_B became the standard) to be incompatible with v1.08 when it was first released.

Now what happens when you fire a missile and some NPC hits your target before the missile hits your target is an interesting question...

Found it.

Hmm, that makes sense, I suppose. However, I'm doubting Someone's comment in there about turning missle_source into enemy_sprite. Doesn't missle_source contain the value of the sprite which fired the missile? If so, how does it know? Perhaps something related to sp_brain_parm?

Summary:

For weapon-based attacks, no matter who does them, missle_source and enemy_sprite are equal to the attacking sprite (and thus equal to each other).
For missile-based attacks, missle_source is equal to the missile sprite, while enemy_sprite is equal to whoever fired the missile. How the engine knows is unclear. It might even use current_sprite during missile creation, or something...

Ok. My problem goes like this:
current &story value is 0.
Dink must read a note before being able to get the pig food. If he hasn't red a note, &story should remain 0, and when he talks to the sack of pig food, he just leaves a comment and you can continue.
If he red a note (&story = 1), when he talks to sack, he gets a choice meny: take it, or leave it.
My problem is:
no matter story is 0, choice meny is shown, and whatever choice I make, effect is the same (not to mention that pig sack is represented like staircase in itemscreen, and when you use it, dink throws nothing).
Can you tell me whats wrong with the code i've attached to pig feed sack?
Since it contains so many if statements, maybe I have putted '{}' symbols on wrong places.
The code:

void talk(void)
{
freeze(1);
if(&story == 0);
{
say("Pig food, for pig feeding", 1);
unfreeze(1);
}
if(&story == 2);
{
choice_start();
"Take the sack"
"Leave it be"
choice_end();

if(&result == 1);
{
say("I might need that... again", 1);
add_item("item-pig", 428,2);
sp_nodraw(&current_sprite);
unfreeze(1);
kill_this_task();
}

if(&result == 2);
{
say("No way I touch that thing again in my life", 1);
unfreeze(1);
}
unfreeze(1);
}

I'm not entirely sure how dinkc handles this, but at the end of if statements you should never put a semicolon. In C, the following are equivaluent:

if (something);
{
//Do something
}

if (something)
{
}
{
//Do something
}

The only difference is that the latter is more clearly not what you mean to do. The "Do something" part is always executed, regardless of what's in the if expression. This explains that your choice menu always appears.

Also, you have an overkill of unfreeze statements. This doesn't do any harm, but you only need to make sure that this is executed once before the script finishes. So do it before kill_this_task, and at the end of the function (outside any if blocks).

Finally, for the appearance of the pig feed, you should check the sequence and frame number of the sprite you want to use, and use it as second and third argument to add_item. I don't know them by heart, but according to your story sequence 428 frame 2 is a staircase.

Syntax again. I've removed semicolons, left unfreeze just in case, and made few more minor adjustments. It's functioning WOOHOO

In other news, hardness editing is

It's functioning



In other news, hardness editing is

Tell me about it. This is one of the reasons I decided to write a new dmod editor. The primary reason is that I want my editor to detect scripting problems.

"Doesn't missle_source contain the value of the sprite which fired the missile?"

Do you mean enemy_sprite? Either way, no I don't think so, see:

"For missile-based attacks, missle_source is equal to the missile sprite, while enemy_sprite is equal to whoever fired the missile."

This needs testing to be certain, but according to the reference it seems in the case of a missile enemy_sprite actually equals 1 whoever fired it.

Edit: Oh and how is your editor? Getting any further or stalled because of lack of input from us lazy users?

Uhhh... me again. Hey, I warned you I will write often. This time, touch procedure is bugging me. In original Dink, there is an (invisible) desk blocking the path until story reaches 5 or something. I'm trying to make the same, except it should work for the rest of the game.

In a property page, I've set values like this:

Type: invisible
Nohit
touch damage -1

script attached:

void touch(void)
{
sp_touch_damage(&current_sprite, 0);
move_stop(1,8,290,1);
say("The door is jammed! Guess I'll need to find another way out.", 1);
sp_touch_damage(&current_sprite, -1);
}

I think that might actually be to do with the type. This is worth a try:

Set it to normal in the editor and make it invisible in the script instead.

void main(void)
{
  sp_nodraw(&current_sprite, 1);
}

Also, if you put the say() before the move_stop() then Dink will talk while moving

This needs testing to be certain, but according to the reference it seems in the case of a missile enemy_sprite actually equals 1 whoever fired it.

That's correct. Luckily, there is a simple way to get the correct sprite by checking sp_brain_parm, since every missile in Original Dink stores the sprite who launches the missile with it. (Problems will only arise if the dmod author changes this convention)

e.g.

int &culprit = sp_brain_parm(&missle_source,-1)
sp_target(&current_sprite,&culprit)

Oh and how is your editor? Getting any further or stalled because of lack of input from us lazy users?

It's going well. I'll release version 1 "tomorrow".

The lack of input is slightly demotivating, but it also motivates me to make it more user-friendly, so even lazy users can run it.

Just one thing I need to rant about:

There's one thing I'm not going to do, however. If you want to run it, you will need to get Python and PyGtk separately. I know of several Windows programs (for example Inkscape) which package such software with it. The result is that you can download one thing and it works. That seems nice, but it isn't. The result is also that if a security hole is found in Python, you have to look into your installed programs and update each one which includes Python. And in many cases you may need to wait (and/or ask) for the fixed version to be included in the package. The end result is a system full of copies of the same code, all of which have bugs in different places.

The proper solution to this is a distribution, where I can say "this program requires python". Then when installing it, the system will automatically pull in Python as well, if it wasn't installed yet. When Python is updated, the program automatically uses the new version. Every system I know except Windows works this way. In Windows, the burden of keeping the dependencies up to date is put with the maintainer of the program using it, not with the maintainer of the thing which should be updated. That is very wrong. And I'm just not accepting that burden. So I give it back to the users. If you don't like it either, then don't use Windows.

I'll shut up about it now, and stop caring about Windows again. That makes me much happier.

Well, it's clear to me now that a sack of pig feed cannot be turned into a lethal weapon, as for it's animation when used, it's far to complicated for me to understand yet, so some copy-paste action will do it.
Again I have a problem. Tutorials cover only the basics of basics, little more complicated stuff aren't easy to do, but for this action, I heavn't found any clues of how it's done. Pig farming.
I need to drop some pig food on an object (which is in one part of the screen) and start converation that way. How it is done?

Speaking about conversations, how can I, for example, make two sprites speak with Dink (three man conversation)?

Also, does variables such as '&hold', '&temp4gold', '&crap' etc, have only the use to help menaging all sprites on screen (don't know if I used right expression), or they have some special use? I guess here lies answer to my previous question, but just to be certain. I'm not skilled with scripting enough to put it to the test.

Well, it's clear to me now that a sack of pig feed cannot be turned into a lethal weapon, as for it's animation when used, it's far to complicated for me to understand yet, so some copy-paste action will do it.

If you want Dink to whack the sack on the opponent's head, then you need to draw an animation for that, indeed. If you want to use the normal feeding animation as a weapon ("look! I'm throwing acidic/radioactive/whatever stuff on you!") that should work without much trouble. Still, I think your approach to first get the rest working is very sensible.

I need to drop some pig food on an object (which is in one part of the screen) and start converation that way. How it is done?

First hint: this happens at the start of the original game. You can check how it's done there.

The pig food is treated as a weapon by the engine. When press ctrl when it is armed, the "use" function from its script gets executed. You can create a feeding animation for it and create the feeding sprite. If you really want to use it as a weapon, this sprite can have a missile brain, which means it can hit things (with speed 0 it will not move like an actual missile). In fact, you should use the brain I call "flare", which is a missile which runs only one animation sequence.

However, it's more easy to just see if Dink is standing at the right spot while feeding, and if so, consider the thing "hit". In that case, you don't need to create a missile.

Speaking about conversations, how can I, for example, make two sprites speak with Dink (three man conversation)?

All the say_* functions have as their second argument the sprite which does the talking. You can put a number there, which should always be 1 (because the other numbers you don't know beforehand). 1 is Dink. You can also put a variable there, such as &hold or &crap (which is used a lot in the original source, but you can use any name you like). First you assign a number to the variable, then you can use it in places like say_stop (but also all the sp_* functions).

In principle, the editor knows which numbers belong to which sprites, but I haven't ever seen a dmod use that information (with my editor, you would let the editor use it, those interested can see the source of Karel ende Elegast, for example bedroom.c). What people do, is to use global variables. Make sure you have them defined in main.c, then assign a value to them in the sprite's main() function:

void main()
{
&girl = &current_sprite;
}

Then the global variable &girl contains the sprite number of the sprite that started the script. Then you can use a command like:

say_stop("Dink! I hate you!", &girl);

to make the girl say something. This works from other sprites as well (because &girl is global, its new value is known by all scripts). Using &current_sprite directly wouldn't work, because it has a different value for a different script.

A conversation is simple several sprites saying things in turn. Often, the conversation is started from one sprite's script and the other person is Dink. In that case, things are simple, because both sprite numbers are known (&current_sprite and 1 respectively). If you want more people, or if you want sprites to talk from other locations (for example, a shopkeeps saying "don't touch that!" when you try to do things to his merchandise), you can use the above system.

If I continue to ask this much about scripting, I'll might as well credit in my 'hopefully once finished dmod' everyone who helped me here, excluding myself. Try to get in, while I'm still ignorant !

I'm still not sure how (or why) DinkC engine function the way it does, and that's my problem. You could see that in previous posts of mine.

So, I wanted to figure the cutscene myself. And this is what I did.
Created some room interior, put some empty shelves, decoration etc. I've copied in my intro.c the entire script metatarasal had written in his tutorial (an intoduction to dmod making), started the game and watched it.
Everything went fine, but instead of the sprite that was supposed to appear on screen (Ill refer to it as '&var'), the &var never appeared, but his dialogue was spoken by one of the bookshelves. I've checked his sequence, changed his coordinates in create_sprite command, but the same thing happend. What's wrong?
This is meta's code:

void main( void )
{
sp_nodraw(1,1);
int &var = create_sprite(425, 202, 16, 371, 1);
sp_base_walk(&var, 370);
sp_speed(&var, 1);
wait(1);
freeze(1);
freeze(&var);
dink_can_walk_off_screen(1);
sp_x(1, 270);
sp_y(1, 480);
sp_nodraw(1, 0);
move_stop(1, 8, 180, 1);
wait(250);
sp_dir(1, 4);
wait(250);
sp_dir(1, 2);
wait(250);
sp_dir(1, 6);
wait(250);
sp_dir(1, 8);
wait(250);
sp_dir(1, 2);
wait(200);
say_stop("Hmm… Looks like this place is missing a rather important piece of furniture.", 1);
wait(200);
say_stop("`9You’ll get used to it…", &var);
wait(200);
say_stop("Eh, right... I’d rather just buy a new bed I think…", 1);
move_stop(1, 2, 480, 1);
fade_down();
script_attach(1000);
&player_map = 400;
load_screen();
draw_screen();
freeze(1);
sp_x(1, 180);
sp_y(1, 250);
fade_up();
unfreeze(1);
dink_can_walk_off_screen(0);
&update_status = 1;
draw_status();
kill_this_task();
}

Everything looks fine. Could it be that he is standing behind the bookshelf? Did you change his coordinates to be really low in the screen (say, 320, 390), so he is in front of (almost) everything? Even if he is still behind things, it should at least make the text move. Perhaps you should try it without too much furniture, to see what is wrong?

In freedink, it may help to enable debugging mode and see if there are any error messages (even though most of the time there are none, even if there are lots of errors). Not sure if and how that works with normal Dink. Similar, I would expect.

This appears to be a variable problem. Is there a global variable already called &var? If there is, the int line will not work and it will never create the sprite.

the int line will not work and it will never create the sprite.

And I suppose it will not even warn about all this either? Wow. The ways that the engine is broken never cease to amaze me...

Yeah, you need to be really careful in naming your variables. Locals and globals can't have the same names. I originally thought the problem was the same as here myself. If the problem isn't like Kyle says possibly placing preload_seq(371); before the int &var = create_sprite(425, 202, 16, 371, 1); line could possibly work. Still getting to grips with that strange preload problem...

I originally thought the problem was the same as here myself.

I thought of that as well, but that one could also be solved by adding a wait(1) after the create_sprite, and that is already present here, so I don't think this can be the problem here.

There are no global variables called &var. I've moved intro to an empty screen, and it gets stuck when sprite should say his line (sprite is not created, ive added preload_seq, changed coordinates etc). I don't have solution to the problem , but at least I understood how intro should function .

Very strange. Can you put the entire (1-screen?) dmod online somewhere? Or send it to me by email (wijnen@debian.org)? I'd like to have a look at it.

I'm also pretty interested in fixing this

If you're running the script directly from start-1.c via spawn, add a wait(1) before you create the sprite. Creating a sprite directly after using the set_mode(2) command won't work, because the engine will draw the first screen only after it encounters some type of wait command. (So the sprite DOES get created, but it also gets instantly wiped out as the screen is drawn)

If that doesn't make any sense, read Someone's FIFO & Variables file.

Ah, indeed, if you're running the script that way this will be the result. Adding the wait will do the job and so will attaching this script to the screen itself (which is how I do most of my cutscenes).

Sent to Shevek via email.

Sent to Shevek via email.

Thanks. I could indeed reproduce the behaviour, and I could also make it work as it should, following Scratcher's idea to put a wait(1) before the create_sprite in intro.c.

I suppose it makes sense, if you know what the mode actually does. All I know is it stops capturing the pointer.

wait(), has solved the problem.

Yay On to the next challenge!