The Dink Network

Uhm... Do you folks have any advice on how to debug WDE 2+? It's consistently crashing upon clicking on one specific sprite

Edit:
Nevermind. Found out about the drone edition, which is a lot stable as far as I can tell.

So, now for better question... How the heck I'm supposed to put a glass on the table??? I recall something about depth que, but I don't find it in sprite props...

In WDE Drone edition, I think it is called "Depth Dot" in the sprite properties dialog, 2nd column from the left, on the very bottom.

I'm not sure why it's called that though... It was just called this in V2.5 and I left it like that.

I think it corresponds to this DinkC command: https://dinkcreference.netlify.app/functions/sp-que.html#sp-que

Perhaps it should be called "Depth Que" in the WDE interface too?

Someone should rename this thread to toof relearns DinkC. Alright another Q. I wish to put screen transition into a separate function like:

void transition(int &pmap)
{
    fade_down();
    &player_map = &pmap;
    script_attach(1000);
    load_screen();
    draw_screen();
    dink_can_walk_off_screen(1);
    freeze(1);
    fade_up();
}

This works when it's "sequentially" put in the script. But when I invoke it as a function, it doesn't wait for previous

say_stop()

function to finish. I assume it executes this in parallel. Any hint on how to do this?

Ah, this sounds like a question for RobJ...

think of depth que as the portrayed y-coordinate value of the sprite.

the depth dot is the pixel of the sprite that represents its base depth queue value. You can adjust this on a sprite by sprite basis but I don't remember the specific hotkey to do this off the top of my head. It might just be by pressing Q when you has a sprite selected but I'm not 100% sure on that.

There should be something in the bottom of the property window to adjust the depth queue. It might just be called que though, as the command line for it is sp_que()

Lower values appear behind higher values. So if you want to have a glass be on top of a table, set its que value to be higher than the table's y-value.

in regards to the screen transition, why does it need to be its own function? Are you planning to trigger it through multiple other functions?

try doing this

void transition()
{
	fade_down();
	&player_map = &arg1;
	script_attach(1000);
	load_screen();
	draw_screen();
	dink_can_walk_off_screen(1);
	freeze(1);
	fade_up();
}

where you use

transition(&pmap);

command to call the custom procedure.

Custom procedures can have up to 9 pseudo variables I believe.

I thought at first that you might have to have the script_attach(1000) before the &player_map = &arg1; but you don't.

And it seems to work better that way, as when I had it around the way I first thought other sprites or scripts started to run for some reason on loading the changed map screen.

I have several transitions in the intro. Just trying to tidy up things a bit.

I found depth dot, and it works as expected.

The &arg thing will have to wait until tomorrow. I am unusure how to properly define a function argument (synthax). I tried in several ways, with and without ampersend, and, oddly enough, the value was transfered correctly. Those who like to dabble with DinkC intricacies might find information interesting.

Two additional Qs... Is there a way to zoom in screen view in wde? My eyes are strained. Also, how the heck one maps a forrest? I found out it has to be combination of tiles and sprites, but I can't figure out the pattern. Mapping terrein is very hard.

Mapping terrein is very hard.

Now try doing a wooden floor

Heh. I did. I have a special screen for copy paste. But I can st3do it. Forests however...

Forests can be really annoying since you have to do a combination of tiles and sprites and hardness and the double side tree sprite sucks for depth que.
If there are any forest screens that don't directly transition into each other you can cheat a little and not make the tiles match up which definitely helps.

Also when doing forests the clipping feature of X or Z when the sprite is selected is very important for that double side tree sprite since it lets you only have to deal with one tree rather than two.

>Is there a way to zoom in screen view in wde? My eyes are strained.
In the current releases, no, other than setting your Windows Display DPI setting higher than 100%...

But funny you should mention that... I have been working on a huge overhaul for WDE for quite a long while now, and recently I had just finished redoing the rendering system so you can Zoom In/Out...

There are still a bunch of things I am working on though, and it's quite a ways away from being in a releasable state... I actually just sent RobJ the first dev-test version to play around with and report bugs this week.

I suppose if you're curious, I could send you the test version, although I'm not sure how safe it is to edit DMODs with it right now haha...

PS: If you're interested in the test version, could you add me on Discord or Telegram? If I am to let you in on the secret WDE dev cabal, I will have to explain all the changes and whatnot, and it would be easier that way.

@LeprochaUn: Why has no one just edited the default side-tree sprite to only have one tree? It seems like the simplest solution to the side-tree's annoying depth issue...

