Quick Modding/Hacking Answers Thread

How do I use sine and cos to make an projectile home in on a destination? (the player)

In your case of using assembly language to make a projectile in Cave Story move toward the player, there is no need to use the sine and cosine functions. Traditionally in mathematics for cases such as this, angles are plugged into the sine or cosine in order to find the x and y distances between two objects when they are not given. Since in assembly you should be able to refer to where the x and y positions of the player and projectile are, you could simply subtract the player x and y positions from the projectile counterparts, and you have the x and y distance between the two objects. I am going to assume that you know what to do with the x and y distances between the objects.

 

I am going to assume that you know what to do with the x and y distances between the objects.

Actually... that's the only part I don't know. >_>

I figured (no pun intended) that is had to do with subtraction before I heard about sine and cos.


E:

mov eax PlayerYpos
mov edx npc.Y
sub eax, edx
push eax


triple E: Now it's homing in, but it's going waaaaaay to fast. I tried putting buffers on it, but that sets off the homing part...
---

How much velocity is lost per second for an npc?

 

In your case of using assembly language to make a projectile in Cave Story move toward the player, there is no need to use the sine and cosine functions. Traditionally in mathematics for cases such as this, angles are plugged into the sine or cosine in order to find the x and y distances between two objects when they are not given. Since in assembly you should be able to refer to where the x and y positions of the player and projectile are, you could simply subtract the player x and y positions from the projectile counterparts, and you have the x and y distance between the two objects. I am going to assume that you know what to do with the x and y distances between the objects.

Actually you would still want to use cosine and sine (or maybe tan/arctan) if you wanted something to move towards the player at a consistent speed. If you can show me a formula that, say, makes an entity move at speed 100 towards the player without cosine and sine, I'll believe you, but I'm pretty sure you need those trig functions.

 

Actually you would still want to use cosine and sine (or maybe tan/arctan) if you wanted something to move towards the player at a consistent speed. If you can show me a formula that, say, makes an entity move at speed 100 towards the player without cosine and sine, I'll believe you, but I'm pretty sure you need those trig functions.

So how does the con/sine (or tan/arctan) function work?

Because the problem I'm having is that it's targeting the player (and hitting it) in 1 frame.



----------------------
what does


[LOCAL.1+3]

aka

[EBP-1]

do?

 

Actually you would still want to use cosine and sine (or maybe tan/arctan) if you wanted something to move towards the player at a consistent speed. If you can show me a formula that, say, makes an entity move at speed 100 towards the player without cosine and sine, I'll believe you, but I'm pretty sure you need those trig functions.

Semantically speaking, you are right. Even in cases with the distances provided, you still need to divide the x and y distances by the hypotenuse of the formed right triangle, which gives you the sine and cosine of one of the angles, but you're technically not using the computational sin/cos functions themselves. If you wanted to make an object travel in a specific direction without the destination predefined, rather than towards a specific position without the direction predefined, then you would certainly need to use the sin/cos functions.

