The Dink Network

Does anyone know which d-mod or development file handles NPCs shooting missiles best? This can range from stationary objects or NPCs firing arrows or fireballs to moving NPCs with a nice script thta aims at Dink, maybe even fires fireballs that move slightly towards Dink while in the air.

Hidden deep in the recesses of my mind I seem to remember there being a few d-mods or files that handle this well. The obvious Enemy Shoot script I already have, but it is bugged in 1.08 because hitting an NPC stops the callback procedure.

Try the one in Someone's mouse pointer dev file.

That's exactly what I needed. Now to understand those scripts and configure them to my own needs, will be a fun challenge Thanks!

I must ask:

"1.08 because hitting an NPC stops the callback procedure"

Is this true for all callback procedures or just this particular script?

All callback procedures unfortunately, including the ones in the original game. An example of this is the dragon script, where a callback procedure is used to proc random magic attacks. The problem lies in the internal wait (also random) for a callback procedure to be run. While this wait is in progress, any hit/talk/push the sprite triggers will stop the callback from occuring.

Well then, I won't ruin the challenge for you and offer any guidance if you're so keen

I think there are three things to AI for shooting missiles:

1) Shooting in any direction. There is a script in MouseDink that can do this. It's essentially a superior version of the enemy shoot scripts, as those scripts only shoot in 8 or so directions while mine can shoot in any direction.

2) Missiles with mild homing effects. I *think* I, Kara Gu may have missiles like this, but I remember them being fairly unsophisticated. In MouseDink, I had homing missiles (the ones Dink can shoot) that cannot make drastic changes in direction. Thus, they are homing missiles but they can still be dodged.

3) Prediction. Obviously, shooting directly at Dink is not enough, because if Dink was moving, he would be in a different place by the time the missile reached its destination. I tried to write a prediction script when I wrote MouseDink but didn't achieve any satisfactory results. The equations are easy to derive with simple algrebra but the problem is the exact equations cannot be solved with Dink's fixed point integers. Information is lost. I tried to come up with an approximation equation that could be solved without loss of information with fixed points integers, but didn't achieve anything impressive. There are no scripts that handle prediction in MouseDink. EDIT: actually, thinking about it, coming up with a decent approximation formula may not have been the main problem. Inconsistencies in Dink's timings made predicting the missile speed relative to Dink's speed inexact. I may have concluded good prediction was therefore impossible, but I can't remember.

Good luck with adopting the scripts, and feel free to tackle prediction AI

While this wait is in progress, any hit/talk/push the sprite triggers will stop the callback from occuring.

Now I suddenly understand what Seth means in DinkC.txt where he (and the annotator) writes

Same as say_stop, but will not let the PLAYER skip things by hitting space
- if the player may be talking to someone else while this is called, (like
two girls talking in the background) you should use this...

[Seth's explanation up to this point makes perfect sense. But then he goes
on to say:]

...it is safe. Otherwise callbacks may conflict.

[This part is totally enigmatic. What does he mean by "callback" in this
context? What would be "unsafe" about two girls talking in the background?
Oh, never mind. Maybe I just answered my own question...]

[Kidding, ladies, I'm kidding. Sorry 'bout that.]


The unsafe part would be that a callback into the script is required when pressing space to make the girls continue talking, and another one when for the other conversation you're trying to have. I think Seth was a bit confused anyway, as this doesn't seem to be a particularly good example for the problem, but I think I finally understand what problem he's talking about.

The equations are easy to derive with simple algrebra but the problem is the exact equations cannot be solved with Dink's fixed point integers.

Not sure how easy it is to implement in dinkC, but in general, you should remember the starting point and the intended target (which is static if you don't want homing; if you do, things are much more complicated in a way (and easier in another)), and for performance also the total distance between them (sqrt(a**2+b**2), eh, yes, that's a square root... an approximation will do, I suppose...) Then every step you need to compute the next position: fraction=current_distance/total_distance; pos=pos_begin+(pos_end-pos_begin)*fraction. Don't forget to multiply at the start and divide at the end, to simulate using fixed point instead of integer computations. Otherwise fraction is always 0.

Once you know the current position and the position for the next step, and you know how to move in arbitrary directions, things should be easy to make.

Inconsistencies in Dink's timings

This for sure. Sometimes missiles just speed up randomly and that would just mess up any predictions right away. I don't think it's really that needed for Dink anyway. In non-mouse controlled environments dodging missiles is done in 8 directions anyway, so it's not as important to have good skillshots.

I found and analyzed the regular shooting script, very nice math work there, nothing I could ever reproduce unfortunately. Luckily, I think I can copy paste sections of it to make it work fine for my needs

In non-mouse controlled environments dodging missiles is done in 8 directions anyway

You're right. Dink can normally only move in 8 directions! I feel a bit silly now. As I was remembering my old thoughts, I somehow overlooked that they were all about missile prediction specifically for MouseDink. Missile prediction with ordinary Dink would be much more feasible.

I'm not sure if I understand what you mean Shevek. It sounds like you are just talking about shooting in an arbitrary direction. Also, homing is much, much easier than prediction. Predict is about *finding* the intended target position. Assuming Dink is the target, then obviously you have to start with Dink's current position, then add to it depending on Dink's speed, Dink's direction, the missile speed, and the distance between Dink and the shooter. I think I remember I had problems solving the equation in DinkC with a single int value, because all the squaring would produce values too large for an int. I guess it is possible to try to store a single number across multiple integers, but I didn't try that. But the main problem (I think) was that the timing of both Dink and the missiles were very inconsistent in Dink (especially in MouseDink where so much is controlled by DinkC with wait() statements). So if the missile a bit slower than expected, the prediction formula would fail and the missile would miss Dink. If anyone could produce a perfect prediction formula for MouseDink (i.e., the missile always hits Dink unless he changes his direction after the missile is fired) I would be very impressed, but I don't think it is possible.

Giant high-speed cannon ball with low chances of dodging unless fired from one side of the screen at Dink while hes on the opposite side?

Colour me impressed.

I'm not sure if I understand what you mean Shevek. It sounds like you are just talking about shooting in an arbitrary direction.

Right, I misunderstood the problem.

The calculations for prediction are long, but not particularly hard. They should be doable in dinkC as well. The square root is the hardest part of that, but it can be done with a sequence of divisions.

To give a proper answer, I need to know how the information is stored by your dmod. I'm too lazy to check, so I'm just asking. Do you have a two-coordinate speed vector, which gives displacement of dink/missile per time step?

I had 5 hours of math at school and I never learned any of that I consider it my biggest shortcoming when dealing with any complicated scripting that I want to use