A better way of updating a fast moving object's position

[Fragorl]

Having a problem with one or two of my scripts. Even though they use a very fast loop, they are detecting the position of an object (a bullet to be exact) which is travelling vey fast. The problem is this: even a very small delay (~0.001) can cause a large error in the position of the bullet (as recorded by the script) just before it dies. The bullet travels at 1000 m/s, so 1000*0.001 = 1 metre difference between real and actual position. That's in theory; in practise it's more like 2-3 metres most of the time.

One solution is to slow the bullet down, but there are 2 reasons why this is only a partial solution:

1.) The whole process of creating/moving/destroying the bullet needs to take as short a time as possible - it is part of a script. Of course this depends on distance, but maybe 0.5 of a second is the absolute maximum. This means the script can be used realistically for about 300-500 metres atm, but only 150-250 metres if i halve the speed, an so on.

2.) Ofp, bless its realism, takes gravity into account when moving the bullet along its trajectory. A slower speed means a more noticable 'dip' in trajectory per metre moved to the target.

Any ideas, simple solutions, please tell me. Thanks in advance!  

EDIT: omg typos

[h-]

Try using the lowest possible delay (afaik) 0.000001, or better yet: @(true)

some sort of example:

Code: [Select]

#loop
_pos = position _this

@(true)
? !(isNull _this): goto "loop"
exit

[Fragorl]

Thanks for the reply. Unfortunately, there seems to be negligible difference between ~0.0001 and ~0.000001, or for that matter, no delay at all. I still get about a 1 metre displacement between the recorded and 'real' hitlocations. The check refuses to work at all with '@true' for some reason, no idea why.

I've tried weaning the speed back to 250 and even 100 m/s, but there is only minimal improvement - that is, the best results seem to get better, but the worst results stay about the same.

And all the time, those little dirt puffs that the bullet produces when it hits sit there, right in the correct place, mocking me.

[Cap]

umm just a thought are you determining the possition of the bullet by having a script ask for the possition of the bullet or acctually calculating it. By getting the script to actually ask for the possition of the bullet with a certain time delay of course you are going to get an ammount of error.

ok we have that the bullet travels at 1000 m/s^-1, if you know what acceleration gravity is set at, the starting possition of the bullet, the direction of the bullet and how much time has passed before you want to know the actual possition of the bullet we can formulate an equation to work out the possition of the bullet in relation to the starting possition and therefore workout where the bullet is exactly.

How about that.  

just to let you know that the equation might be very complex, but i can give it a go to find it if you like and if you can supply the info i need. Also bare in mind that the bullet will not always (infact very seldom) travel at a speed of 1000 m/s^-1 parrelel to any of the 3 axes, it depends on the initial trajectory and angle of the bullet.

Is this a possibility to acomplish what you seek, and then we can laugh back at that little puff of dirt and be ready and waiting to strike our fist to destroy it before it even knows where it is going to be its self.  

[Fragorl]

Haha! Yes, of course! Good thinking Cap! Now why didn't I think of that?

My excuse: ofp's little 'quirks' that seem to make everything inaccurate, made me think that the only way of doing it was to beg ofp for the precious data via getpos. But your way of course is better!

I'm creating the bullet so of course, I have all the data at my fingertips. Plug it all into s=ut + 0.5 at^2 and the other relevant equations, sit back relax and get the time of flight and voila! We can calculate the hit position. This *should* work.

My next question: anyone know what OFP uses for 'g' - accel due to gravity? 9.8?1? or 10?

Thanks Cap.  

[Cap]

haha good good  

hmmm i dont know what they use as g but can we figure it out in a little ofp land physics expt.?

s = 0.5 at^2
-> a = 2s/t^2

perhaps you have already recorded some values that we can equate from (maybe with the average or summit?) remembering that s is the displacement on the z axis (change in height) take enough readings and average it and we should do prety well, but thinking about it our z value wont be too far out anyway cos the bullet moves minimal in the z direction so it should be quite accurate eh? (disregarding the x and y values) can you do this?

[Fragorl]

Ok, might as well do this properly  ;D

Aim:See above.

MethodI tried dropping a camcreated bullet (because thats what id be working with) a distance of 50 metres and using a looping timer to get the total time. This proved to be unreliable, giving way mixed results. I then changed the method, to dropping a camcreated bullet from rest, allowing it to fall for 1 second, the taking it's new speed (velocity _bullet select 2). This got good steady results.

Precautions:Safety Goggles.
Setvelocity'd the bullet to [0,0,0] just before the trial began to make sure it was at rest. Did not run any other heavily resource-using scripts in the background

