Turn(piecename,x_axis,numberA,numberB)

[PicassoCT]

Is it possible that the numbers you hand over to this functions have a sizelimit? Not in, capped by a Maximum, but a sizelimit when it comes to precision? I experiMentaled with the trooper on the rope, and experienced, that if i dont round the numbers the piece simply dissappears and is never seen again. I first supspected nils and nans to screw it up, but after filtering them out, i still get the vannishing trooper.

So I figured that as pieces can turn turrets, therefore i conclude they are gamerelevant, therefore they are synced, and therefore there precision has somehow to crash into the wall of determinism. So if i concluded right, by trying to break trough said wall, the piece simply vannishes to avoid a desync?

[Tobi]

There's no logic that makes pieces suddenly disappear when they are prone to desync or so.

What values are you passing?

[PicassoCT]

Im passing a 3and recive a 0 - there is no logic behind any of this anymore.

Two third of my function are now barriers, tests if anything turned nil and nan all of the sudden. Yeah, i know, check for math.rules violation (no squareroot of neg numbers) no dividing by zero.. but honestly if a language has problems passing on values to functions... what is there left to check?

boolean moveCode2Crematory=true;

Well it works, as long as i use hardcoded values. Guess ill just have a constant pedulum soldier, retarded_script should be happy for a good third place in the special_scripts_olympics. ;(

[knorke]

sounds like bug in script, eg moving the pieces veeeeeery far away.
post an example? (best would be model+script so its testable)
also try echoing the variable used for animating:

bla = srsbsnss math*lolfactor
Spring.Echo ("bla="..bla)
Move (piece, x_axis, bla)

[PicassoCT]

Did it, and now it works, for now.. dont know how long..

Still its not perfect...goto work on it. The soldiers sometime swings out of tune... will send you a version knorke.