Author Topic: What would be the function that sets a delay of a raycast judging by distance?  (Read 3740 times)

          So my question, as posted as the topic title, is how I would get a raycast/hitscan bullet to delay it's explosion judging by the distance of the target.

As the projectile speed limit is 200, then the fastest that a bullet can travel 2000 brick studs is 10 seconds.

My question is if, supposing the Raycast scanning distance is unlimited, then can a function be written that detects distance, and gets the square root of it and multiplies it by a number less than it, approaching 0, that number sets the delay.  So say if something is 2000 studs away and the raycast detects the distance, it will fire with the function and divides by 3/10ths of the total distance (2000) and then sets the total value as the delay of the ray casting hit.
Fixed, see figure below.

It is figured as follows:

Where:
T is the time of the delay.
d is the distance between the muzzlePoint node and the target.  (Measured in brick studs, in this case 2000 brick studs)





You could say that this is cheating the speed limit, but with the recent controversies over raycast/non-raycast snipers, I've decided to post this as a solution of trying to make weapons that are velocity-accurate.  A working function of this objective would help weapon makers like myself make weapons of higher quality.  As it does not disobey the projectile speed limit, it should not lag when fired and to my knowledge isn't impossible.

So tell me what you all think?  Is this possible?  Have any ideas on how this would be written?
« Last Edit: January 16, 2012, 11:26:32 PM by SWAT One »


function weaponFire::onFire(%this,%obj,%slot)
{
     //raycaststuf
     %raycast = raycastgetstuf();
     %time = timestuff(%raycast);
     schedule(%time,'',explodeStuff);
}
dingdingding
easy.

Was asking how the equation would be put into the function too.

I need a complete function.  This is rather a new concept to just be blown off.

Ok, I actually took the time to read the topic well, and this is a good concept.
Though a idk how to get the position of the muzzle node, so I will just use the position of the player.

Code: [Select]
function getTimeFromDistance(%dist)
{
return %dist / 0.3 * %dist;
}

function getDistanceFrontObject(%obj)
{
if(!isObject(%obj))
return 0;
%scale = getWord(%obj.getScale(),2);
%starter = %obj.getEyePoint();
%vec = %player.getEyeVector();
%end = vectorAdd(%start,vectorScale(%vec,2 * %scale));
%col = firstWord(%ray);

if(isObject(%col))
return vectorDist(%obj.getPosition(),%col.getPosition()) TAB %col;
else
return 0;
}

function "WeaponImageGoesHere"::onFire(%this,%obj,%slot)
{
%diststr = getDistanceFrontObject(%obj);
%dist = getWord(%diststr,0);
%pos = vectorAdd(%obj.getEyePoint(),%dist);
if(%dist > 0)
{
%time = getTimeFromDistance(%dist);
if(%time > 0)
schedule(%time,'',doExplosion,"-projectilehere-",%pos);
}
}

function doExplosion(%projectile,%pos)
{
new Projectile()
{
datablock = %projectile;
initialPosition = %pos;
initialVelocity = "0 0 0";
sourceObject = 0;
sourceSlot = 0;
client = 0;
scale = "1 1 1";
}.explode();
}
It could work, but idk.
Read threw the script, and tell me what I need to do.
I think in a second I know a fix, but ill just post here for now for safe keeping or whatever.

That should work, replace weaponimagehere and -projectilehere- with the weapon image and the projectile that explodes.
Then it should do the rest itself.
« Last Edit: January 17, 2012, 08:54:52 PM by Brian Smithers »

This problem is actually the core of what I was kinda working on with a raycast projectile mod, which would have raycasts that operate as a function of time by breaking them down into thousands of straight segments, which would make things like movement anticipation and firing ahead of the target possible with raycasts, as well as raycasts being affected by gravity or whatever.  It could do all the timing for you, but Rykuta got bored with Gears of War 3 and stopped working on the mod, so I kinda stopped working on the support scripts for it and started doing my own things.

Also I really do not understand how you are deriving your timing.  You do realize that (d/d)/(0.3) will always be the same?
« Last Edit: January 16, 2012, 01:17:53 AM by Nexus »

Brian got it right.  Nexus, it's d/0.3d

Brian got it right.  Nexus, it's d/0.3d
Wait.
My stuff works
what

Code: [Select]
function getTimeFromDistance(%dist)
{
return %dist / 0.3 * %d;
}

Where are you pulling %d from?

Anyway, the problem with this is that you raycast forward, hitting a player, then that player moves and an explosion spawns in the air next to the player.

Brian got it right.  Nexus, it's d/0.3d

that is a constant, 3.333

no matter what the distance d is it will always be 10/3

Shouldn't it simply be distance / muzzle velocity * 1000 milliseconds?

Shouldn't it simply be distance / muzzle velocity * 1000 milliseconds?

d = v*t

t = d/v

yerp

You have to split up the raycast into sections each a set length (possibly with a remainder at the end), and delay each raycast by a certain ammount. This makes it work just like a real bullet would.

brians would not work properly because things can move in and out of the way while the bullet is still in the air, which means someone could get blown up even when their not in the path of the bullet.

If you know the basics of math you should be able to figure out the first part easily, but the second part requires some thinking.

d = v*t

t = d/v

yerp

vectorDist( %start, posFromRaycast( %ray ) ) / %speed * 1000

You have to split up the raycast into sections each a set length (possibly with a remainder at the end), and delay each raycast by a certain ammount. This makes it work just like a real bullet would.

brians would not work properly because things can move in and out of the way while the bullet is still in the air, which means someone could get blown up even when their not in the path of the bullet.

If you know the basics of math you should be able to figure out the first part easily, but the second part requires some thinking.

This would decrease the framerate slightly every time a raycast projectile is fired, also decreasing it considerably in an active battlefield with many players doing this. Raycasts are expensive in computing power.
« Last Edit: January 16, 2012, 02:25:58 PM by Port »

vectorDist
Or if you're a math guy like me:



This would decrease the framerate slightly every time a raycast projectile is fired, also decreasing it considerably in an active battlefield with many players doing this. Raycasts are expensive in computing power.
Raycasts are not "expensive" in computing power. I've set a raycasting guns fire rate to 50 a second and had 25 people firing it all at once with a latency increase of only 100ms.

EDIT: whats with the ~reserved~. It's Fing pointless in a coding help topic.
« Last Edit: January 16, 2012, 02:33:21 PM by Ipquarx »