@Bombchu and GIR
Pretend you set the speed of your projectile to 100. The first thing you want to do is get the total distance between the projectile and the player. To do this, take the square root of the sum of the squares of the x and y distances between the projectile and the player. Divide the horizontal distance by the total distance, multiply the result by 100 (since that's the speed you want the object as a whole to travel), and that's what you want to set as the horizontal speed for the projectile. Now divide the vertical distance by the total distance, multiply that result by 100 as well, and that's what you want to set as the vertical speed for the projectile. Now make your projectile travel at the horizontal and vertical speeds you calculated, and it should travel at a speed of 100 units toward the point the player was on when this calculation was made.

 

Then just have that calculation repeat every tick, and you've got a homing shot, unless I'm mistaken.

 

@Bombchu and GIR
Pretend you set the speed of your projectile to 100. The first thing you want to do is get the total distance between the projectile and the player. To do this, take the square root of the sum of the squares of the x and y distances between the projectile and the player. Divide the horizontal distance by the total distance, multiply the result by 100 (since that's the speed you want the object as a whole to travel), and that's what you want to set as the horizontal speed for the projectile. Now divide the vertical distance by the total distance, multiply that result by 100 as well, and that's what you want to set as the vertical speed for the projectile. Now make your projectile travel at the horizontal and vertical speeds you calculated, and it should travel at a speed of 100 units toward the point the player was on when this calculation was made.

This works (since you're basically calculating sine and cosine from the values of the triangle itself) but given that you have to square 2 numbers and then take a square root of their sum I'm not sure there's any (computational) benefits to doing it this way. Trigonometric functions are normally hardware based these days and fairly cheap, but pixel uses the fake/fast integer trig functions because he made it way back. I suspect there's no real reason to go either way, unless you really hated calling the functions from ASM, but good luck calling a square root function in ASM (there is no built in instruction for integer square-roots IIRC).

Actually yeah scratch that, this wouldn't work because this method assumes you can take the square root, which you (sort of) can't. Not without converting to a float first, anyways (or maybe there's a built in function for integer square roots hiding somewhere in the exe).

 

So, do things like bones and purple orbs use all these complicated calculations? I always thought homing projectiles were made to go to what the player position had been when the projectile was created. Does that use trigonometry, or is my assumption simply incorrect?

 

this wouldn't work because this method assumes you can take the square root, which you (sort of) can't.

Then you'd need the angle formed in order to properly plug into the sin cos functions. Does ASM support inverse trig functions? I guess then you could get that by taking the inverse tangent of the y distance over the x distance.

Please enlighten me and Bombchu by explaining the technique Pixel used/you would use to make a projectile home in on the player.

 

I'm trying to start a boss fight that begins with the doctor in his muscle form, and when I type this in and use a Horz/Vert trigger (I checked, it works) to start the script, it doesnt even show the boss at all. Help?





<KEY<CNP0420:0267:0000<WAI0010<ANP0420:0007:0000<END

 

What size map are you using?
I think certain teleportable bosses like the Muscle Doctor only work well in a short-sized map (the size of the map where you fight him in the original). Putting him in a huge map will confine him to the top-left... And I think he spawns in the left-most wall anyway if you spawn him incorrectly.

 

How difficult would it be to render a larger image like <FAC does, but above the message box? Something like a Touhou style.

 

Then you'd need the angle formed in order to properly plug into the sin cos functions. Does ASM support inverse trig functions? I guess then you could get that by taking the inverse tangent of the y distance over the x distance.

Please enlighten me and Bombchu by explaining the technique Pixel used/you would use to make a projectile home in on the player.

Yeah that's how pixel does it iirc.

What I would do is first use the arctan to find the angle, and then use like cos for the x velocity and sin for the y (you might have to fiddle with your angle or add 180 to it or something depending on your coordinate system).

To see how pixel does it I would look at/literally copy the code the flying gaudi uses. Note that they will add a small random number to the angle though, to simulate imperfect aiming.

 

How difficult would it be to render a larger image like <FAC does, but above the message box? Something like a Touhou style.

not terribly hard, you wold have to move the render area of the bitmap to above the textbox (or below if it's a <MS3) and remove the text buffers onside the boxes or else the text will be over in the right.

Yeah that's how pixel does it iirc.
What I would do is first use the arctan to find the angle, and then use like cos for the x velocity and sin for the y (you might have to fiddle with your angle or add 180 to it or something depending on your coordinate system).
To see how pixel does it I would look at/literally copy the code the flying gaudi uses. Note that they will add a small random number to the angle though, to simulate imperfect aiming.

:create_object
setpointer
push 0
mov edx, npc.y
sub edx, playerypos
push edx
mov edx, npc.x
sub edx,playerxpos
push edx
call 004258e0                      ;detects player collision
add esp,8
mov localvar3,eax
mov edx,localvar3
push edx                             
call 004258b0                      ;sin table
add esp,4
shl eax,2
mov localvar2,eax
mov eax, localvar3
push eax                             
call 004258c0                      ;cos table
add esp,4
shl eax,2
mov localvar1,eax
push 100                                
push 0                                
push 0                                 
mov ecx, localvar2          
push ecx                             
mov edx, localvar1          
push edx                              
setpointer
mov eax, npc.y           
push eax                                
mov edx, npc.x            
push edx
push 115
call 0046efd0                            
add esp,20

without the random function.

 

call 004258e0

See this right here is probably your arctan, since it's returning the angle that is passed to sine and cos. And it's also passing the values needed for aiming (npc x and y).

 

See this right here is probably your arctan, since it's returning the angle that is passed to sine and cos. And it's also passing the values needed for aiming (npc x and y).

K, I'll (try) to figure it all out over copy/paste.


-----

How does npc.collision work?

 

How does npc.collision work?

What's that?

 

I guess it checks if the NPC is colliding with wall. I may be wrong, though.

This is my official 666th post. Hell yes.

 

What's that?

npc.collision = [ecx+4]

?

 

Two questions:
1. How would I make an NPC be in front of the player instead of behind (With the player standing still)?
2. What is the best way to put the player in a spesific position without teleporting them there
(IE talk to an NPC then put the player a set distace away from that NPC before talking to them)?