MantisBT - opensim
View Issue Details
0002787opensim[REGION] Scripting Enginepublic2008-12-08 19:232009-01-25 18:14
closedwon't fix 
Grid (Multiple Regions per Sim)
.NET / Windows32
0002787: llSetPos is not precise
When using llSetPos() with a very accurate vector, it will round off and produce unexpected results.

I am using this script: [^]

After removing the while loop bit (because of this bug) it produces a dome that has dimensions that are quite off and produces a bad looking shape.

I used lots of llSay's to diagnose and in the move function i checked the p.z and destination.z and whenever it would llSetPos() to the destination at say "25.10391" the p.z would be "25.10392" thus always resulting in the while loop continuing forever due to the imprecision in the llSetPos() implementation.
No tags attached.
has duplicate 0003298closed UbitUmarov Prim moving with "llSetpos(pos)" and check position with llGetPos() never reach given end-position 
Issue History
2008-12-08 19:23nicktellisNew Issue
2008-12-08 19:23nicktellisSVN Revision => 7624
2008-12-08 19:23nicktellisRun Mode => Grid (Multiple Regions per Sim)
2008-12-08 19:23nicktellisPhysics Engine => ODE
2008-12-08 19:23nicktellisEnvironment => .NET / Windows32
2008-12-08 19:23nicktellisCategory[REGION] OpenSim Core => [REGION] Scripting Engine
2008-12-08 21:58dahliaNote Added: 0007687
2008-12-08 22:11nicktellisNote Added: 0007688
2008-12-08 22:35Ewe LoonNote Added: 0007689
2008-12-20 08:58HomerHorwitzMono Version => None
2008-12-20 08:58HomerHorwitzStatusnew => resolved
2008-12-20 08:58HomerHorwitzResolutionopen => won't fix
2008-12-20 08:58HomerHorwitzAssigned To => HomerHorwitz
2008-12-20 08:58HomerHorwitzNote Added: 0008169
2009-01-25 18:14chi11kenStatusresolved => closed
2009-03-14 11:34Ewe LoonRelationship addedhas duplicate 0003298

2008-12-08 21:58   
It's generally not a good idea to make exact comparison tests with floating point numbers in any situation as they are subject to tiny precision errors. I would suggest replacing the line:

while (p.z != destination.z) {

with the following line:

while (llVecDist(p, destination) > 0.0001) {
2008-12-08 22:11   
I've never encountered a problem with floats at a level of 10 thousandth in any situation other than this, only beyond billionth or abouts but I will sure give this a whirl and see what happens.
Ewe Loon   
2008-12-08 22:35   
Vairables are stored and calculated as double precission floating point numbers
thats 64 bit, while the position of the object is only single precission (32 bit) floating point
thus there is going to be inconsistancies, the above example is probibly you best solution

the position cannot be changed to double precision floating point of the viewer wouldnt work
2008-12-20 08:58   
There are numbers that just aren't representable as float. Please see notes from dahlia and Ewe Loon for a possible solution of your problem.