Okay, so i see where you are coming from, the "objToMove" is actually the turret, its just supposed to AIM at the enemy where it wont miss, the bullet is handled separately, but it is fired after we aim, i want to keep them 100% seperated, as the bullet does not know what it will be hitting cause there will be different turret modes. I also am not a fan of Alarms, u could probably tell that i just need a script that aims at the enemy, kinda like we do when we are shooting projectiles in games, but this takes it an extra step cause it will know where the enemy will be related to its path.
Also just to clarify "target" is the enemy we have targeted from previous code, and the "wpSpd" is the speed of the bullet the turret will fire
I hope this clarifies a bit of what im talking about?
Also, what is this "wcs_" variable? And why do we just randomly add "0.1" to our path length?
edit:
I'm dumb, I just needed convert the delay to dist and factor it into the script, you may find it a little more in accurate like maybe by a tiny bit because
Code:
// This below is the part you are missing I think :D
if _wcs < _timeenemycompletion // Here is where you might want an accuracy check. e.g. if _timeenemycompletion - _wcs > ACCURACY
{
_possible = true
}
else
{
_possible = false
}
if _possible
{
// The point you have decided to fire to, 100% accuracy because of absolute check above
var _pointafterwcs = (_faralong * obj_enemy.lengthofpath_
+ _wcs * obj_enemy.pathspeed_)/obj_enemy.lengthofpath_ + 0.1
// The distance in pixels the enemy is from reaching that point
var _pointpathdist = (_pointafterwcs - _faralong) * obj_enemy.lengthofpath_
// The distance in steps the enemy is from reaching that point
var _enemystepstoreach = _pointpathdist / obj_enemy.pathspeed_
_bullettraveldist = point_distance(x, y, _xx, _yy) // SHIFT THESE TWO UP
_delay = _enemystepstoreach - _bullettraveldist/12
var additionaldist = _delay * obj_enemy.pathspeed_ / obj_enemy.lengthofpath // ADD THESE TWO LINES IN
_pointafterwcs -= additionaldist
_xx = path_get_x(path_random, _pointafterwcs)
_yy = path_get_y(path_random, _pointafterwcs)
}
}
Now there's no delay. Might sometimes be a fraction of a pixel inaccurate because I suspect the calculation is not optimize enough in that it takes away too many decimal values from the rounding too many times? Maybe
Just ignore everything below about the time needed if you don't want to know how the calculation is done. Now the script has factored in the time as distance too.
------
before edit:
Hmm at least to my knowledge, it is impossible to take aim at an enemy on a random non linear path where it WON'T miss if you don't want to know where the enemy will be relatative to its path. If you don't want to miss, that step is necessary. If you don't want to miss, you need to know the path, because the enemy can move any direction at any point in time for a non linear path.
Imagine your turret is an officer on a spaceship, he is in charge of aiming the spaceship at the enemy. What he needs to do it, tell the spaceship where to aim (angle) AND tell the spaceship when to shoot. But now you want it separate, so you need another officer, officer2, to tell your spaceship when to shoot. Your script is officer1 which tells it where to aim, but you don't have officer2 to tell it when to shoot? All you need to do is to either make your bullet officer2 to tell itself when to shoot, or create another object to be officer2 to shoot all the bullets. All this is NEEDED if you don't want to miss hitting a target on a random non linear path, at least to my knowledge.
Your original script is correct in taking aim at the enemy. But you noticed it always falls a little short of the enemy, because officer2 is missing. If you just want you turret to AIM at the enemy, it is already doing so.
wcs_ means "worst case scenario", which means for a non linear path, what is the worst possible amount of time it would take to hit the enemy at a point along the path, and that worst possible scenario is if the enemy is travelling directly away from the projectile.
IF the projectile is able to hit the enemy at the worst case scenario, it will be able to hit the enemy at a point on path anywhere after the worst case scenario point. It is the logic behind getting 100% accuracy to hit a random non linear moving enemy.
The 0.1 I added is just an example. If my wcs_ point is 0.7, you will have to fire at any point after 0.7 that is why I added 0.1, you could also do 0.7 + 0.01 or 0.7 + 0.3 and it will also work. As long as it is above 0.7.
However, you COULD technically use 0.7 but the rounding of numbers made by gamemaker might affect the true value and hence why it is better to use >0.7.
IF you use anywhere below 0.7, for example 0.65, it MIGHT still hit, assuming the enemy did not make a worse case scenario maneuver which is travelling directly away from the projectile. The lower you go from 0.7 the higher the chance to miss. With 0 being a complete miss unless the enemy is travelling directly towards your projectile.
This wcs step is for optimization, you can technically search through every point till you find apossible point like a O(n) search however for VERY long paths it might get too tedious. With the wcs, you can get the desired point in 1 step an O(1) which is very fast even for long paths.
All these calculations are to HIT an enemy on a RANDOM NON linear path. To my knowledge, you need BOTH Direction AND Time to achieve. I do not think you can calculate a 100% hit on an object with random angular velocity (random non linear path) with just direction alone.
However, if you just want to aim and fire at a location relative to the velocity the enemy was moving at at that point in time? If that is the case then it is predicting a LINEAR PATH and firing at a linear velocity, and
@Jordan Robinson's script will fit your requirements perfectly.
Sorry I might have misunderstood your original question incorrectly, I assumed you wanted to HIT an enemy moving on a non linear path, but it seems like you just wanted to fire at an enemy relative to his current linear velocity at that given time. That would technically still be a linear path calculation that was why I got confused.
If you still want to use the code I provided and just want to JUST AIM and fire without the time calculation, increase the 0.1 value, that way it will know to shoot further ahead. This may be what you want instead. BUT it is not a guaranteed hit.
And alarms are the simplest way to execute code after a certain amount of time in game. Unless you want to manually count the steps yourself which would be like an alarm but just manually.