'Walking' builds.

Created a clock object. Root prim with 3 rotating disks, one for each hand. Works fine as far as timekeeping. Howver, over a day period, it 'walks' in some random direction...doesn't matter if I lock it down or not. Also have a steam engine build with an animated piston arm...same deal as the clock, only walks FARTHER each day than the clock.

So I wrote a program that on a touch by the owner, records the position the item was placed in. A timer function checks current position every few minutes and if the item was moved, it returns it to the original position. Now, here's the problem...

On any clock or steam engine I make and own, it works FINE...will stay in place for weeks on end (like the clock atop the tower on my store). Someone buys one (-copy, -mod, +transfer on all objects and code), they start to walk, even though the owner touches it and it SAYS it is locked.

First, why with NO motion scripts in the root prim (they are all in child prims) does the damn thing move at all, it is NOT physical, yet somehow the rotating objects cause the root prim to move?

Second, why would my lock script work fine for me, but do absolutely nothing but print the 'locked in place' the message when someone else buys one and tries to lock it down?

Here's the (rather primitive, am still learning) code I came up with to fix position with a mouseclick by owner. It works fine with full perms when I own an object....fails on tranfer only objects I give people (they get the lock and unlock messages but it still moves over time).

// position fixer - Maklin Deckard

vector startpos;
vector currentpos;
integer lockpos;

default
{
    state_entry()
    {

    }
    
    on_rez(integer temp)
    {
        llSetTimerEvent(0);
        lockpos = FALSE;
        llWhisper(0,"Position your object and click on it to lock the position.  If it is moved, it will be reset to original position ever 60 seconds.");
    }

    touch_start(integer total_number)
    {
        if ( llDetectedKey(0) != llGetOwner() )
        {                                                                                                       return;
        }
        
        if(lockpos == FALSE)
        {
            lockpos = TRUE;
            llWhisper(0,"Locking position, item will be checked ever 60 seconds and returned to current position if moved.");
            startpos = llGetPos();
            llSetTimerEvent(60);
        }
        else
        {
            llSetTimerEvent(0);
            llWhisper(0,"Position unlocked, item location will no longer be checked and returned to initial position.");
            lockpos = FALSE;
        }
    }
    
    timer()
    {
        currentpos = llGetPos();
        if(startpos == currentpos)
        {
            llSetPos(startpos);
        }
        else
        {
            llSetPos(startpos);
        }
    }
}

From what i noticed, any changes (and that's literally any, even things like setting colour or transparency of prim) made to a piece in linked set can cause re-calculation of the set centre point, which is the point that determines location of set in world. It doesn't make sense and is possibly a bug, but it does happen.

So i'd figure when/if there's some sorts of rounding errors and other inaccuracies creeping into this centre point calculation --and seeing how re-calculation can cause the centre point jump temporarily as much as few cm from previous position-- i could see this somehow affecting overall position of object in the sim over prolonged time o.O;

Yeah, I had it printing out x,y,z for a bit...while we can only set it from edit to 3 decimal places, the LSL was showing to 6 places, the last place changing randomly...which explains the creeping.

Still at a loss why the lockdown program I listed works fine for me, but not for anyone I give or sell the item too....two identical items, same code...mine stays put for weeks, the copy still creeps around. Who owns the object should NOT matter to the program...but yet it does. Could be permissions....when I test its full permissions since I created and own it...I wonder if the nomod is what is causing it? Maybe it cannot relocate the object if its nomod? Hrm, may have to make an alt and experiment with giving him a transfer only and a transfer/mod version and lock them down side by side and wait a day...

I used to program on the old text based games, in a forth based language called MUF. LSL makes THAT look logical and stable.

There are lots of weird things in that code, but I can't see what is causing it to fail when the owner changes. Is it getting to the timer() event when someone else owns it? (Check by putting a whisper in there). It's maybe possible that some other script in the object is messing it up, though I doubt it.

if ( llDetectedKey(0) != llGetOwner() )
        {                                                                                                       return;
        }

You're missing the ret-- nevermind, it was just spaced so far over that it wasn't visible in the code box. O_o

You don't have any scripts flipping the object between physical and non-physical, do you?

Other than that, I'm baffled - I'll watch to see if any of my test turrets drift, though.

You can only edit to three places because the values are sent across the network layer quantized down to 16-bit values (and in general only use the range 0-200) instead of 32-bit floats. Even at three decimal places you can't use all the values, 0.038 might correct to 0.041 as an example, depending on the property you are changing. Position however is sent using full 32-bit floats, but who knows how the server engine handles it.

I'm pretty sure it has something to do with permissions, Maklin.


My experiences with such are similar to Joannah's, though that was almost a year ago when I last did anything like that.

Anything that uses server side rotation is rather tough on sim resources; if there is any way to use client side rotation or a texture rotation, that's a far gentler way to go. However, I remember some bugs in the texture rotation... it's been a long while.

I haven't seen this in a very long time; but tortured prims have a tendancy to 'walk'. I had a prim once that each time it was edited it would move a bit. I did like you, every so often i would reset the prim position.

I had formatting issues with the code box Sorry.

Nope, he entire clock is not physical. I use three separate programs (in the hand objects) to adjust the angle of the hand prims to the desired angle in the clock. In the steam engines, the move scripts are in the piston arms. Nothing should ever touch the root prim...but something is.

Hrm, cannot wait till I can get home and hand an alt a copy that is transfer only (the way I sell them) and one that is mod/transfer ok. I really don't like doing mod, but that could well be the root of the issue. EDIT: On second thought, mod is OK....just have to have a disclaimer that if you relink anything and change the root, you broke it and are out of luck.

Another person had a good idea, a whisper in the timer routine to see if that fails for another player. Sigh....I love building, just finished an industrial sized stationary engine w/dual pistons, but the way LSL reacts is driving me nuts.

Wouldn't happen to have the code you used, I'd like to take a look at it and see if there is something I am not doing right.

I'd have to dig it up and i don't have the time to do that. We are talking like 2004. The prims i mentioned would move when anyone would edit the prim; reguardless to if they had rights to it. It was very weird. I didn't report it till a year later, LL back then had a tendancy to ax features that didn't work right (and they had already axed some aspects of prim torture, i was not optimistic).

You can have my code Maklin - though be warned, it's fairly script-cycle intensive. One might want to test this in a sandbox

Takes too long for a sandbox, you say?

Easy fix. Drop in multiple scripts, and shorten the loop cycle timing. Hopefully nobody will notice when all scripts in the sim start performing slo-mo like Neo in the Matrix, but you shouldn't be at it all that long.

I'll have to go digging the scripts out of things (I don't save such in 'scripts' folder, as eventually I forget the context).

