Project Reality Forums

Hi there!

Since the most recent campaign is over and NATO CHARLIE COMPANY had their fair share of fun with the tool I developed during its runtime I thought its time I release this to the public and allow everybody to gain from it.
Before I get into a few details about its handling let me briefly outline the essentials.
"Single Battery Computer System" (SBCS) formerly known as "FireSolutionCalculator" (FSC) is an application written in JAVA and completely independent of BF2 R.
Its sole purpose is to allow mortar operating crews to swiftly and precisely calculate fire solutions to account best for an existing target distribution and density.
This is done by a variety of different Type of Mission modes. Each mode calculates a specific geometric shape or takes the grid system for its calculations into account.
The modes are Point-To-Point (PTP), Keypad (KP), Multiple-Main-Grids Mode (MMG) and Fire-For-Effect (FFE). PTP lets you define a START and END point as well as either a spread or amount and calculates all necessary shells in between effectively drawing a (dotted) line from START to END.
KP mode comes with 4 different Target Modes. The modes are Outer-To-Inner (OTI), Inner-To-Outer (ITO), Single-Grid and Sequence of Grids.
If you divide a KeyPad into 9 smaller SubGrids very much like a keypad is build the fire sequence for OTI would be: 1,4,7,8,9,6,3,2,5.
ITO is the same in reverse. SG allows you to shoot on single SubGrids. SoG enables the user to define a fire sequence on his own.
MMG provides the user with a mode where he can choose from up to 30 completely different Target Locations. That modes was often used for Target Predesignation where you had to work with different Main Grids.
Lastly FFE which also comes with a couple target adjustments.
The way I laid it out geometrically FFE is a circle with a specific radius where all shells are calculated to hit with their center along the line/circumference line of the circle while maintaining an even distribution from each impact center to the next one.
In its very basic mode the mortar operating crew chooses a target location and the type of ammunition. Depending on the type of ordnance the radius from the circle assumes a value of either 50m or 70m with one shell in the middle (Center Shell).
You may also choose to use the Large Sheaf with comes with one more circle around that inner circle making it 19 shells in total over an area of either (100m? * pi) or (140m? * pi).
Lastly you may also choose to alter the radius and the amount of shells between a number of predefined values to accommodate the need for an individual effect on target.
That sums up the essentials of all modes. There is still more to explain but I guess I may as well allow you to explore for yourself.
In addition the current state of work allows for the automatic compensation of relative heights by loading a supplied heightmaps.ser file.
To ensure maximum precision it is necessary to adjust your home location within your current keypad. That is done either by the "Home Adjustment" (features two different modes) or the KeypadImage Adjustment. I recommend using the latter. After setting your homelocation you can load keypad images via the options tab.
Adjusting your home location is if you are not centered within your current keypad.
That is all I can recall as being important. Should I have forgotten to mention something feel free to reply to this thread.
Lastly to put myself on the safe side here is a disclaimer:

I make no warranties as to performance, merchantability, fitness for a particular purpose, or any other warranties whether expressed or implied.

No oral or written communication from or information provided by the author shall create a warranty.

Under no circumstances shall the author be liable for direct, indirect, special, incidental, or consequential damages resulting from the use, misuse, or inability to use this software, even if the author has been advised of the possibility of such damages.

These exclusions and limitations may not apply in all jurisdictions. You may have additional rights and some of these limitations may not apply to you.

Now before I provide you the link I attached a pdf file to the archive which features a manual that I haven written as an assignment of my CO Sproge and what we used for the purpose of training our Forward Operators. Maybe you can make some use of it.

SINGLE BATTERY COMPUTER SYSTEM(SBCS) by ZuluActual

My next goal is the implementation of a network feature to allow FOs and the FDC to communicate on basis of a client -> server -> client model.
This would simulate devices the actual military uses to send artillery coordinates without engaging in a vocal radio communication.
Anyone interested in the further development can follow its progress here

My next goal is the implementation of a network feature to allow FOs and the FDC to communicate on basis of a client -> server -> client model.
This would simulate devices the actual military uses to send artillery coordinates without engaging in a vocal radio communication.

this is interesting, hope you make a kind of overlay

Mustve taken ages to make. Seems like a nice program but from what I had a look takes ages to actually fire a round. I assume you can always hit the target with the first shot, which is nice. But other than that I dont see a real advantage in using this.

Personally, I use a list of ranges from 100 to 1500 with 10m increments. Its accurate enough for me.

Good job making it tho, shows that youve got a lot of dedication.

Nice software. 43 pages of manual. That's quite an achievement.

Overcomplicated a bit for my taste. I prefer to stick to my ways though.

Well I admit this piece of software is more of an expert tool and needs proper briefing before Its potential can be fully exploited.
For example it does take some time to initially setup and adjust your home location. Once done its simply inputting the target grid, pressing the calculate button and shooting the values.
Of course you need to have either a second screen, laptop or perhaps a tablet pc to be actually able to make use of this.
Also a solid knowledge of the Type of Mission calculations is useful and what they do and their differences.
But at the end of the day I really only used and still am using this project as a way to get familiar with JAVA so a certain degree of complexity is something I haven't explicitly tried to avoid.