Results:____Trial #__|_____downward speed (ms^-1) after one second___
           1          |          12.6951                  
           2          |          12.6270    
           3          |          12.6759              
           4          |          12.6276          
           5          |          12.6951          
           6          |          12.6178    
           7          |          12.6659      
           8          |          12.6659        
           9          |          12.6367      
           0          |          12.6367      
Average: 12.65

Error:D*mn, moving the mouse before the script executes causes major random errors. If I hold it still, I tend to get the same two results: either 12.6659 or 12.6367. There's no way to know what another person would be doing though...  As for systematic, I dunno. I've got nothing to compare it against (except the 'true' value of 9.81), but his is flashpoint after all.

DiscussionK, i was hoping to get results that were more concurrent, but ah well. They were close enough. 12.65 it is then...

[Cap]

haha superb effort lol i give you a 'B' i had to downgrade from an A due to the lack of graphed data sorry

ok one thing i want to know are you tring to find the pos of the bullet in relation to its coords on the map (them really long ones that you see in the mission.sqm) or just in relation to its initial pos?

also you seem to have worked out the velocity not the value of gravity, how did you come up with the downward speed of each trial? cos acceleration is in m/s^2 (sorry i would do the experiment myself but im not to good with the camcreate command if needs be if u tell me how to do it i will so we can compare results lol, propper physicists then lolz) and it this a landmark day was that the first officialy recorded ofp physics expt.? I feel a speech coming on...

Oh on this day, this historical day, we witnessed the birth of the study of the ofp digesis. A day so (was it sunny when you did the expt.?) sunny the light glistened from the mighty gravity affected non-real metal but strangely oh so simply not bullet of wonder...... lol ok ill stop now

[Fragorl]

;D heh heh...

Yes, i'm trying to find the bullet's final position in relation to its starting one, but it doesn't make any difference whether it's relative to a starting position or just coordinates, as i can work out either from both...

About readings: yes, this is 'g' afaik, because it is the gain in (downwards) velocity per second (ms-2) - in one second, the bullet went from a standing start to 12.65 ms-1. I got this simply by velocity select 2.

This topic is by no means solved yet, as I am still getting inaccuracies (not to do with the method, no, that was a good idea) but due to ofp itself. Specifically using a loop like
#loop
~0.001
timer=timer+0.001
goto "loop"
is actually wildy inaccurate; the timer seldom actually reflects the amount of time that has passed.

[macguba]

Ah yes, I'd forgotten about that.   Its nothing to do with loops per se:   ofp is pretty inaccurate about time generally.

Interesting to know that gravity is 12.65 rather than 9.81 though.

[Platoon Patton]

RESISTANCE

Isnt there an OFP factor (friction) involved?

Have U tried your test with other objects?

g is calculated in empty space,you already have a bigger value  

The groundtextures in OFP must have a magical attraction  ;D

[Fragorl]

Isnt there an OFP factor (friction) involved?

The 'OFP factor' is always involved. It drives me mad sometimes  ;D
Seriously though, yes this is a good point. I ignored air resistance because, frankly, I've no idea how to take this into account. I mean, I know the theory quite well, but how well this relates to 'real life' in flashpoint I've no idea (if it does at all).

g is calculated in empty space,you already have a bigger value

I know! What the...? Oh well.

No, i haven't calculated with other objects, because a bullet is what I'm using. Hah, imagine trying to take the surface area of a car into account for air resistance! 's beyond me.

As for the inaccurate timer, I think it is the nail in the coffin for this idea. I mean, if the timer varies depending on fps, whether the user is moving around or standing still, system specs etc (and it does seem to), then I can't use it .

I'm still hoping there's a simple reliable solution out there, like the equivalent of grouping a gl to the bullet, or something.

[Sui]

...Unfortunately, there seems to be negligible difference between ~0.0001 and ~0.000001, or for that matter, no delay at all...

I have a feeling that the shortest possible delay that OFP will recognise is 0.001 (though I could be wrong).

Macca's right though... OFP can be fairly impresice when it comes to timing...

[macguba]

Sui's right, there is a minimum delay and I discovered what it was .... though I can't remember ..... 0.001 sounds about right, or maybe 0.0001.     0.000001 is definitely beyond the range though.

[h-]

0.000001 is definitely beyond the range though.

yeah, most likely...
I just threw it in because all other OFP values have six digits both sides of the decimal

@Fragorl:
What the hell are you actually trying to achieve with this stuff??

[Triggerhappy]

