The Dink Network

So, I figure I'll just make one big thread to post all issues I come across that I just can't figure out. Also, this means I'm probably working on my D-mod, the newly renamed "Shadows of Death," once again.

So here is my issue: I'm trying to get this script to do something once it reaches a certain x-coordinate. I want it to dissapear, and advance the overall dungeon puzzle. For some reason it has issues with the if (&x < 20) statement. For some reason, it initiates part of the script after the if statement, so the sprite ends up moving farther than it's supposed to, and then for some reason the hardness doesn't follow it and I can't move the sprite anymore without Dink getting stuck in hardness. I seriously have no idea what's going wrong, and it's probably a simple solution that my limited understanding of DinkC just doesn't cover.

Part of the script:

void push(void)
{
 &temp = sp_dir(1, -1);
 &x = sp_x(&current_sprite, -1);
 &y = sp_y(&current_sprite, -1);

 if (&temp == 4)
 {
  freeze(1);
  &x -= 75;
  sp_hard(&current_sprite, 1);
  draw_hard_map();
  move(&current_sprite, 4, &x, 0);
  wait(1200);
  sp_hard(&current_sprite, 0);
  draw_hard_map();
//the issues begin around here
  if (&x < 20)
  {
   sp_nodraw(&current_sprite, 1);
   sp_hard(&current_sprite, 1);
   draw_hard_map();
   wait(1000);
   playsound(35, 22050, 0, 0, 0);
   wait(750);
   say_stop("Looks like that did the trick.", 1);
   &var = 1;
   unfreeze(1);
   return;
  }
  unfreeze(1);
 }
//Etc.
}

Why do you use draw_hard_map() both before and after you move the sprite? Dink's frozen anyway, so it shouldn't matter that the sprite's hardbox is still in its former location until it's done moving, should it? Or is there some reason in the context of your scene that it should?

I don't know. For some reason I probably thought both would be necessary for the original script to work right. That shouldn't be the problem, so I'll clean it up once I get the rest of the script working right.

Is there some advantage in using move() over move_stop() here?

edit: for the draw_hard_map(); you really only need one right before the unfreeze. Also you only need the outer unfreeze. And get rid of return.

Yes, move() instead of move_stop() in case you push the sprite into a hard object which would cause the game to freeze.

Well, he's got ignoring hardness turned off, so he has to use move(). If you use move_stop without ignoring hardness and the sprite runs into hardness, it'll never execute the rest of the script, and if you've got Dink frozen, the game will hang there forever.

Edit: Whoops, I was late.

Ah, right. You should add a say(); at the end there for testing purposes. 20 might be too low a number. The sprite might have to be completely off screen to reach that destination.

What's happening is half of the if statement script seems to run even when the sprite is still at a x coordinate of over 200. So I have a feeling the if (&x < 20) is somehow incorrect and messing it up or something.

Is there an "int &x;" anywhere?

Yes, the local variables were declared in void main(void). I didn't want to post the entire script.

Since it's a little unclear in the original post, does the code in if (&x < 20) run? If it does, I can't see what the problem is... If the script skips over the if (&x < 20) part, well, of course it would run whatever's further below in the script; The only return statement you have is within the if (&x < 20) check.

When you say it runs part of the if statement, which part do you mean? Does it get as far as displaying the say_stop() text?

I'm not actually 100% sure the if statement runs. What appears to happen is the sprite moves a bit farther than it's supposed to, which I assumed was because the extra wait procedure within the if statement was being run as well. The hardness doesn't move with the sprite so I can't continue to push it left to see if the statement runs when (&x < 20) so I need to figure out what's going on with the hardness.

Edit: I haven't seen it run the say_stop(), so the if statement probably doesn't run.

Well, it's easy to find out if the if statement is running. put a say() command with some text at the start of it.

There's no need for even that much; if the sprite doesn't disappear, the if check doesn't run... I think the problem in this script is likely in the part that you didn't post; try moving the return; statement from after the first unfreeze, to after the second unfreeze, and see if it acts little saner.

