How much time does it take for a bullet in Arma 3 to reach it's initSpeed?

[zacharypw 12]

I want to know how long it takes a bullet to get to its initSpeed because I am trying to figure out how Arma 3 gets its airFriction values from the formula 
airFriction = deceleration / velocity2 listed here.

I need to know deceleration to know airFriction.

Thanks!

[Harzach 2505]

Reading through that page, it would seem that initSpeed is what we refer to as muzzle velocity IRL. So, it would stand to reason that initSpeed is reached upon firing - it is the initial speed of the projectile leaving the muzzle. In fact, this is explicitly stated in the initTime entry regarding missiles:

Quote

Missiles are launched at initSpeed. After initTime, the missile starts accelerating based on its thrust parameters. (see "thrust", "thrustTime").

 

This is also consistent with the idea that (for ballistic projectiles) initSpeed and airFriction determine trajectory. 

[Harzach 2505]

I believe @sarogahtyp has done some digging around in this area in the past, maybe he has some insight he can share.

[zacharypw 12]

1 hour ago, Harzach said:

Reading through that page, it would seem that initSpeed is what we refer to as muzzle velocity IRL. So, it would stand to reason that initSpeed is reached upon firing - it is the initial speed of the projectile leaving the muzzle. In fact, this is explicitly stated in the initTime entry regarding missiles:

 

This is also consistent with the idea that (for ballistic projectiles) initSpeed and airFriction determine trajectory. 

I want to figure out how much TIME it takes to get to get to the INITIAL SPEED. What I have been doing is using Time = 0.01 because that is the smallest speed you can run arma 3 in using setaccTime. But my math for airFriction comes out differently than what vanilla values are in cfgAmmo for 5.56x45mm,7.62x51mm, and 12.7x99mm when I use 0.01 for Time in the deceleration equation.

[Harzach 2505]

Quote

Initial: existing or occurring at the beginning.

 

It starts at that speed, so the time is 0. Before that time, it's still in the barrel.

 

 

[zacharypw 12]

That does not help me. Obviously Bohemia used a constant for how long it takes for a bullet to go from say 850m/s to 0 in order to calculate the airFriction. I am trying to find the constant. This constant has to be Time. 

If I use a deceleration formula 

FinalVelocity–InitialVelocity/Timetaken = Deceleration

I need Final velocity which is 0 m/s
I need Initial Velocity which is 850 m/s
I need Time taken which is what I am trying to figure out. I cannot use 0 for time because 850 - 0 = -850. Then -850/0 = infinite. See the issue? Assuming I use a formula where distance is utilized I still need the distance that Bohemia used assuming they used Time as 0 like you are suggesting.

[da12thMonkey 1943]

Arma's ballistics is extremely generalised. Deceleration is determined per ammo type by looking at velocity and time of flight data from comparable real-world ammunition.