Although, I suppose you can stamp the half-tile wide yellow hardness on the edges of the forests. That way only a little bit of tree sticks out, and you can set the depth que so that the tree is always on top of Dink.

//tree edge sprite script
//Robj: "Duck these trees and their depth ques, I'm autoscripting this shit"

void main(void)
{
  //check if current sprite is already clipped - first check clip_bottom
  &save_x = sp_clip_bottom(&current_sprite, -1);
  if (&save_x >= 1)
  {
    if (&save_x <= 200)
    {
      //editor clipped to only show top tree of edge sprite
      //check for custom clipping
      &save_x = sp_que(&current_sprite, -1);
      if (&save_x != 0)
      {
        //no que set - let's set it correctly
        &save_y = sp_pframe(&current_sprite, -1);
        &save_x = sp_y(&current_sprite, -1);
        if (&save_y == 10)
        {
          &save_x -= 113;
        }
        else
        {
          &save_x -= 116;
        }
        sp_que(&current_sprite, &save_x);
      }
    }
    
    //we don't want to mess with the custom clipped sprite, so kill this off here
    kill_this_task();
  }
  
  //Now check clip_top
  &save_x = sp_clip_top(&current_sprite, -1);
  if (&save_x >= 178)
  {
    //editor clipped to only show top tree of edge sprite
    //check for custom clipping
    &save_x = sp_que(&current_sprite, -1);
    if (&save_x != 0)
    {
      //no que set - let's set it correctly
      &save_y = sp_pframe(&current_sprite, -1);
      &save_x = sp_y(&current_sprite, -1);
      if (&save_y == 10)
      {
        &save_x += 92;
      }
      else
      {
        &save_x += 84;
      }
      sp_que(&current_sprite, &save_x);
    }
    
    //we don't want to mess with the custom clipped sprite, so kill this off here
    kill_this_task();
  }
  
  //check if the sprite is placed in a way that the the top tree of the edge sprite is off-screen
  &save_y = sp_y(&current_sprite, -1);
  if (&save_y <= 94)
  {
    //top tree offscreen - skip clone sprite creation
    goto set_main;
  }
  
  
  //get the x and y of current tree edge sprite
  &save_x = sp_x(&current_sprite, -1);
  &save_y = sp_y(&current_sprite, -1);
  
  //create the extra sprite and clip
  &save_x = create_sprite(&save_x, &save_y, 0, 32, 9);
  
  //initiate clipping for sprite
  sp_clip_right(&save_x, 51);
  sp_clip_bottom(&save_x, 377);
  
  //now actually clip it
  sp_clip_bottom(&save_x, 180);
  
  //set proper frame and que of clone sprite
  &save_y = sp_pframe(&current_sprite, -1);
  sp_pframe(&save_x, &save_y);
  if (&save_y == 10)
  {
    &save_y = sp_y(&current_sprite, -1);
    &save_y -= 113;
  }
  else
  {
    &save_y = sp_y(&current_sprite, -1);
    &save_y -= 116;
  }
  sp_que(&save_x, &save_y);
  
  //check if the sprite is placed in a way that the the bottom tree of the edge sprite is off-screen
  &save_y = sp_y(&current_sprite, -1);
  if (&save_y >= 471)
  {
    //bottom tree offscreen - kill off current_sprite, it's no longer needed
    sp_active(&current_sprite, 0);
    kill_this_task();
  }
  
set_main:
  
  //clip current sprite
  sp_clip_right(&current_sprite, 51);
  sp_clip_bottom(&current_sprite, 377);
  sp_clip_top(&current_sprite, 185);
  &save_y = sp_y(&current_sprite, -1);
  &save_x = sp_pframe(&current_sprite, -1);
  if (&save_x == 10)
  {
    &save_y += 92;
  }
  else
  {
    &save_y += 84;
  }
  sp_que(&current_sprite, &save_y);
  
  kill_this_task();
}

I attached that to every forest side tree in Charlie's Legacy and it worked pretty good. You can use it for either facing edge tree sprite.

I made a complete tile tree as a single sprite and use that in both SOB and PQ redux, as the half tree thing was annoying, and having a single full tree that looked like a tile tree meant it could be placed where ever I wanted.

@SimonK So you use them instead of tiles completely? Doesn't that impact performance?

He definitely doesn't replace them completely, just uses it where convenient.

But even if he did, it would not really affect performance in any way since you couldn't have more than 100 editor sprites on the screen at any time.

