GridRefCoords.sqf

[CarlGustaffa 4]

I have this script that will translate positions into a grid reference. Unfortunately it seems a bit "hardcoded", so it will only give the correct results on the Sahrani island.

Also I have problems understanding what is going on in there.

Anyone know of a a version of this that obtains island dimensions from config file or wherever, making it possible to use on any kind of island and dimensions?

[dr_eyeball 16]

I uploaded a modified version on OFPEC recently.

Spooner is also working on a generic version which should work on most islands now. I think it's part of SPON Map.

Here is the updated pos2grid.cpp COC CEX script which I use and works on all the islands named in the script itself.

I have only modified the Zoom0/Zoom1/Zoom2 check and added the worldName switch to correct offsets. See thread above for the discussion on recent developments and why it's not generic. I hope Arma 2 will have this function as standard this time round.

pos2grid.cpp

private ["_x","_y","_cfg","_offsetX","_offsetY","_stepX","_stepY","_el","_smallZoom"];
_cfg    =configFile>>"CfgWorlds">>worldName>>"Grid";

_offsetX=getNumber(_cfg>>"offsetX");
_offsetY=getNumber(_cfg>>"offsetY");

_smallZoom = "Zoom1"; // Zoom1/Zoom2 is default used by BIS/ArmA/Sara - _smallZoom can be Zoom0/Zoom1/Zoom2
if (isClass (_cfg>>"Zoom0")) then {_smallZoom = "Zoom0"}; // if Zoom0 exists, assume it uses Zoom0/Zoom1

_stepX=getNumber(_cfg>> _smallZoom >>"stepX");
_stepY=getNumber(_cfg>> _smallZoom >>"stepY");

switch toLower(worldName) do
{
 case 'sara': { _offsetY=-480*-1; }; // uses Zoom1 & Zoom2
 case 'saralite': { _offsetY=-480*5+120; }; // uses Zoom1 & Zoom2
 case 'sakakah': { _offsetY=-480*11+160; }; // uses Zoom1 & Zoom2
 case 'map_ssara': { _offsetY=-480*5+120; }; // uses Zoom1 & Zoom2, offsetX = -4880; offsetY = -7480; 
 case 'intro': { _offsetY=-480*-1; };
 case 'porto': { _offsetY=480*10+320; }; // uses Zoom1 & Zoom2
 case 'syr_darain': { _offsetY=480*10+320; };
 case 'tolafarush': { _offsetY=480*11+320; };
 case 'schmalfelden': { _offsetY=480*10+320; }; // uses Zoom0 & Zoom1
 case 'avgani': { _offsetY=480*10+320; }; // uses Zoom0 & Zoom1
 case 'afghan_village': { _offsetY=-480*16+80*3; };
 case 'razani': { _offsetY=240; }; // uses Zoom0 & Zoom1
 case 'fdf_isle1': { _offsetY=-480*21+320; }; // podaga
 case 'map_3demap': { _offsetY=-480*15+0; };
 case 'tatawin': { _offsetY=-480*25+160; };
 case 'watkins': { _offsetY=-480*11+160; }; // uses Zoom0 & Zoom1
 case 'uhao': { _offsetY=480*11+320; }; // uses Zoom1 & Zoom2, offsetY = -15360;
 case 'uns_nt': { _offsetY=+480*32; };
 case 'unskduc': { _offsetY=+480*32; };
 case 'vte_australianao': { _offsetY=-480*30; };
};

_x=(_this select 0 select 0)-_offsetX;
_y=(_this select 0 select 1)-_offsetY;


_el=
[
   ["A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"],
   ["a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"],
   ["0","1","2","3","4","5","6","7","8","9"],
   ["0","1","2","3","4","5","6","7","8","9"]
];

_xs=([1,-1]select(_x<0));
_x =((abs _x)-((abs _x)mod _stepX))/_stepX;

_y=100*_stepY-_y;
_ys=([1,-1]select(_y<0));
_y=((abs _y)-((abs _y)mod _stepY))/_stepY;

