How do you create Z-Axis Projectile Movement?

[Kid_Roleplay]

I think it's the Trigonometry I don't get, having not applied it in a long time and so have lost it. I messed with your example and put in a few things.

MessingAround_3.mfa

The bullet, like the player, would be something that corresponds with the invisible layer. All "real" objects are on Layer 1, while all "overlay" objects appear on Layer 2. Layer 1 will be hidden, so no one will see that, while having that is useful for working with 360 degrees without having to put in angular alterations (but consequently more objects will be needed).

And yes, the height value is what I'm trying to work with. I named it "Altitude." I could make it so that it can calculate the distance and speed and then raise or lower depending on that, but at extreme heights difference with small X/Y distances, this gets to be a problem.

[schrodinger]

Ok, here's what you can do, very quick:

MessingAround_4.mfa

I've added a line for the "Z angled (while I would call it X angle, just a matter of viewpoints..) auto-targeting projectile"
Shoot it with enter key.

I've added a couple values:
X_start_angle of real_projectile is the new angular direction for vertical targeting
body_v_center of real_enemy is the height of the center of mass of the enemy in relation to its base
(so to make projectile aim at enemy body center and not base)

[Kid_Roleplay]

I do like how this is progressing so far. Now that things are looking a little clearer, it may be easier to explain!

MessingAround_5.mfa

If you place the enemy directly on top of the player to the exact coordinates, then the Projectile Speed should be zero. The projectile would be traveling vertically. Likewise, if it could be possible to adjust this speed based on the difference of the coordinates of the player and enemy being targeted. I was also thinking about some kind of acceleration, like say if a missile was being fired, and it speeds up as it travels, but that's not so important for the moment.

Now, here's what I've changed.

I added crosshairs, one that follows the mouse, and one that is the Real one, which adjusts depending on what the mouse is overlapping. It sets the projectile to be fired to the height and center of whatever is the target. Instead of spacebar and enter, I just made firing a left click, and combined the two firing codes into one.

Secondly, just miscellaneous things. I changed the counters to record information about a fired bullet, and got rid of some object alignment issues and made the mouse cursor invisible. Also updated the strings in the frame a bit to reflect what the counters are doing.

[schrodinger]

Well this is a very special case,
the Z angle "collapses" when the two objects overlap,
since arctangent needs a minimum distance to calculate the angle between two objects (ATan2 0,0 = 0)
It's likely that your player won't (almost) ever have the exact-same position of the enemy,
and even in those situations the system would behave not so indecently.

Anyway,
if you want to correct this, you could hard-code this very limited situation,
and only keep the code to alter the Z-position, that should hold true.

(So that if player Xpos=enemyXpos and player Ypos=enemyYpos
do special case --- only update vertical position
else
do standard projectile thing)

I wouldn't alter the "speed" basing on this issue,
since the cos/sin functions already take charge of that depending on angular difference for all the three axis,
while if you want to do some acceleration things you could simply dynamically alter the speed value of projectiles
from the moment they're being fired

[Kid_Roleplay]

Well, maybe overlapping perfectly was exaggerating a bit. You'll see that when you have both the player and enemy very close to each other and then fire, the speed of the projectile traveling in X and Y directions is just as fast as if aiming at nothing and firing straight ahead, while the growth in altitude doesn't grow high enough.

Even when overlapping to the exact coordinates, the altitude looks as if it's working fine but the X and Y speed would, or need to be, zero. That's all I mean.

[schrodinger]

oh, now I see what you mean,
...you're right

maybe simply correcting both horizontal and vertical speed by cos(x angle) could do
(cosine gets close to 0 when vertical angle is near 90 degrees)

i.e.

set xpos to
X_pos( "Bullet Real" ) + proj_speed( "Bullet Real" ) * Cos(start_angle_X( "Bullet Real" ) ) * Cos(start_angle_Z( "Bullet Real" ) )

set ypos to
Y_pos( "Bullet Real" ) + proj_speed( "Bullet Real" ) * Cos(start_angle_X( "Bullet Real" ) ) * Sin(start_angle_Z( "Bullet Real" ) )

[Kid_Roleplay]

You see! I wasn't kidding when I called you a scholar. :p The hard part being out of the way, now I just need to figure out how to make it accelerate as well as how to implement MoveSafely2 into it for the purpose of handling fast moving object collisions (like bullets). The latter I'll just take a look at some of the examples already sitting around.

[schrodinger]

For acceleration I think you only need to play with the speed value you already have,
maybe make it smaller by default and find a suitable good-looking way to increase its value during time.
You'll surely find a good way by tinkering around

[Kid_Roleplay]

Yep! It was pretty easy to get to work! Thanks again for everything.

... Now... if only MoveSafely2 didn't crash so much. -.-

[schrodinger]

Happy this was useful,
I'm sorry can't help with move safely, never used (though looks cool and useful)
I usually tend to handle collisions in the "math" way with fastloops

(but there seems to be some discrepancies when both target and bullet are moving,
as you may see in a recent thread by Casleziro.
I wonder if this extension would behave in a better way in that situation?)