this a lot to read so i didn't bother just to make one correction, that is very important:

Results:
____Trial #__|_____downward speed (ms^-1)___
          1          |          12.6951                
          2          |          12.6270  
          3          |          12.6759            
          4          |          12.6276        
          5          |          12.6951        
          6          |          12.6178  
          7          |          12.6659    
          8          |          12.6659      
          9          |          12.6367    
          0          |          12.6367    
Average: 12.65

gravity is an accelleration. that ^ is velocity (speed). you got those numbers by assuming it went at a constant speed

the acceleration of gravity is about 9.604 m/s^2 (or something similar, i may be implementing some dislexia) in ofp

[Fragorl]

lol, i should have been more clear about what i was doing with all that stuff.

Triggerhappy: as you know acceleration is the change in velocity per 'unit' time (ie 1 second.) So what the results say is, having let the object drop for 1 second, it attained a downwards velocity of 12.65 ms-1. So the change in velocity was 12.65 ms-1/1s. Vector is 12.65 down, units are ms-1/s = ms-2.

This wasn't accurate tho, as i didn't take air resistace into account, as i mentioned before.

HateR_Kint:
I pretty much said most of it in the first post, but i'll explain it in more detail here.

Working on a script. The script camcreates a bullet. The bullet moves a long a path, from a starting point towards an end point. This is designed to check for solid obsticles between the start and end, like a 'raytrace'. The problem lies in that the bullet travels so fast, it can go along way in the space of ~0.0001. Instead of doing a check this way and getting big inaccuracies, i was looking for another way. Cap suggested that, knowing the bullet's velocity and everything, we should be able to calc the point of impact simply by knowing how long it was in the air for. The problem with this is that actually timing the time using script is really unreliable.
The script itself is in a thread in the ideas board, started by Clees, called Urban Areas... Obsticles

So atm im looking for a better way to get the bullet's pos, right before it hits something.

[Triggerhappy]

either way, the accelleration of gravity in ofp is approx. 9.6, so there has to be some flaw in your design. How do you know it was for exactly 1 sec? It would be fairly hard to implement that flawlessly through ofp script. much better to use a set distance and measure time, then calculate. I did that in trying to find the acc. of gravity, and got about 9.4 ish (average of about 200 trials ;D) then homefry (who i had been helping at the time) came by and told me that someone at the official forums (trustworthy ofcourse) told him it was approx. 9.6 (although, once again, i may be getting numbers mixed and its really 9.4;D)
anyway, thats gravity, so good luck with your script

[Roni]

Hello

Just passing and thought that I'd throw in a quick two cents

00 <ka-ching !>  

Check ou the tute on the Laser Designator (it's in the Editors Depot somewhere).  Apparently this "weapon" creates a virtual spot on the map wherever the laser "dot" is calculated to be.  This dot is dynamically updated and can be used for all sorts of neat "raytracing" projects such as this.

AFAIK it doesn't check for building interects but I could be wrong - I haven't read the thing very closely  

Good luck with it.



Roni

[Fragorl]

Triggerhappy:

there has to be some flaw in your design

almost definitely ;D

How do you know it was for exactly 1 sec?

I used this:
Create bullet, setpos, setvelocity [0,0,0]
~1
Get Velocity.
I've no way of knowing how accurate this was.

much better to use a set distance and measure time, then calculate.

How did you measure time, or distance? With script?

(average of about 200 trials )

Wow! Thats commitment.

Roni:
I considered that, but seems a bit difficult. Thanks for the 2c though

[Fragorl]

I think I may have almost solved this... just need a little more help.
I tried using a smokeshell instead of a bullet. The smokeshell, of course, does *not* disappear when it hits something (like a bullet does), it simply falls to the ground. So i could easily check for when it stops using the line:
"_x==0" count (velocity _this)
This works quite well. The problem is, when it hits something, it *instantly* teleports to the ground below where it hits. So i get a _pos which is correct for x and y, but not z.

I read somewhere that ecp 1075 has 'bouncy' grenades- ie they hit somethig and bounce off again, they dont just instantly stick to the ground. So i was wondering, which simulation is this, and is there any object in stock ofp that would exhibit this behaviour? Preferably ammo, but anything might work.

Thanks!  :thumbsup:

[Fragorl]

OK- got it! ;D. Got the x/y length from start to the grenade's resting place, found this as a proportion of the total x/y length from start to finish, found this fraction of the total z change, added to initial z.

Thanks everyone for your input! If there's still a better way, tell me, but for the time being this method works really well

*Solved*