_xf=_x mod 10;
_xc=(_x-_xf)/10;
if(_xs<0)then{_xf=9-_xf;_xc=count(_el select 0)-1-_xc};_xc=_xc mod(count(_el select 0));_xc=_xc max 0;

_yf=_y mod 10;
_yc=(_y-_yf)/10;
if(_ys<0)then{_yf=9-_yf;_yc=count(_el select 2)-1-_yc};_yc=_yc mod(count(_el select 2));_yc=_yc max 0;

format["%1%2%3%4",_el select 0 select _xc,_el select 1 select _xf,_el select 2 select _yc,_el select 3 select _yf]

Edited April 22, 2009 by Dr_Eyeball
reformat

[CarlGustaffa 4]

Thanks a lot! This will solve a lot of small bugs, excellent. Just what I was hopng for.

[beita 10]

I've got a few questions about this script (found a more recent one, but it still applies).

Can this be changed to allow for getting a position from a grid? I'd like it to be in the center of the grid if possible, even better would be to add another digit onto the grid, and use that. So, instead of a 6-figure grid reference, it would be an 8-figure one.

Also, will the above script work with the ACE islands, or will new entries have to be made into the switch according to the map's worldName?

[CarlGustaffa 4]

I have a hard time reading this script, i.e. trying to understand how it works. Maybe it's just my lack of certain math skills kicking in. So I never tried going anything else with it.

As for ACE islands, my guess is no, at least not easily enough so that I could do it. I had to implement SPON_Map in my Domination Lite edit in order to get working grid references. SPON_Map is rather big for such a 'small' feaure, and have its own problems you have to work around (not working from the editor unless Shift Preview, can not work on the server, only clients).

I put a request for such a system on the ACE ticket system, but it was set to future with 10.000 hours estimate time :S So, no, I don't think we'll be seing a builtin function there in the near future.

Basically, I have given up now. I'm awaiting ArmA2 and hoping it has builtin functions to obtain grid from pos and to set pos given grid (center of), since at least ArmA2 seems to be based on a 6 digit grid.

In ArmA units will gladly report their correct positions whatever the gridsystem the world is using. I just don't get why we (the scripters and mission making people) can not be given the same possibility with a couple of simple commands. ArmA1 is now in it's final life cycle (given that ArmA2 will 'soon' arrive), and we still don't have a general purpose grid reporting system that works flawlessly for any given island.

You have no idea the amount of greaf and frustrations the lack of such a feature has caused me...

[HitmanFF 6]

This is the version I've made that will show the grid ref for the ACE islands I'm using. Works fine for Nogova, Everon and Trinity. You should be able to include the other islands fairly easily, if need be:

private ["_x","_y","_cfg","_offsetX","_offsetY","_stepX","_stepY","_el","_smallZoom","_fourdigit", "_return"];
_x = (_this select 0 select 0);
_y = (_this select 0 select 1);

_cfg = configFile>>"CfgWorlds">>worldName>>"Grid";

_offsetX=getNumber(_cfg>>"offsetX");

_smallZoom = "Zoom1";
comment "Zoom1/Zoom2 is default used by BIS/ArmA/Sara - _smallZoom can be Zoom0/Zoom1/Zoom2";
if (isClass (_cfg>>"Zoom0")) then 
{
 _smallZoom = "Zoom0"
};
comment "if Zoom0 exists, assume it uses Zoom0/Zoom1";

_stepX = getNumber(_cfg>> _smallZoom >>"stepX");
_stepY = getNumber(_cfg>> _smallZoom >>"stepY");