&var = 1;
unfreeze(1);
//move from here
return;
}
unfreeze(1);
//to here
return;
}

Moving the return; actually worked. Thank you scratcher! But now I solve one new problem I didn't forsee, but I should be able to figure it out quite easily. THANK YOU!

Okay, I am having multiple problems with my boss script and I have no idea what's going on. I have examined a couple other scripts, including ones I wrote earlier for this game as well as for DatB, and I took pieces of the scripts to fix a couple things already, but I can't seem to get the rest of it to work right. I condensed two scripts into this one, and it solved a few issues, but added at least one of these current ones.

Issues:
sp_target(&current_sprite, 1); doesn't work, boss won't target Dink.
boss's die procedure text appears in top left corner of the screen for some reason.
hit sounds are playing randomly

The whole script (minus spoilers):

void main(void)
{
 preload_seq(271);
 preload_seq(273);
 preload_seq(275);
 preload_seq(277);
 preload_seq(279);
 preload_seq(712);
 preload_seq(714);
 preload_seq(716);
 preload_seq(718);
 int &x;
 int &y;
 int &wait;
 sp_brain(&current_sprite, 10);
 sp_base_walk(&current_sprite, 270);
 sp_speed(&current_sprite, 3);
 sp_base_attack(&current_sprite, 710);
 sp_hitpoints(&current_sprite, 110);
 sp_defense(&current_sprite, 3);
 sp_strength(&current_sprite, 7);
 sp_exp(&current_sprite, 250);
 sp_timing(&current_sprite, 33);
 sp_touch_damage(&current_sprite, 4);
 sp_distance(&current_sprite, 40);
 sp_range(&current_sprite, 35);

 if (&story != 16)
 {
  sp_nodraw(&current_sprite, 1);
  sp_nohit(&current_sprite, 1);
  kill_this_task();
 }

 if (&story == 16)
 {
  screenlock(1);
  playmidi("18.mid");
  freeze(1);
  freeze(&current_sprite);
  move_stop(1, 2, 180, 1);
  wait(200);
  sp_dir(1, 4);
  if (&plot == 1)
  {
//spoiler dialogue
  }

  if (&plot == 0)
  {
//spoiler dialogue
  }
  unfreeze(1);
  unfreeze(&current_sprite);
 }
 sp_target(&current_sprite, 1);
}

void attack(void)
{
 playsound(8, 5050, 0, &current_sprite, 0);
 &wait = random(4000, 0);
 sp_attack_wait(&current_sprite, &wait);
}

void die(void)
{
 script_attach(1000);
 &x = sp_x(&current_sprite, -1);
 &y = sp_y(&current_sprite, -1);

 int &dead = create_sprite(&x, &y, 0, 275, 1);
 sp_nohit(&dead, 1); 
 screenlock(0);
 freeze(1);
 say_stop("`7Uhg.....", &dead);
 wait(200);
 say_stop("Now tell me why Luke is here!", 1);
 wait(500);
 say_stop("`7Spoiler", &dead);
 wait(500);
 say_stop("`7Spoiler", &dead);
 wait(500);
 say_stop("`7<bleh>", &dead);
 wait(1000);
 say_stop("Great.", 1);
 wait(200);
 say_stop("Spoiler", 1);
 wait(200);
 say_stop("Time to leave this cave and wander the desert.", 1);
 &story = 17;
 unfreeze(1);
}

Give it brain 9 and it should target dink.

by hit sounds do you meant the sound it makes when it attacks? Because you have play_sound() then a wait() command that could end up being four seconds long. I suggest moving the play_sound below the wait(). Not sure about its dying words though.