Just look at some data and pick a time span (i.e. particular range/distance and the round's time of flight and velocity for that range), and work out the change in velocity over that span of time - that's the generalised deceleration.

Then BI just plug that value in to the formula and come up with the airfriction value

[Harzach 2505]

1 hour ago, zacharypw said:

See the issue? 

 

Yes, you erroneously asked for the time to initSpeed instead of the time from initSpeed to 0. Which is obviously a dynamic value, as da12thMonkey has explained.

[ZaellixA 383]

I believe the situation here is simpler that it looks.

 

The best idea would be to use the given formula to estimate the air friction (which I am not sure it equals the drag, but this is for a different topic). My best bet would be to use a linear approximation which means that you should do exactly as you described above. Replicating here:

 

Quote

(finalVelocity - initialVelocity)/(timeOfFligth) = deceleration

 

According to the web page you cited, it seems that BI does indeed use a linear approximation for the deceleration, which in turn ends up being a linear approximation to the air friction, making it a constant stated by the slope of the deceleration-vs-squared velocity plot. Now, assuming a linear trend, you could peak any portion of the trajectory to estimate the air friction, since it is given by the slope, which is a constant.

 

Thus, although your assumption that you should use the final velocity to be 0 is not incorrect, it does not render itself to performing actual calculations (you would have to use calculus to get past it and I don't think it is implemented in ArmA 3 scripting). On the contrary, as mentioned above, you could use another portion of the bullet flight-time to estimate the air friction with the formula you provided yourself. An example would be to measure the velocity at, say 0.5 seconds after it was fired and use those values to do the estimation. This would be something like

 

// Assuming some given values here for the demo
private _initVel = 850; // Initial/muzzle velocity of 850 m/s
private _finalVel = 732.4; // Measured velocity after 0.5 seconds equal to 732.4 m/s
private _timeOfFlight = 0.5; // Time of flight of the bullet at the moment of the velocity measurement

private _deceleration = (_finalVel - _initVel)/_timeOfFlight; // Calculate deceleration
private _ airFriction = _deceleration/(_finalVel * finalVel); // Use BI's given formula

 

Alternative approach

If would like to verify the assumption that the air friction is a constant given by the slope of the graph of deceleration versus the squared velocity you could get the velocity at different time instances (a regularly spaced grid would be the easiest way) and create a graph of the deceleration versus the square of the velocity. From that you could estimate the slope, or even better, calculate the slope, or even directly the air friction for each grid point (well actually the midpoint between grid points). This could possibly look something like the following

 

// Get the object
private _obj = ; // Get the bullet here somehow

// Assuming some constants for the demo
private _initVel = 850;
private _dt = 0.01; // The time-grid spacing (for regular grid)

private _airFriction = []; // Create an array to hold the calculated air friction

// Calculate 100 times
for "_idx" from 0 to 99 do {
  sleep dt; // Wait for duration dt
  
  private _speed = speed _obj; // Get the speed of the object at this instant in time
  private _dV = _initVel - _speed; // The difference in speed between the two time steps -> the deceleration
  
  _airFriction pushBack (_dV/speed); // Calculate the air friction at this iteration and put it in our results array
  
  _initVel = _speed; // Update the speed to use in the next iteration
};

At the end of this snippet you will get (the linear approximation of) the air friction at times corresponding to the midpoints between the time grid points.

 

One note to make here is that I am not sure whether you should use the command speed, which, according to BIKI, gives the y component of the velocity of the object, or calculate the magnitude of the velocity and use that instead. The magnitude could be calculated as

 

private _vel = velocity _obj; // I assume you already have something in _obj

// Manual calculation (not optimal)
private _velMag = sqrt((_vel select 0)^2 + (_vel select 1)^2 + (_vel select 2)^2); // Manually calculate the magnitude

// With built-in command
private _velMagBest = vectorMagnitude (velocity _obj); // It is always advised to use built-in commands

 

Edited January 29, 2023 by ZaellixA
Corrected a couple of typos

[zacharypw 12]

Alright, I'll just explain everything if you want to read the whole thing you can. if you don't then just ignore this paragraph.

I am a modder that worked with the creator of Universal Ammo System, and after he dropped off the internet, I took it over.  Right now me and another modder are working on a replacement for Universal Ammo System that uses ACE3 Advanced Ballistics. There is a LOT of code from UAS ammo properties that frankly are very difficult to get IRL references to. For many there isn't any data to get sometimes because the ammunition was only used in testing and there were only a few hundred cartridges made for testing only. I thought that If I could mathematically convert the cartridges' airFriction values, I could reverse engineer ballistic coefficient's without using off the cuff estimation and it would be easier on me. I guess that is not really possible WITHOUT making a bullet class for said bullet and making a script or something along those lines.

 

I don't fully understand ZaellixA's explanation of an example post. I didn't want to predict the trajectory of the bullet if that makes sense.

 

17 hours ago, Harzach said:

 

Yes, you erroneously asked for the time to initSpeed instead of the time from initSpeed to 0. Which is obviously a dynamic value, as da12thMonkey has explained.

It's not an error. I think I explained it incorrectly. I wanted the TIME it takes in the engine for the bullet to get from when you press the primary mouse button to the gun firing the bullet in game at muzzle velocity. I believed this is what BI used to create the airFriction value along with the formula mentioned on the wiki. I was then going to just swap the formula around so it could be used for deceleration instead of acceleration. Alas, I appear to be wrong in my assumption that BI used a constant for TIME. 

[sarogahtyp 1104]

@zacharypw

 

currently I did not understand what exactly you need and what exactly you are trying.

But! I know I wrote a script that predicts the position of a moving target at the time the currently used bullet or missile will hit the target if the trigger is pulled now.

Or in short: The script calculates the position for a lead assist system.

 

In those script I had to simulate the complete flight path of bullets and rockets to get the desired target position. Therefore the script should contain the information you are looking for (whatever this is).

 

Predict Target Position

 

If you have questions, just ask.

[ZaellixA 383]

8 hours ago, zacharypw said:

I didn't want to predict the trajectory of the bullet if that makes sense

What I suggested does not allow for trajectory prediction, it is just a way to calculate the air friction and the "alternative solution" allows to graph the air friction against time (or even distance/displacement since those two are related through speed).

 

I'll try to explain a bit better in case this could indeed provide some help.

 

Unless I'm utterly mistaken, all we can do is consider that the bullet will be "ejected" at the time you click your mouse button (or whatever way you use to shoot a gun). This means that for time t = 0, the velocity of the projectile (bullet) will match the initial, or muzzle, velocity provided by its config file (I believe this is where this value is set but I am sure you know that better than I do). The simplest case of all, and then one that is implied to be used by BI in the web page you cited, is to assume that the air friction is constant for each projectile. In this case you could use the formula you provided to calculate the air friction. I replicate it for completeness.

airFriction = deceleration/(velocity^2)

Now, you do have the velocity but you don't have a value for the deceleration. One, simple, way to acquire it is to get the velocity of the projectile in another time instance, with t = t2. If the air friction is indeed a constant, then t2 can be any instant after the initial ejection of the projectile but before it hits any object (you want air friction to be the only external force applied for the formula to be valid). An example could be to get the velocity of the projectile 1 millisecond after it is ejected. This could be done in script like

 

// Add an event handler to trigger when the user fires a weapon
player addEventHandler["FiredMan", {
	private _projectile = _this select 6; // Get the projectile

	[_projectile] spawn {
		private _bullet = _this select 0; // Get the bullet into this script
		private _initVel = vectorMagnitude (velocity _bullet); // Get its initial velocity at this moment
		
		sleep 0.001; // Sleep for 1 millisecond
		
		private _finalVel = vectorMagnitude (velocity _bullet); // Get the bullet's "new" velocity

		// Assuming deceleration is negative acceleration, it is calculated as the difference in speed in
		// two time instances over the time interval during which the change happened 
		private _deceleration = (_finalVel - _initVel)/0.001; // Calculate the deceleration as the difference of the two velocities over the time interval 
		
		// Print the results
		systemChat ("Deceleration of the bullet is: " + str(_deceleration)); // Print the deceleration
		systemChat ("Air friction of the bullet is: " + str(_deceleration/(_finalVel^2))); // Print the air friction calculated with the given formula
	};
}];

Now, there's a couple of details to be taken into account here. First and foremost is the use of sleep. Personally, I am not sure whether this delay/sleep is accurate or even steady (to my limited knowledge, in programming, a steady clock is one that for later instances, it is guaranteed that will provide a greater value compared to the initial one). It is up to the scheduler to take care of the delays and sleeps which may render the whole process inaccurate. I believe that by running the "simulation" many times and averaging could provide a better estimate (not necessarily unbiased though, especially if the actual sleep duration is always equal or greater to the specified - this could add a negative bias to the time interval if I am not mistaken). I am sure there's people in the forums that could potentially provide more insight into this. Nevertheless, I believe this is a well educated mathematical formulation to get an estimate of the deceleration and in extend the air friction.

 

Second point to make is that I am not sure (it is not very clear to me) whether deceleration is indeed negative acceleration, in which case its calculation (or its estimate at least) should be correct in the script, or just the difference between the value of speed between two time intervals, in which case the calculation is not correct and the actual value will depend on the time interval (which makes it a weird way to calculate the value at minimum).

 

Third, as mentioned in my previous post, is that I am not sure how BI calculates the velocity. Most probably, it should be the magnitude of the (3D) velocity of the body, in which case, again, the calculation above should be correct. Alternatively, BI could use only the y component of the velocity to calculate air friction, thus ignoring effects such as gravity. Nevertheless, this would also seem weird to me, as it would then depend on the direction the muzzle is pointed. In reality, one would have to calculate the change in velocity at the direction of the initial muzzle direction in order to acquire a more accurate speed (in one direction) estimate. This requires dot products with the directional (unit for convenience) vector pointing towards the direction the muzzle is pointing. Not sure how big a difference this could make, especially for very short time intervals though.

 

I do hope this helps somehow, although I really doubt that this way of estimating the air friction renders itself for "offline" calculations (which I believe is what you really want to achieve). Additionally, as sarogahtyp mentioned, they already have a (quite complex I assume ) script which could potentially provide more help (and hopefully they put much more thought into it and found better ways to get the results you seek).

 

As a final remark, please note that the presented script is not tested and should be treated with caution. 

[sarogahtyp 1104]

7 minutes ago, ZaellixA said:

I am not sure (it is not very clear to me) whether deceleration is indeed negative acceleration

 

The terms acceleration and deceleration are one-to-one interchangeable.
The only difference is that some people call positive values acceleration and negative values deceleration.
Others use the term acceleration for both ranges of values.

[ZaellixA 383]

2 hours ago, sarogahtyp said:

 

The terms acceleration and deceleration are one-to-one interchangeable.
The only difference is that some people call positive values acceleration and negative values deceleration.
Others use the term acceleration for both ranges of values.

Thanks for the post. I do know that but due to the fact that some people use it one way and the other, it is not very clear which is the case here or even if in this case the meaning is somewhat different. To be honest I strongly believe that in this context acceleration and deceleration are indeed the same thing (dependent only on the sign) I do my best to avoid passing down information based on mere speculations. This is the sole reason I wanted to clarify that to me it is not very clear in the current context.

 

Thanks for the clarification though :).

[da12thMonkey 1943]

On 1/30/2023 at 3:05 AM, zacharypw said:

I wanted the TIME it takes in the engine for the bullet to get from when you press the primary mouse button to the gun firing the bullet in game at muzzle velocity.

initSpeed, is as the name suggests, the speed the bullet has when it is initialised. It does not accelerate to its muzzle velocity, it is created with a velocity defined by initSpeed

internal ballistics are not something that BI bothered with simulating in Arma's projectiles. Any delay between mouse press and the bullet's initialisation at initSpeed will be the result of user/hardware specific factors like input lag, frame rate etc.

 

Bear in mind that the base magazine initSpeed can be overridden or modified by the initSpeed parameter in the weapon