The Dink Network

TheNotSoNewGuy has been here for a few days (or was it a few years?) and has already released his first file:

The Dink Exploding Missiles Superfix superfixes that bug you have probably come across where missiles explode prematurely for no apparent reason.

So it isn't just Dink's incompetence after all...

Uhh, wow?

I'm gonna check this out soon and comment on it If it works like documented that's pretty big.

Errr.. what is this bug you are talking about?

It's nice to have a new productive member!
(Haven't noticed the bug though )

Wow, it's true! Sometimes the fireball just hits Dink hand and becomes a harmless puff of smoke before it goes off.

Yeah, I think I've noticed it too.

Strange. Honestly, that's actually never happened to me.

Never noticed that it's much more productive to shoot monsters from below than from above? It's because damage and experience text sprite are for unknown reasons not set to nohit. So fireballs explode when they touch them. Which means you can only attack a monster from above again, after the damage text has vanished. Very annoying indeed.

Nice work fixing this. Well, working around.

This worked excellently! A huge improvement I must say. Those saying they don't notice have literally become so used to the bug that it feels like it's a gameplay mechanic, but it's a LOT more accurate now.

Thanks for this file Implementing it on all my missile scripts.

I'm glad you all find it useful! In the original Dink it is only a small issue, but for DMODs that want to implement faster explosive shots it can really be a game changer.

nice so gonna use it and dunno why but that wizard guy felt like a dweeb somehow so i just had to kill him XD

Haha, Merder. Yeah, that's pretty much what I was going for when I made the wizard. There's a secret in the wizard room if you can find it, nothing special but it may give you a laugh if nothing else.

There's a secret in the wizard room

You put a secret in a dmod which is only meant for showing how a new script works?

Awesome!

Cool beans. You forgot one fix, though, which is the dreaded moving acid rain of Windemere! Try shooting acid rain diagonally at a duck, and you'll notice the missile doesn't stop moving even though it changes into a rain sprite. (This is because the item-ice script uses sp_mx and sp_my for diagonal movement, and the dam-ice script only sets sp_speed to 0; not sp_mx and sp_my)

Thanks Scratcher! I have seen that bug but it's been such a long time since I've noticed it that I forgot all about it. I just now fixed it (took like one minute, thanks to your info), but I'll wait a bit for another release just in case somebody finds something else worth adding or fixing. I added you to the credits for your suggestion.

thenewguy has been here for less than a week and he's already boosted my faith in the community.

On topic of the fix though, has anyone noticed that missiles will sometimes go extremely fast? I've looked at the missile scripts more times than I'd like to remember and there's not really anything in there that would randomize speed, so I'm basically wondering if it's an engine thing or just my machine.

My faith in the community fell when Whinny left, now there is no balance, the law is overpowering the criminals. It will go mad man, we have no crime happeneing since the law doesn't have it's hands partially full of Whinny and the other major.

That happens on my machine, too, so I think it's an engine thing. I'll probably look into it when I get bored again

I've also noticed the random doubled missile speed; it's noted at the end of the readme for this file as a glitch I know about but that isn't fixed by the new scripts. Unfortunately, I don't have any idea how to fix it... I reckon it involves how the engine handles sp_mx and sp_my, but I can't be sure. Maybe on rare occasions it adds the mx/my twice instead of once?

Now I'm tempted to run some tests to see if the mx/my is still the same when the missile goes really fast. if so there might not be any way to fix it without digging into the source.

And yeah, sorry I've joined the Dinkiverse so late...but hey, it's impressive that Dink is still alive in 2013, all the way from 1997(9). And even though Dink is starting to get old, I think at the very least we haven't seen his last great adventure yet.

I don't think that can really be fixed. I believe it has more to do with your computer than Dink. Mr. Smallwood sometimes tends to even walk hella fast when your computter gets a sudden burst of energy.

I don't think that can really be fixed.

Everything can be fixed. Computers only do what they're told. So anything that is not as the programmer wants it, is an error in the program.

However, the question is which program: if it's an error in the engine, it may be fixed in Freedink, but regular Dink doesn't get updates AFAICS.
Not that it needs to; Freedink is a great replacement. The only downside I heard about it so far is some missing sounds. I'm working on that. If it's an error in the dmod, it can certainly be fixed. But I fear it isn't in this case.

I believe it has more to do with your computer than Dink. Mr. Smallwood sometimes tends to even walk hella fast when your computter gets a sudden burst of energy.

I've seen the missile thing, but don't recall ever seeing Dink run very fast.

Anyway, this can indicate either of two things:
1. the program expects a slow computer, and runs at the maximum speed possible. This is not the case for Dink, or it would be unplayably fast on recent computers.
2. There is an error in the program, which causes his speed to change.

Since 1 is not possible, it must be 2. Errors can be fixed.

Where is your new engine Shevek! We're waiting for it

Where is your new engine Shevek!

I'll post a demonstration video soon.

I suspect the fast missiles is due to two different timing systems going out of sync. Similar to how hellfire type missiles can hit the same enemy more times than normal if the game is lagging. Something along the lines that the sp_timing has triggered several times but the game's main timing 'tick' is slowed down so the actual movement hasn't beenr registered and performed. Then the engine catches up and performs multiple moves rapidly.

Haven't done any testing so that might not be it, but if it is, it would probably not be so easy to fix. The sp_timing would have to be based on the 'tick' so that any lag would lag everything equally and consistently.

The missile fix/bandaid looks pretty cool. Only had a brief look. I wonder if adding in another bandaid to stop missiles exploding on grass or other sprites that dmod auhors often forget to set to no_hit might be a useful addition

Someone, I actually thought of doing that (the bandaid you mention in the last paragraph). The main reason I opted not to is because it would be a slightly bigger change to the functionality. But what could be done is first check the missile_target brain is 0, then check whether it's not hard. If both are true than don't explode. I think that would work pretty splendidly. Then just hope none of the secret tunnel trees in the DMOD are set to soft or similar important things to shoot soft, or you won't be able to deal with them without fixing them in the editor.

Maybe I'll add an excerpt for people to add to their scripts if they want that functionality (for the next version), but I'm afraid of making it all too complex. I'm hoping to keep things as simple as I can. And I really don't want to break anything important...that's the hard part, I think.

Also, you are in the credits, Someone, because I reference your FIFO and variables tutorial. Thanks a lot as it's helped me much in my DMOD!

But what could be done is first check the missile_target brain is 0, then check whether it's not hard. If both are true than don't explode. I think that would work pretty splendidly.

It should be possible to do this, though. I think it would be better to fix this in the editor: select all those sprites and set them to nohit. My editor cannot do that yet, but it will. If I understand the workings of SpriteReplacer correctly, it can do it.

I agree, Shevek, fixing it in the editor would be perfect.

I would hate to reinforce a bad habit in DMOD authoring (not setting nohit) by fixing something that isn't broken with the missiles. But still, for those who would like to implement the previous idea to improve a DMOD without going to the trouble of fixing all the nohits, I think it would not be hard to do. However, the annoying hit sound when you use a melee weapon on them would still happen.

I suspect the fast missiles is due to two different timing systems going out of sync.

I don't think this can be the problem. The two timing systems, at least as I made it in my engine, are that the (internal) brains are called once every sp_speed, but the animation runs at sp_timing. For my engine, if the computer can't keep up, the brains are called less often (leading to slower movement), but the animation just skips (it handles, but doesn't draw) some frames, and therefore continues at its normal rate. Why is this a problem? Because sprites hit other things when their animation reaches a "special" frame. So if the animation continues, but the movement doesn't, that influences the place where the hit takes place.

However, hellfire is probably different. The above is about the attack sequence. For my engine at least, missile explosions are triggered from the brain, so if the brain is slowed, there are also fewer hits, and the number of hits per distance is still the same. I think this will be the same in Seth's engine. I suppose this is just another bug in the engine...

Hmm, I thought of something. Instead of using the basic sp_mx and sp_my to make the missiles move, the missile could run a loop that increments it's sp_x and sp_y based on predefined values (like it's sp_gold, and sp_defense).

It would be complex and there's a chance it might still not work. There's also the fact that every single missile item would have to be edited as it's a problem with all of them. Now if only these things could be fixed in the engine it would be a lot better...unfortunately, I'm not your guy, as I am not skilled at understanding the Dink source.

That would be incredibly laggy with more than a couple of missiles on the screen...

Wow. If I had done a bit more experimenting I would have figured this out in no time!

It isn't the sp_mx and sp_my that are the problem. It is the sp_speed!

The reason there is a problem is because for example, the speed of the fireball is set to 6 in case you shot it in a non-diagonal direction. mx and my are only used if the shot is diagonal which is why it only goes twice as fast if you do a cardinal direction and not a diagonal. In other words, I got rid of the speed change in fireball and made it all operate by sp_mx and sp_my. From what I can tell, the doubled missile speed is now gone! Yeah! I'm sure the same thing is what's plaguing the other ranged weapons. One more bug down! It'll require replacing a lot of scripts but I think it's worth it to have these fixed.

So now I wonder, is the increased speed a conflict between the two movement systems, or is it just a glitch that happens with sp_speed?