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??