Feature #22045

Please add Range Table fo BM21 Grad

Added by badger almost 4 years ago. Updated over 3 years ago.

Status:Duplicate Start date:07/08/2011
Priority:Normal Due date:
Assignee:- % Done:

70%

Category:-
Target version:-
Component: Affected Version:
Close Reason:

Description

In ACE there are range tables fo D30 an 2B14 Podnos. But there is not range table for BM21 Grad. Please add it.
If you need help with creating this, our-army.su community can do it.

Also please add strings from range-tables to stringtables, so we can translate it in other languges.

bm21table.txt (10.7 kB) MaHuJa, 08/21/2011 19:36


Related issues

duplicates A.C.E. for OA - Feature #20305: Range tables for Grad and MLRS Feedback 06/08/2011 03/26/2012

History

Updated by Xeno almost 4 years ago

  • Target version set to Planned (Needs Contributors)

Updated by badger almost 4 years ago

What can I help for this?

Updated by rocko over 3 years ago

Needs to be provided if possible.

Updated by MaHuJa over 3 years ago

  • File bm21table.txt added

I have only calculated them; I have not proven them correct.

So, somebody needs to test against a light variety of targets, and check that these values do indeed get the rockets on target. In particular I suspect the boost phase offset may make the altitude compensation inaccurate. (If this particular strain of inaccuracy exceeds a mil in the worst case, I don't know.) Also, it's going to be desirable to round off a few digits.

This information is derived from 15 MB worth of grad missile path tracks.

Edit: Oops, there's a missing column. Will fix.

Updated by MaHuJa over 3 years ago

  • File deleted (bm21table.txt)

Updated by MaHuJa over 3 years ago

Now with no missing columns

Updated by rocko over 3 years ago

thumbs up

Updated by rocko over 3 years ago

  • Status changed from New to Assigned
  • Assignee set to Nou
  • Target version changed from Planned (Needs Contributors) to 1.12

Nou is the artyman, he will implement it.

Updated by Nou over 3 years ago

Does the M270 have range tables? How are they done? Rocket artillery I think is not handled "right" in ACE at all. Remember that rockets after boost phase do NOT follow a ballistic trajectory. Gravity has NO EFFECT on shotRocket simulated ammo after the engine burn out (or during the engine burn).

How it was done in the original BIS artillery module by Headspace is that the rocket fires, and when it reaches a certain altitude its replaced with a "proxy" that is using shotShell as the simulation type and its given the last velocity vector and vector direction so it follows a ballistic path. I do not think any of that is implemented right now in ACE for the MLRS or the Grad by default.

Updated by MaHuJa over 3 years ago

Nou wrote:

Remember that rockets after boost phase do NOT follow a ballistic trajectory. Gravity has NO EFFECT on shotRocket simulated ammo after the engine burn out (or during the engine burn).

On the other hand, aim the grad/mlrs to point directly at a mountaintop in the distance, fire, and observe that the impacts are way down the side.
The fact that it tracked the shots all the way back down to 0 alt 10000+- dist, means something in your statement doesn't hold; object replacement would stop the tracking.
Rockets fired high do hit the ground eventually. And predictably.

The method used:

I have a mission, which uses a fired EH on the artillery piece. For each shot, a script is spawned which will spew information (sql insert) on the objects position to the log file several times per second. For the grad the rate was between 35 and 40 times per second. I shot at 10 mil intervals, and after the sqlite import, I have a 15MB file. I then have a program that will do a lookup on that table, filtering by altitude difference for the target (for that table, 0 +- a few meters) and selecting the closest points ( order by abs(distance-targetdistance) asc ) and doing a lerp off of them. Not perfect (I should be doing lerp on lerps, for example, but it works reasonably well because I have enough granularity in the data) but the results have been a good match to the official range table for the ace m119.

In this case, I've done such a lookup on 0 altitude n*100 distance, and dumped it to the table attached. I've used -100 altitude and subtracted the 0 alt values to create the per 100 alt diff numbers. (Though as I said, I don't know how much the boost phase will affect that number.)

FWIW I was running ace when I did the test firing.


Actually, to whoever wants to verify the numbers - plotting the numbers (I suggest delta plotting) should result in very smooth graphs if it worked as intended.

Updated by Nou over 3 years ago

MaHuJa wrote:

Actually, to whoever wants to verify the numbers - plotting the numbers (I suggest delta plotting) should result in very smooth graphs if it worked as intended.

Check out this CIT ticket: http://dev-heaven.net/issues/18809

Unless we are doing a proxy replace with the grad right now I assume its the same thing?

Updated by MaHuJa over 3 years ago

Something that you know to be true isn't. At least, not anymore.

I'm loading ACE, I'm using a "bulletcam" that follows the shot through its flight (and stops when an object is replaced as with paladin delayed fuze) and, with mlrs and grad both, I'm just not seeing the behavior you're talking about.

I know what behavior you're describing: at the paladin 1.1 release - before the uo versions - I saw that happen with the then unreleased copperhead. It stopped in midair and then slid backwards. However, the mlrs/grad missiles are pitching down as appropriate, and hitting the ground.

FWIW a "far" low-angle mlrs shot (blind, fwiw) was slowly accelerating while on its way up - until the acceleration picked up even more because it was on its way back down.

Updated by MaHuJa over 3 years ago

Nou wrote:

MaHuJa wrote:

Actually, to whoever wants to verify the numbers - plotting the numbers (I suggest delta plotting) should result in very smooth graphs if it worked as intended.

Check out this CIT ticket: http://dev-heaven.net/issues/18809

To clarify,
I was referring to the numbers in the file I attached on this issue. If the graph is smooth, and a test shot or two hits where aimed, then it should be good to go. If the graph is jagged, I have some work to do.

Updated by rocko over 3 years ago

  • Target version changed from 1.12 to 1.13

Updated by rocko over 3 years ago

  • Category set to Integration
  • % Done changed from 0 to 70

Updated by rocko over 3 years ago

  • Target version changed from 1.13 to Planned (Needs Contributors)

Nou seems absent

Updated by rocko over 3 years ago

  • Category deleted (Integration)
  • Status changed from Assigned to Duplicate
  • Assignee deleted (Nou)
  • Target version deleted (Planned (Needs Contributors))

Also available in: Atom PDF