I confirmed that my non-physical turrets with rotating parts were also 'drifting' slowly over time, and have come up with a fix which does not require the owner to ordering the object to stay put, and which does not interfere with the owner moving the object manually.

It simply involves a timer ticking about every 0.3 seconds, and checking the distance the object has moved. If it is less than 0.002, the object is silently returned to its last good position. If it is more, then the object is allowed to move.

(I don't know whether lacking modify permissions would interfere with this, but I intend to sell the turrets as copy/modify/no-transfer)

The highest drift distance I saw (while I had it spamming me with the messages) was 0.000881. The lowest distance due to me moving a turret slowly at normal zoom was 0.004283. I then tested zooming in on the object and dragging it verrry slowly until it visibly moved. This came out to around 0.0022 - 0.0023. I then zoomed way the heck in so that my screen was pretty much filled by the turret, and tried dragging it as slow as possible once more - that time it was actually caught by the position-fixer, and moved back (it visibly moved and then moved right back). Dragging it a little faster (still zoomed way the heck in) worked properly. Conclusion: If you are zoomed in so far that a 0.5 radius sphere fills your entire screen, and you drag like molasses, then you will have problems. Otherwise, you will probably have no trouble at all moving something with this lock on it.

Needless to say, I can't guess whether other objects would be affected greater or less by their rotation, and if they are affected more, you might need to increase the threshold. (This should probably also be tested somewhere laggy, like the weapons testing sim, to make sure the drift doesn't exceed the correction threshold if there's a lot of lag)

Here's the script, with a debugging message sent to the owner whenever the object is moved faster than the detection threshold (so that if it's drifting too fast, you will have an idea of how high to raise the threshold). You can comment that out if it's working good already, of course.

vector lockedPos = ZERO_VECTOR;
default {
    state_entry() {
        lockedPos = llGetPos();
        llSetTimerEvent(0.3);
    }

    on_rez(integer param) {
        lockedPos = llGetPos();
        llSetTimerEvent(0.3);
    }
    
    timer() {
        float diff = llVecDist(llGetPos(), lockedPos);
        if (diff>0 && diff<0.002) {
            //llOwnerSay("Detected and corrected turret movement by "+(string)diff+".");
            llSetPos(lockedPos);
        } else if (diff>=0.002) {
            llOwnerSay("Turret at "+(string)llGetPos()+" in "+llGetRegionName()+" detected turret movement by "+(string)diff+" - we presume this is by a user.");
            lockedPos = llGetPos();
        }
    }
}

You could also do a periodic sensor scan for the owner, and raise the threshold while they're not nearby - this would make it less likely to drift if time dilation increases the drift rate, without making it harder for the owner to move the object (since the threshold would be at its normal low level while they're nearby).

Oh, sandbox is ALWAYS where I test my really 'experimetal' items in SL. Sort of like when I was coder on one of the text based MU*'s, I had a copy of the DB and an offline MU* running for really drastic program testing - This was of course after HARDLOCKING the MU* daemon on the real server server a couple times (Well, that could be conclusively PROVEN as being my code, that is).

See? Even programmers CAN learn from experience (it just usually takes them a hell of a lot longer than normal people )!

Hrm, I could also leave the threshold HIGH and institute a touch or dialog-driven on/off for the owner to use. Going to work with this again tonight....I currently have two clocks in my house that I gave to my friend and beta tester, one with and without mod perms....going to see if it is the permissions affecting my code once SL comes back up from patching.

Thank you for the help!

I also had problems with the rootprim walking off in random directions doing my Prizm Sign (a sign with several prismas that rotates in a predefined pattern).

This annoyed me highly and some customers that bought it would of course harass me and call me misc names.

I also suspected that there was a rounding problem in the script, so i skipped all dynamic Euler2Rot calls in the code and just calculated the rotations at startup.

That decreased the walking but not completely.

Anyway, the SL update two weeks ago seems to have fixed the walking. I did some measurements on the signs and also on a clock i made and they seem to be fix in the world now without any firther change of the code.

Also the customers signs work, the exactly same objects that before the update would wander.