I still call hax

But since the Devs seem to approve, have fun using it.

Thank You for all your hard work.

can someone give me a TL;DR of this please

killonsight95 wrote:can someone give me a TL;DR of this please

You can read manual.

killonsight95 wrote:can someone give me a TL;DR of this please

SBCS replaces and enhances the in-game mortar calculator by a number of features.

That is TL;DR. For any questions not explained in my first post or the manual feel free to ask.

My question is how did you figure out the trajectory?

I remember Sniperdog posting his exact formula but I can't find it anywhere!


Way to release it a year early and make all my excell spreadsheeting useless

In case you are referring to the barrel elevation this is for non height-compensated elevation values a simple one-stepped interpolation which is basing on empiric values taken from the game.

Otherwise if you would want to achieve a minimal use of in-game values you would probably need to reverse-engineer the polynomial equation describing the relation between the barrel elevation and the range it refers to.
The reason for that is a regionally limited linear behavior of the range-elevation function.

I thought an actual formula that demonstrates the way I solved this might help the practically inclined to a better understanding: I hope that answers your question.

Does that mean you just took the ranges given ingame at 10m intervals and fitted an equation to it? That also elevation is linearly related to range?


One little feedback, something that I wanted to put in my own calculator, any way you could allow a text based insertion?

Instead of using the tabs just have an iput go like: "J4-2@3"


Or does height gradually make more of a difference at longer ranges?

I know the trajectory gets really flat near the maximum range.

No certainly not at 10m intervals. That would give you roughly over 130 single interpolation equations. Its sufficiently accurate to apply subsequent interpolations in 100m increments. If you were to use 10m increments you could easily quite literally copy the results from the in-game calculator. Also with height compensated values this would get a increasingly hard if not a near-impossible task to manage up to a degree were the actual act of programming would nullify itself due to the sheer repetitiveness of the code in such a case.
There is only a regionally limited linear relation between the ranges and their respective elevation values. The bigger an interval you choose for applying the interpolation the higher the interpolation error becomes. That means you could fit a single linear function over the whole bandwidth of range-elevation values but your result would be flawed by a specific non-linear value. (As a gut feeling I am saying that value is the difference between the actual polynomial function and the by interpolation gained linear function at that working point).Now if you break that up into a number of smaller intervals (say a 100 meters) and fit a linear function over those intervals your margin of error becomes smaller. Thats what interpolation basically does for you. Of course a single linear function that accurately describes that particular relation is something I would prefer over the current system but I think its something the game engine ultimately defines and defines in a way where it comes close to the real world physics for a special case.

I must point out that this project constitutes my first programming project I have ever done in my life so far. This obviously means my first project in JAVA as well. So expect to encounter a whole number of bugs and rather unbecoming GUI implementations. Were I considered it feasible I drew up concepts for the code and the structure/work flow but I have done this mostly only for the actual geometric and elevation/traversion related calculations. One such arguably unbecoming implementation is the ComboBoxes I am using to let the user specify the grid locations. When I decided to employ those components I just finished the transition from a purely text driven to a wholly GUI driven application being rather relieved by the possibility of restricting the user in what he may provide as an input. In retrospective and in consideration of my current JAVA knowledge I do believe using TextFields as the main choice for feeding data to SBCS is a well advised path for the future development. Thank you for your input. Its more than welcomed and as such well appreciated.

As to your question about the trajectory. Can you elaborate on your understanding of the term trajectory in this context.
When I am hearing this I am seeing a parabolic function that is used to describe the trajectory of objects and should I not be mistaken that function's determining parameters are the velocity and mass of the object as well as its launching angle. Now I can't really help you in that department because the only in-game values I am using for SBCS is the relation between all possible ranges and their associated elevation values.
The physics of the flight or trajectory is of lesser interest to me. It is not crucial or needed at all for the realization of the calculations. The parameters are always the same except for the barrel elevation which equals to the launching angle but for those you are using the interpolations. In case of the launching angle being the same at all times you obviously only would have one elevation value and a therefore constant function where every x value had the very same y value. But as you know that is not consistent with either real world nor the in-question in-game physics.
I hope that makes some sense.

Gotta love the RM/PR community! Nice work.

Ah I found it! Wasn't too hard.

The actual physics equation came out to:
Angle = 90 - sin^-1 (-14.70235*Range/(projectile velocity)^2)/2.
Where -14.7 is the acceleration due to gravity in BF2 (with the gravity modifier set to 1)

This allowed me to compute the maximum range just fine but for some reason it didn't work correctly with some of the other angles.

The equation I modeled after doing some measurements is:

Range = -8.869232072*10^(-22)*x^8 + 5.863078464*10^(-1 *x^7 - 1.645660969*10^(-14)*x^6 + 2.552955503*10^(-11)*x^5 - 2.385872722*10^(- *x^4 + 1.370373343*10^(-5)*x^3 - 4.712480004*10^(-3)*x^2 + 8.691949397*10^(-1)*x + 19.70789909

where x is the range. This equation worked to an accuracy of within about 2 meters.

This equation is only really useful to angles for this weapon though

As to your question about the trajectory. Can you elaborate on your understanding of the term trajectory in this context.

The above is what I mean exactly. The parabolic path the shell takes when inbetween points.

When I am hearing this I am seeing a parabolic function that is used to describe the trajectory of objects and should I not be mistaken that function's determining parameters are the velocity and mass of the object as well as its launching angle. Now I can't really help you in that department because the only in-game values I am using for SBCS is the relation between all possible ranges and their associated elevation values.

Yeah... I needed the range to angle formula... I got it.

Now I just assume that the trajectory is a simple wave... Figuring out the trajectory will help me vizualize the differences in height better.

-------

Chase Armitage wrote:No certainly not at 10m intervals.

http://www.od-sierra.org/L4gi/rangecard.pdf

ytman wrote: Range = -8.869232072*10^(-22)*x^8 + 5.863078464*10^(-1*x^7 - 1.645660969*10^(-14)*x^6 + 2.552955503*10^(-11)*x^5 - 2.385872722*10^(-*x^4 + 1.370373343*10^(-5)*x^3 - 4.712480004*10^(-3)*x^2 + 8.691949397*10^(-1)*x + 19.70789909
-------

That is a polynomial equation with a power of 8 - not sure if its written like that in English - which is probably describing the relation between the range and their associated elevation values. Now this is only applicable if no relative height difference is in play but it would be quite interesting to reverse-engineer the polynomial equation for range when indeed the relative height differs from zero.
I am assuming in order to gain the above equation some mathematical tool like maple13 was used. Perhaps it could be applied to determine the relation when it comes to relative heights.
The way I was doing it is by simply applying a two stepped interpolation. But to explain that I would really need to get down and have a look at my concept for that specific calculation.
I was going about it by looking at a particular height for a specific range and than figure out the relation to all the known numbers I had.

Chase Armitage wrote:That is a polynomial equation with a power of 8 - not sure if its written like that in English - which is probably describing the relation between the range and their associated elevation values. Now this is only applicable if no relative height difference is in play but it would be quite interesting to reverse-engineer the polynomial equation for range when indeed the relative height differs from zero.
I am assuming in order to gain the above equation some mathematical tool like maple13 was used. Perhaps it could be applied to determine the relation when it comes to relative heights.
The way I was doing it is by simply applying a two stepped interpolation. But to explain that I would really need to get down and have a look at my concept for that specific calculation.
I was going about it by looking at a particular height for a specific range and than figure out the relation to all the known numbers I had.

The "Range = F(x)" bit is a typo, it should be "Angle = F(x)" Where x = the range.

This will not adjust for elevation so is probably useless for you. But height is only a significant feature at ranges beyond about 1100m.

If It weren't for my currently strongly pronounced laziness I would actually key in an exemplary range and take a look at the result. It should in a any case be between 0 =< result =< pi/4. Also I havent given much thought about the numerical distribution of the barrel elevation scale but I am guessing thats a miliradians value? 1570 miliradians equals to an angle of 90(degrees) or pi/4. 800 which is the lowest value on the barrel elevation scale should equal to a value of 45(degrees) and after doing the math it indeed does. Now that is perfectly coherent with the actual physics. Any thrown object travels the most distance when launched at an angle of 45(degrees) considering the objects as well as their velocity at the point of launch are the same. So any angle below or beyond that will shorten the traveled distance of that particular object.
For our case that means our elevation values which are provided in milliradians are in the intervall of pi/8 =< elevation =< pi/4.
In case that above polynomial equation spits out angle degree values that can be pinned to that above interval it easily could be used to calculate elevations in millirads.
Also I agree that heights only start to have a significant impact on the actual elevation calculation at certain conditions. Those conditions are the distance to target as well as the difference in relative height.
Even though the needed barrel rotation increases for larger distances when trying to achieve the same coverage of ground at a smaller range the height compensation turns out to assume also non-linear values.
When comparing the difference in elevation for a set range at a height of 0 and a height of -200m and the difference of that set range to that set range + 100m by expressing it as a ratio you notice the ratio to run towards 1 with increasing ranges. At 200m the ratio is 0.11 and at 1300m 0.73 while reaching its peak. This simply means even when having a maximum negatively signed relative height difference at a small range the maximum impact on the actual elevation would be roughly 10% at 200meters (when the target were against your initial expecation at the same relative height you would be missing by 10meters - 10/100* 100meters - the most. That should put it in perspective ). Now considering the same at say 1300m the impact on the elevation could be as much as 73% which is indeed a big difference.