A single static sprite won't have any impact on performance even at considerable size. If it did, we'd be cursing at title screens for causing FPS drops.

Hmmm... Then I could just throw in regular trees and forget about forest tiles.

I only use the complete forest tree sprite where using the split ones annoyed me, or if I wanted to have a single tree with hardness to block off or fix tile hardness.

Thinking about it now, I should've have used that tile coloured tree and a version of it burning to replace all the trees in my development jam, just to see what the effect would be. Probably a better way to hide burnable trees if you put one next to a forest.

Uh... I'm starting to remember why dmoding can be extra tedious affair. Too many little hurdles along the way.

Does anyone know if WDE has some issues with loading hardness? I have two houses and a tree. The tree was set as a hard sprite, yet Dink can walk right through it (the trunk). One house behaves as expected, the other just ignores most of the hardness tiles stamped over it...

It's most likely a file permissions issue. WDED and Martridge can load/run anything regardless of location, and don't force you to use Program Files like it's still the Windows 98 era.

@yeoldetoast Not sure how to check/resolve that... Restarting my machine usually helps... but...

It's impossible to know without an error message, but if sprite properties aren't showing up, it suggests that there's a problem with writing to map.dat. Simplest way to check would be to look at file properties before and after saving.

Otherwise, the only thing I can think of is the use of savestates, which won't reload the screen until you walk to another and then back again.

I'm feeling dumber every day... Is there any script anywhere to show me if I killed all enemies on screen (I'm creating them manually, I know the count) so that I can remove screenlock?

You just want to know if all monsters are dead, right?
Just do something like this:

if (get_sprite_with_this_brain(9, 0) == 0)
{
  if (get_sprite_with_this_brain(10, 0) == 0)
  {
    //No monsters remaining
    screenlock(0);
  }
}

Thanks. The counterintuitive part was that this had to go to enemy's die() procedure. Ugh. There really should be a DinkC tips 'n hacks document.

Sigh... I have a script attached to a screen. In one place it is supposed to create a box:

// void main( void )
int &box = create_sprite(170, 290, 0, 444, &frame);
sp_hard(&box, 0);
draw_hard_sprite(&box);
// crap after

No matter what I do, the sprite isn't hard. I tried using draw_hard_map(); just below it, to no avail... What am I missing?

It appears SlipDink encountered the same problem, but nobody figured it out at the time. I can't seem to get it to work either.

Hmmm, it is an inconsistent error. I made a script that generates a box with frame random between 1 and 7 and sometimes it was hard, sometimes not, but then it was hard more often than not once I started generating a box on each screen I moved to.

// test create box
void main (void)
{
int &frame = random(6, 1);
int &box = create_sprite(170, 290, 0, 444, &frame);
sp_hard(&box, 0);
draw_hard_sprite(&box);
kill_this_task();
}

Then I varied it so that I got a line of boxes for each frame horizontally and sometimes the last one was not hard, but after a few presses it was hard like all the others.

// test create box
void main (void)
{
int &frame = 1;
int &box;
int &bx = 80;
boxline:
&box = create_sprite(&bx, 290, 0, 444, &frame);
sp_hard(&box, 0);
draw_hard_sprite(&box);
&frame += 1;
&bx += 80;
if (&frame < 8)
	goto boxline;
kill_this_task();
}

Well, I figured out what I was doing wrong. I was testing it using editor sprites which, it turns out if you alter using scripting, also alters the "hard" field for the editor sprite which is then used by draw_hard_map for recalculation, rather than it just using the property for the corresponding live sprite, which in this case I was altering directly.

The main take-away from this is that live sprites created with scripts behave differently to live sprites derived from map sprites in some cases.

I've made a test screen as well. Now it also became inconsistent. So far I was only getting no hardness. The original box was placed on top of cave "edge" tile which has automatic hardness drawn. I wonder if hardness overlaps may trigger this... Though, so far, nothing supports that theory.

More questions...

1. I recall someone somewhere mentioned that scripts with .d extension shouldn't be used. So far, I've copied a few such item related scripts from the original game. Should I find .c versions, and where?

2. Is there a way to check if used bomb hit a specific target, and execute some code if it didn't? Or at least, how to check if the bomb was used?

The main take-away from this is that live sprites created with scripts behave differently to live sprites derived from map sprites in some cases.


So is there any fix to the randomness of that hardness bug? I've had it happen too a few times now. Quite annoying.