_offsetY = 0;
_fourdigit = true;
switch toLower(worldName) do
{
case 'sara': { _offsetY=-480*-1; comment "uses Zoom1 & Zoom2";};
case 'saralite': { _offsetY=-480*5+120; comment "uses Zoom1 & Zoom2"; };
case 'sakakah': { _offsetY=-480*11+160; comment "uses Zoom1 & Zoom2";}; 
case 'vte_australianao': { _offsetY=-480*30; };
case 'map_ssara': { _offsetY=-480*5+120; comment "uses Zoom1 & Zoom2, offsetX = -4880; offsetY = -7480;";}; 
case 'intro': { _offsetY=-480*-1; }; 
case 'porto': { _offsetY=480*10+320; comment "uses Zoom1 & Zoom2"; };
case 'syr_darain': { _offsetY=480*10+320; };
case 'tolafarush': { _offsetY=480*11+320; };
case 'schmalfelden': { _offsetY=480*10+320; _stepX=100; _stepY=100; comment "uses Zoom0 & Zoom1"; };
case 'avgani': { _offsetY=480*10+320; _stepX=100; _stepY=100; comment "uses Zoom0 & Zoom1"; };
case 'map_3demap': { _offsetY=-480*15+0; };
case 'watkins': { _offsetY=-480*11+160; comment "uses Zoom0 & Zoom1"; };
case 'uhao': { _offsetY=480*11+320; comment "uses Zoom1 & Zoom2, offsetY = -15360;"; };
case 'ace_island_eden': { _offsetY=-128*100; _fourdigit = false; comment "uses Zoom1 & Zoom2, offsetX = 0; offsetY = -2560;"; };
case 'ace_island_noe': { _offsetY=-128*100; _fourdigit = false; comment "uses Zoom1 & Zoom2, offsetX = 0; offsetY = -2560;"; };
case 'ace_island_trinity': { _offsetY=-128*100; _fourdigit = false; comment "uses Zoom1 & Zoom2, offsetX = 0; offsetY = -2560;"; };
default { _offsetY=getNumber(_cfg>>"offsetY"); };
};

_x= _x - _offsetX;
_y= _y - _offsetY;

if (_fourdigit) then
{
 _el=
 [
    ["A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z"],
    ["a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"],
    ["0","1","2","3","4","5","6","7","8","9"],
    ["0","1","2","3","4","5","6","7","8","9"]
 ];

 _xs = ([1,-1] select (_x<0));
 _x = ((abs _x) - ((abs _x)mod _stepX)) / _stepX;

 _y = 100 * _stepY - _y;
 _ys = ([1,-1] select (_y<0));
 _y = ((abs _y) - ((abs _y) mod _stepY)) / _stepY;

 _xf = _x mod 10;
 _xc = (_x-_xf) / 10;
 if (_xs<0) then
 {
   _xf = 9 - _xf;
   _xc = count(_el select 0) - 1 - _xc
 };
 _xc = _xc mod (count(_el select 0));
 _xc = _xc max 0;

 _yf = _y mod 10;
 _yc = (_y-_yf) / 10;
 if (_ys<0) then
 {
   _yf = 9 - _yf;
   _yc = count(_el select 2) - 1 - _yc
 };
 _yc = _yc mod (count(_el select 2));
 _yc = _yc max 0;

 _return = format["%1%2%3%4",_el select 0 select _xc,_el select 1 select _xf,_el select 2 select _yc,_el select 3 select _yf];
}
else
{
 _return = format["%1%2%3%4%5%6", floor(_x / 10000) % 10, floor(_x / 1000) % 10, floor(_x / 100) % 10, floor(_y / 10000) % 10, floor(_y / 1000) % 10, floor(_y / 100) % 10];
};
_return

[CarlGustaffa 4]

Rgr that, I will try it out some time.

[Mike84 1]

I've got a few questions about this script (found a more recent one, but it still applies).

Can this be changed to allow for getting a position from a grid? I'd like it to be in the center of the grid if possible, even better would be to add another digit onto the grid, and use that. So, instead of a 6-figure grid reference, it would be an 8-figure one.

Also, will the above script work with the ACE islands, or will new entries have to be made into the switch according to the map's worldName?

I actually have been working on a 'grid2pos' function for the past 2 days, and it is working pretty nice now. It only works for numeric coordinates like the ones you find in ACE and zCommon, and also with islands that have 'stepY = -100' (the Y axis increases value as it goes up, like real maps do, yes ACE devs), and currently only accepts 8 numeric digits (6 digits are useless).

When I've tested the grid2pos function a bit more, I'll work on a 'pos2grid' function that will be based on Spooners code, but doesn't require an additional dialog to measure the size of the map.

There are currently 2 ways of how to do that that I know of, which are:

- Finding the island width of each island, and putting each value for each island in the function (I did this for my grid2pos function)

- Using the default in-game map control to measure it (works fine, but it blinks the screen for a milisecond, which is annoying).

Once those functions are both done (which might take some time, as I'm also working on a artillery system atm which uses these functions) I'll post them on ofpec.

[beita 10]

Awesome! Sounds like exactly the kind of thing I'm looking for. Looking forward to it.

[CarlGustaffa 4]

@Mike84: Why are 6 digits 'useless'? From 6-30:

"a. In a grid mission, six-place grids normally are sent. Eight-place grids should be sent for registration points or other points for which greater accuracy is required."

"f. Distribution. The observer may control the pattern of bursts in the target area. This pattern of bursts is called a sheaf Unless otherwise requested, the battery, computer system (BCS) assumes a circular target with a 100-meter radius." (that covers 4 grids, or the center grid pluss half a grid around).

Maybe when using a converged sheaf onto a point (i.e. a tight group of vehicles) would it mean something to use more than a 6 digit grid? I've also seen 10 digit grids being used for an adjust mission, so I guess anything is really possible. This was used in a movie though.

8 digit grid in ArmA could possibly mean something though:

* You can't create 'realistic' artillery shells because ArmA really can't deal well with the amount of damage inflicted. See how 'stupid' Domination does DPICM rounds, reason being that server can't deal with a faster delivery. I tried. Will crash server.

* You don't want to have the same strenght, because of balancing issues. The size of the enemy that an ArmA server can handle isn't big enough to validate the use of full strenght shells. We typically see a squad or platoon sized unit holding a location, instead of batallion or higher echelons.

So to compensate for lack of sheer firepower to the reasons given above, one could validate the use of increased accuracy instead by using 8 digit grids.

Sending you a PM also Mike84.

[beita 10]

I guess it all depends on the type of artillery you are talking about.

A 6 figure grid ref may be fine for a fire mission meant for an enemy Company/Battalion, but what about a mortar fire mission on a house or bunker? 6 figure is simply not accurate enough for this. 8 figure probably isn't either, but it's still a LOT closer.

Will you be releasing the function to the public? I'd really like to use it in an artillery system I've got, along with some other functions.

EDIT:

My bad, didn't read your post properly.

[CarlGustaffa 4]

For a specific target such as a house or bunker, the observer would either request a converged sheaf combined with an 8 (10m accuracy) digit grid, or 10 (1m accuracy)? If not, the type of target would be included in his call for fire, and the FDC would probably request a more accurate grid if it was left out. Keep in mind that although you're calling in a 10 digit grid, the fire computer might increase the number of shots to increase the hit probability depending on the current dispersion (!= distribution).

In my version however, I will be indicating the dispersion ellipse when a converged sheaf distribution is selected. So my forward observer will also do some of the FDC tasks, to lessen the computations.

One of my main frustrations with all artillery solutions thus far has been they have been too easy to use, with no error factors. What I'm doing for pinpoint accuracy (dispersion errors still apply though), is requiring the observer to designate his position accurately. Still using map clicks, but it gives more of a challenge to hit a point target. For non accurate fires, just use a 6 digit grid, and live with the reduced firing effects of ArmA (it just can't cope with too much destruction, causes lag and server crash).

[Mike84 1]

I can't seem to attach scripts on this forum, so here a link to the ofpec thread:

http://www.ofpec.com/forum/index.php?topic=33299.0

I added support for 6, 8 and 10 grid coordinates for you carlgustaffa (hopefully you dont need more or less than that)

[beita 10]

I can't seem to attach scripts on this forum, so here a link to the ofpec thread:

http://www.ofpec.com/forum/index.php?topic=33299.0

I added support for 6, 8 and 10 grid coordinates for you carlgustaffa (hopefully you dont need more or less than that)

Awesome! Thanks for this function.

[CarlGustaffa 4]

@HitmanFF: Sorry, but I wasn't able to make the system work for ACE_Sara. Sorry btw, I ment the redefined ACE Sara island, not those in the ACE Island pack. Guess I'm stuck with SPON_Map for a while.