For the dying words, put the script_attach(1000) after the lines that retrieve sp_x and sp_y. From the moment you do script_attach(1000), the value of &current_sprite is lost (IIRC, &current_sprite is actually set to 1000, but that sprite doesn't exist), and its sp_x and sp_y will default to 0, which is the top-left corner.

Thank you both. Moving the script_attach(1000) down a few lines and changing to brain 9 fixed all the issues. I feel like an idiot now. -.-

You're not an idiot, some people are more idiotic because they talk about all the cookies they have.

Me having issues like this is why I've decided not to become a game programmer. I'm terrible at it. If I ever finish this D-mod...well, don't ever expect part 3 to be made.

That script gives me the giggles. I imagine the dialogue spoken as written.

"Spoiler... spoiler... bleh."

"Great, spoiler."

Don't forget to add a kill_this_task() command at the end too, otherwise the script will stay loaded forever. (Can cause problems if you do it too often.)

Or use script_attach(0), which is severely underused imo.

I'd want to see a part 3, so I'll hold Skorn's mother hostage until then.

If I do part 3, it won't be nearly the size this D-mod is going to be. If I do it, it'll probably be a decent sized quest. Definitely not going to make another epic.

It still better be done or Skurn's family gets it.

So, since I was bored today, I started taking a look at my D-mod for the first time in over a month. So, I tried messing with some warp scripts I had tried implementing back then, and I actually just managed to get the warps to work. However, Dink is unable to change screens normally now, he just stops at the edge of the screen as if there is hardness, or no screen at all, which isn't the case. He can still go over the warps and change between the 4 different screens, but that's all. Why isn't Dink changing screens normally anymore, and how the heck do I fix it?

Here is an example of one of the warp scripts, for reference. (The warp is a long invisible object on the edge of the screen that triggers when Dink walks over it.)

//Warp Script, for mind-bending fun!

void main(void)
{
  int &rtemp = &real_player_map;
  &rtemp = 370;
  sp_nohit(&current_sprite, 1);
  sp_nodraw(&current_sprite,1);
  sp_brain(&current_sprite,14);
}
  
void buttonon(void)
{
  &player_map = &rtemp;
}

void buttonoff(void)
{
  &player_map = &real_player_map;
}

The scripts are taken from Cast Awakening Part 1: Initiation, and slightly modified. Which is probably why they don't fully work.

It most likely has something to do with those fancy warps.

Why don't you just use a regular ol' warp script.

Because I'm trying to make the illusion that Dink is changing screens normally, instead of warping to another screen. Which succeeds. It just won't let him leave the screens with warps.

All right, makes sense.

Anyways, can you explain why you set &rtemp to &real_player_map even though the next line just sets it to 370. Seems kind of silly to me.

&real_player_map is a declared variable right? Like it's set to a global in your main.c right?

I just copied and pasted the script, I don't fully understand how or why it works or is supposed to work.

Reasons why I suck at programming.

All right, try this.

Go to you story folder.
Find the script MAIN.C
Open said script.
Add in

make_global_int("&real_player_map", 0);

And try your warps again.

Why isn't Dink changing screens normally anymore, and how the heck do I fix it?

I'd wager it's because there is no actual screen beyond the one with the warp script. Changing &player_map won't change screens by itself, and there needs to an actual screen on the other side for the natural screen changing mechanic to kick in. IF the map trickery is working properly, just a blank screen ought to do; the bordermost screen would never actually be seen in-game.

I already had the global declared, just forgot to say so.

@scratcher, I don't understand what you mean.

Nevermind, looks like Initiation uses a different method. Trying out the game, it seems to do some very weird and unnatural nudging along the edges of the screens... I can't imagine how those warp bars could handle the screen changing themselves (meaning there should be a loop that does it, somewhere) unless redink is exploiting some weird glitch in the Dink engine. (Weird glitch? When do you ever see those?)

From what I saw in the script, once you step on the warp, it looks like it sets your current screen to a screen number right next to the screen you're warping to . Then when you step off the warp (as if you were leaving the initial screen), you go to the new screen as if you had entered it from a screen right next to it. I hope I explained that well enough.

That's as far as my understanding of the script goes. I don't know if there's supposed to be any other parts to it somewhere else.

Disregard everything I said above... I seem to be excessively tired and confused.

it looks like it sets your current screen to a screen number right next to the screen you're warping to . Then when you step off the warp (as if you were leaving the initial screen), you go to the new screen as if you had entered it from a screen right next to it. I hope I explained that well enough.

It's not even that complicated, actually. When you change the value of &player_map, the game assumes you are on that screen. SO, let's assume you are on screen 66. You walk right, to screen 67. On screen 67, there is a script that says &player_map = 66. Because of that line, the game now thinks that you are on screen 66 (even though you are in reality on screen 67). So, if you then walk right, you will appear on another incarnation of screen 67 (the same screen you are on), or if you walk left, you will appear on screen 65.

EDIT: That sounded sane when I was writing it. If it doesn't anymore, sorry. In any case, the buttonoff stuff in the initiation warp bars is just there in case the player walks close to the edge of the screen, and then turns around and doesn't leave the screen. If you actually walk to the next screen, only the stuff in void buttonon matters.

Simpler explanation (I hope): If you set &player_map = 1, then walk right, you will appear on screen 2, regardless of which screen you were on previously.

I previously thought that a blank screen needs to exist beyond screen 67, so that the screen scrolling mechanic works, but that doesn't actually seem to be the case... Not sure how I could be mistaken about something like that. (I even built a stupid "buffer zone" of blank screens around an area in my dmod where I use this trick... worthless effort, apparently.)

Heh. I did something sneaky with screens in "Malachi the Jerk." There's a spot where, right before you walk onto the next screen, you get sent to the same spot on a different but identical screen. From my tests, it doesn't seem like you notice anything has happened, so it seems to the player that they've simply gone up to the next screen.

Maybe the issue is this: When Dink steps on the first warp to go to the next screen, he enters the warped screen but he's immediately stepping on another warp that would return to the previous screen. But when he goes to a different edge of the screen for another warp, he still warps correctly. Maybe something is messing up the &player_map values which is stopping him from normal screen changes?

Idfk. DinkC is pretty much a level beyond my understanding 99% of the time.

Yeah, it's definitely &player_map ducking up somehow. You could alt+d while testing to check what the map number is, or even better, add a say command somewhere that tells you the values of &player_map, &real_player_map, etc.

Also, potential facepalm problem: Make sure that the warp button's hardbox reaches the very edge of the screen. (go to editor -> make the warp sprite temporarily hard -> press space.) Because if there's even one pixel of empty space between the warp bar and the actual edge of the screen, void buttonoff would run before you change screens, and that would nullify the warp script/screw everything.

The warp sprites go to the edge of the screen, so that's not the issue. I went into debug and saw what was happening. After Dink leaves contact with the warp sprites, the &player_map sets to 0. I'm not sure how to adjust the variables in the script to make sure the &player_map resets to that actual map number.

Have you set &real_player_map? If not, simply &real_player_map = &player_map at the top of void main should do the trick.

I figured it out, though I still have a small bug I need to work out. I added a &real_player_map = &player_map; line to the void main, and it fixed the non-screen change issue.

The bug I've now encountered, is sometimes when Dink goes from the warp screen to the left, about 10% of the time, the warp fails and he just walked onto the screen right next to it. I don't know why this happens, but for now, this whole thing is functional for playtest purposes. It's time to move onto scripting quests.

Edit: Scratcher, I'm glad my solution is what you posted while I was writing this post. I'll move the command up to void main and make sure it still works.

The bug I've now encountered, is sometimes when Dink goes from the warp screen to the left, about 10% of the time, the warp fails and he just walked onto the screen right next to it.

Sounds like a timing issue. It may be possible that Dink moves two pixels before triggering the button script, which means he has already moved over the edge of the screen. The most logical solution would be to create an invisible wall (e.g. no screen after the edge). Not sure if that might result in Dink not moving to the next screen at all though.

I had a solution in mind, where if he ends up not warping like he should, I was just going to put down some terrain tiles that would stop Dink from going any farther than he's supposed to, but allow him to walk back to the previous screen. Sure, it doesn't solve the bug, but it would stop a player from exploring places they shouldn't be able to get to, or getting stuck.

I didn't get around to actually implementing this before my laptop died though. Hopefully I'll remember to fix this when I have a decent working computer again. (The desktop I'm on can barely do anything.)