Regarding my question... It seems what I wanted to pull off was way beyond DinkC capabilities... Nevermind...

At least "vanilla" Dink Smallwood comes scripts on file called source.zip on develop folder (HD seems to not include it).

For bombs:

For checking if bomb hit something you usually do something like this in the intended target's hit procedure:

void hit( void )
{
  int &rcrap = compare_sprite_script(&missle_source, "dam-bomn");
  if (&rcrap == 1)
  {
    //do stuff
  }
}

see e.g. s4-rock.c on main game.

To do something if bomb doesn't hit stuff...
The best I can think is to modify dam-bom.c with something like this at the end:

//Wait for the bomb hit sequence to end
wait(1400);

//&foo here is some global variable - the intended target should set it to 1 when hit with the bomb
if(&foo != 1)
{
  //bomb did not hit
}

Note: if you do modify dam-bom.c, please add a "script_attach(0);" at the start of the main(). This will fix an annoying bug in bomb use.

Thanks, but I had to find a workaround, since other bugs started popping up, for which I have no patience.

For example, a sprite created in one script, and then fetched in another using get_sprite_with_brain() (I know there's only one on screen), and then freezing it, freezes the whole game.

But again, in my scenario, it's avoidable.

If the engine's locking up, it usually means you forgot to chuck a wait in somewhere. Unsure if it was brevity but the command is get_sprite_with_this_brain.

To Robj: I cannot replicate it in my tests. The one duck on the edge of the screen is an editor sprite that spawns a script sprite (when it moves top left) and then runs draw_hard on it which works every time.

Interestingly, it also recalculates it for the editor sprite duck, even without draw_hard_map, which appears to be an undocumented feature. Map sprites may also be distinguished by leaving behind a slightly different-coloured box on the overlay. If someone can make a minimal reproduction that semi-reliably fails i'll look into it.

edit: tried again using collapsible boxes and ran into a wrong hardbox when not using preload_seq which would explain SimonK's inconsistency, but even then draw_hard still worked. Might need a wait between creating the sprite and its draw_hard for the engine that doesn't support preload_seq .

Oh cool, preload_seq still exists in yedink. I thought it might have been removed like in DinkHD.

It's useful for a couple of situations to fix weird things.

Closest I did to getting rid of it was temporarily removing the "Please Wait" flashing banner for a while, due to it sometimes causing a crash, but it's back now I think.

I did some more little tests. This one created a collapsible box without using preload_seq beforehand or a wait before running draw_hard_sprite and ended up having an improper hardbox each and every time it first ran, while still generating a square I couldn't walk into. In the duck test, the duck graphics were already cached because of the map sprite duck, and always worked as expected.

After creating a second collapsible box and running draw_hard_sprite on it, the first box with the improper hardbox had its proper box applied, while still leaving behind the original bogus hardbox. The second box and all those following also received proper hardboxes. Only running draw_hard_map to recalculate the entire screen's hardmap got rid of the first box's improper box, while keeping the proper one.

With a wait (I used 100ms) or preload_seq before running draw_hard_sprite, the first box received its proper dink.ini-specified hardbox box every time. In all cases, it generated some sort of square on the hardmap I couldn't walk into, even if it was not the one specified in dink.ini.

I came to the point where I'm adding midis to my dmod. However, whenever I call playmidi(), the game freezes for about two seconds, which is annoying. I'm using freedink on windows 10. Is there a way to reduce the lag?

Also, does loopmidi() loops forever, or is this attached to a specific script lifetime? You call loop midi on one screen, and go to the other.

EDIT:
The freeze also happen on midi loop starting over.

The setting of loopmidi will only become apparent when the next background music is played. It will not affect what's already playing at the time of invocation. When set to 1 it will loop indefinitely.

whenever I call playmidi(), the game freezes for about two seconds, which is annoying.

Pretty sure it's not strictly a Dink issue, but some kind of modern Windows midi playback issue. I don't know what the technical reason is and googling for "midi lag" is hopeless because it just brings up a bunch of stuff about recording latency, but I've noticed it happens with other things that use midi as well.

Bah, every time I see this thread bumped the title jumpscares me - "WDE crashed?! AGAIN?! It keeps happening!"

@Scratcher
T'was probably due to my crappy way of installing Dink. Using freedink properly, solved it.

@drone1400
WDE 2+ yes. Drone edition never failed me

I do hope you'll implement screen zoom. Working with pixel perfect stuff is really hard to see on modern machines.