Using the getpos command on Startis or Altis return inaccurate X and Y values.
On Stratis they only have 2 digits behind the separator (1cm resolution)
On Altis they only have 1 digit behind the separator (10cm resolution)
This is to inaccurate.
In the mission.sqm files from the editor, both worlds create more accurate position values.
Open editor and place a player on the map.
In the init field put this code:
oneachframe { hintsilent str(getpos player) };
Preview the mission and watch the output.
OR
Watch the status bar in the editor.
@Killzone_Kid
Added more notes to the discussion on wiki.
This seems to be an limit to the str/format function, wich returns max. 6 digits.
Think this can be closed.
This needs to be reopened, it is NOT a str problem. All getPos commands, except getPosVisual are extremely imprecise, and have a resolution of 10+cm (anywhere).
It'll keep returning the previous position until the object has moved 10+cm.
If you in a loop sets a camera's position to that of a moving unit, it will teleport in laggy steps every 10 cm. If you instead set its position to the value from getPosVisual, it's smooth as butter.
First, what you are describing is not what this ticket was about.
Second, getPosVisual exists for that exact reason.
getPos is a simulation time command (and that is why it is choppy with moving objects) and getPosVisual is a render time command. You can learn more about it here.
They do this by design. This is the only difference between getPos and getPosVisual. You can use Visual variant instead of regular variant whenever you need what you just illustrated.