(Accepted) Grid Coordinate Function

[DucusSumus]

I edited an old OFP function, which would take a position and return a grid coordinate, for ArmA.  To use it, simply preprocess the function and then call it anywhere you need it.  It takes one parameter, a position.  Here's an example of how to use it:

Code: [Select]

gridCord = compile preprocessFile "gridcord.sqf";
MyGridPosition = [getPos player] call gridCord;

[Eymerich]

I have had a (fast) look to your functions.
Seems interesting and seems short too!
I'll try this evening.
Thank you!

[Blanco]

Very nice.
What's the difference between your script and posworldtoscreen and posscreentoworld?

[DucusSumus]

To be honest, I wasn't even aware that those functions existed.  The biggest difference with my function, though, is that it returns a string rather than an array.  This looks a little nicer in a radio message, for example. 

[Mandoble]

Blanco, this function these two commands have nothing in common.
These commands are based on the existance of a map control placed somewhere in an active display (dialog). So, as anyother control, its screen coordinates go from 0 to 1. Whith these functions to may transform world coordinates to screen coordinates [0-1, 0-1] so you can "draw" things on the map control.

[Cheetah]

Hmm is your one better than mine? Could be that your algorithm is alot better.

[Mandoble]

It is not a matter of better or not, the real matter is that the function posted here is only valid for OFP, while yours (Cheetah), with better or not better algorithm, is well suited for ArmA coordinates (quite weird coordinates btw).

[DucusSumus]

Mandoble, my function works in ArmA.  That is why I posted it.  It's based on an OFP funciton, but it has been altered to work in ArmA.  Go ahead and try it. 

[Mandoble]

You are using ["A","B","C","D","E","F","G","H","I","J"]; and this set is not what ArmA uses: W,X,Y,Z,A,B,C,....,O for Sara and Z,A,B,C,D for Rhamadi.

[DucusSumus]

Position in ArmA is zero at the beginning of A; west of A, x is a negative number in the position array.  This is because it is extremely unlikely for you to be in a location that has a grid coordinate outside of A - J.  Everything outside of that area is just ocean.  Inside the playable area, my function will return the correct grid coordinate.  You'll get errors in the WXYZ and KLMNO areas, but there is absolutely no land in those areas.  I could alter the function to make it include these areas, but I decided not to do so because it just isn't necessary.

[Cheetah]

Don't know if Rahmadi is on the negative side.

[DucusSumus]

It is; I've tested it.  The beginning of the A coordinate is a zero in the position array.  West of that (into Z territory), it's negative. 

[bedges]

I could alter the function to make it include these areas, but I decided not to do so because it just isn't necessary.

did BI not include boats in arma? i don't have it so i can't check...

[DucusSumus]

There are boats, but the areas that are outside of the "regular" grid (A-J, 0 - 99) are wayyyy out there.  They're beyond all of the sub-islands even.  Honestly, I can't think of a single scanario that would have you out that far.  Even if I were to edit this function to make it include those areas, it doesn't need to be as complex as Cheetah's (though his works very well). 

[bedges]

i can think of several scenarios, for example a recreation of horatio nelson's last battle, where the player should be far enough out of range of land that it looks like the open ocean in all directions.

but then, they didn't have sat-nav in those days huh... 

point is, if it's worth writing a function to do a job and if it causes little hassle to do that job in *all* circumstances, that's what you should aim for. limiting the function because you cannot foresee all the possible uses that the function could be put to by enterprising users is enforcing an unnecessary constraint on the resource.

if it does complicate the resource considerably or has an adverse effect on the engine, then that's a different story.