[CODE SNIPPET] & Extremely important note regarding position accuracy (to some)

[dreadedentity 278]

Hello all,

While working on another script I plan to release soon (debug is taking an extremely long time because of this issue), I have found out that accuracy is nearly impossible to achieve because of the way numbers are handled either in the game, in the engine, or within my operating system itself. Basically, the issue is that somewhere in the pipes, all numbers are rounded to 6 significant figures. I was in the middle of writing a huge essay explaining the situation but I deleted it because I realized a chart would be faster to understand/explain and you guys wouldn't want to commit suicide from boredom while reading it. Besides, most of you should know what significant figures are from school anyway. So here's the chart:

12983.5m

1928.93m

495.293m

93.0293m

5.20039m

0.102938m

This basically sums up the issue in 6 numbers, versus the (almost) 3 paragraphs I had written up (and we are all about optimization here). So as you can see, larger numbers lose significant portions of their accuracy, because if you do getPos (or literally any of the other position-returning commands in the game at the moment) they all output the same way.

And if you think this only applies to positions, you're wrong:

myNumber = 57.293847 + 2.394807209;
//Those numbers should equal 59.688654209, I did the math on paper and with a calculator.
hint str myNumber; //Game shows myNumber equals 59.6887. Try it!

I have made an issue in the feedback tracker regarding this, extra information is also available, if you think this is important CLICK HERE AND VOTE UP.

Why is this important? It's probably not to most people, but it's pretty important to me so I wrote this little function that's able to keep all that "extraneous" information.

DREAD_fnc_getAccuratePos =
{
/*
USAGE: _output = [P1] call DREAD_fnc_getAccuratePos;
	P1: OBJECT - The object you want a more accurate position for.
RETURNS: POSITION ARRAY (3 ELEMENTS) -
[[X position rounded to nearest whole integer, variation], [Y position rounded to nearest whole integer, variation],
 [Z position rounded to nearest whole integer, variation]]

EXAMPLE: _accuratePosition = [player] call DREAD_fnc_getAccuratePos;

RETURNS: [[14630,0.833008],[16172,0.761719],[0,0.00143814]]

ADD EACH SUB-ARRAY TOGETHER: [14630.833008, 16172.761719, 0.00143814]
*/

private ["_object","_output","_objPos1","_objPos2"];
_object = (_this select 0);
_object enableSimulation false;
_output = [];
_objPos1 = getPos _object;
_object setPos [(_objPos1 select 0)-(floor(getPos _object select 0)), (_objPos1 select 1)-(floor(getPos _object select 1)), (_objPos1 select 2)-(floor(getPos _object select 2))];
_objPos2 = getPos _object;
{
	_output pushBack [floor (_objPos1 select _forEachIndex), _objPos2 select _forEachIndex];
}forEach [0, 1, 2];
_object setPos [((_output select 0) select 0) + ((_output select 0) select 1), ((_output select 1) select 0) + ((_output select 1) select 1), ((_output select 2) select 0) + ((_output select 2) select 1)];
_object enableSimulation true;
_output
};

Using this function can return numbers (with a little work) that have up to a maximum of 11 significant figures! Currently set up only for object positions, but could probably be easily modified to input/return pure numbers using the same theory. This theory is using the "significant figures rounding effect" (as I have dubbed it) against itself, by saving an object's position, rounding down the X, Y, and Z positions to the nearest whole number and subtracting the object's current X, Y, and Z positions by the rounded numbers. Thus you have numbers like 0.0023938 and 0.392829 which since they are at 0, which allows them to utilize the maximum number of significant figures available. You then simply save both the rounded-down number, and the "variation".

I hope this helps...somebody. It helped me

EDIT: Added some colors to the chart in case anybody doesn't get it.

Edited October 4, 2014 by DreadedEntity

[das attorney 857]

There's been a lot of discussion already about this. See below for more info & existing solutions. There's probably more in the Arma 2 scripting forums but I can't remember any of those offhand.

http://killzonekid.com/arma-scripting-tutorials-float-to-string-position-to-string/

http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-(dev-branch)&p=2784968&viewfull=1#post2784968

http://forums.bistudio.com/showthread.php?163450-Strange-parse-number-behaviour&p=2631498&viewfull=1#post2631498

http://forums.bistudio.com/showthread.php?179261-Is-possible-to-use-numbers-bigger-than-1-000-000

[dreadedentity 278]

There's been a lot of discussion already about this. See below for more info & existing solutions. There's probably more in the Arma 2 scripting forums but I can't remember any of those offhand.

http://killzonekid.com/arma-scripting-tutorials-float-to-string-position-to-string/

http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-(dev-branch)&p=2784968&viewfull=1#post2784968

http://forums.bistudio.com/showthread.php?163450-Strange-parse-number-behaviour&p=2631498&viewfull=1#post2631498

http://forums.bistudio.com/showthread.php?179261-Is-possible-to-use-numbers-bigger-than-1-000-000

Thanks for these pages, I had no idea there was already this much discussion about it. Although, it would be true to say that this is probably a subject that doesn't come up very often...

[killzone_kid 1326]

Thanks for these pages, I had no idea there was already this much discussion about it. Although, it would be true to say that this is probably a subject that doesn't come up very often...

There is even talk about it on the very same wiki you left your notes on https://community.bistudio.com/wiki/Talk:getPos. I moved your notes to talk as well.