Making llSetLinkPrimitiveParamsFast act like llSetPos

[ItHadToComeToThis]

So. I have an attached hud object that is comprised of multiple prims.

I have it set at the minute that should an event occur the hud will shake (move) up and down slight by 0.001 and I am using llSetPos to do it. Annoyingly llSetPos has a 0.2s delay so I went to use llSlPPF as it has no delay but I can't replicate the behaviour of llSetPos. I have LINK_THIS, LINK_ROOT, PRIM_POSITION, PRIM_POS_LOCAL etc etc but there is no combination I can find that moves the whole HUD object up and down like llSetPos does.

Anyone got any ideas?

[Rolig Loon]

PRIM_LINK_TARGET

Combine actions on multiple child prims in a single function call.

[ItHadToComeToThis]

25 minutes ago, Rolig Loon said:

PRIM_LINK_TARGET

Combine actions on multiple child prims in a single function call.

Ahh yeah I know of PRIM_LINK_TARGET. I was hoping there was a way to avoid using that. Using llSetPos is a single function that uses up much less memory than multiple PRIM_LINK_TARGET calls. Hmm never mind.

[arton Rotaru]

48 minutes ago, ItHadToComeToThis said:

So. I have an attached hud object that is comprised of multiple prims.

I have it set at the minute that should an event occur the hud will shake (move) up and down slight by 0.001 and I am using llSetPos to do it. Annoyingly llSetPos has a 0.2s delay so I went to use llSlPPF as it has no delay but I can't replicate the behaviour of llSetPos. I have LINK_THIS, LINK_ROOT, PRIM_POSITION, PRIM_POS_LOCAL etc etc but there is no combination I can find that moves the whole HUD object up and down like llSetPos does.

Anyone got any ideas?

I guess the movement is just way to small, and way to fast to actually be shown in the viewer. It's probably the 0.2 seconds delay that makes it work at all.

[Fenix Eldritch]

From SLPPF caveats:

Quote

PRIM_POSITION caveats

• Depending upon the situation position may need to be in local coordinates or region coordinates, See llSetPos#Specification for details.
  • It is usually not a good idea to combine PRIM_POSITION with LINK_SET. The root will treat the coordinates as world or attachment, while the children will treat them as local, yielding inconsistent results or failure. If you want to move the object as a unit, use LINK_ROOT instead.

If you want to move the entire linkset, use LINK_ROOT. I just tested this in-world with a multi-primmed hud attachment and it seems fine. Do note that if you're just using successive SLPPF calls, the functions may be too fast to get the shake movement you want. You may need to add some artificial stalls to give the effect time to be noticed by the user. Here's my quick demo: (script written/added while the object was already attached to hud center)

default
{
    state_entry()
    {
        llSetPos(<0,0,0>);
    }

    touch_start(integer total_number)
    {
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,.001>]);
        llSleep(0.05);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]);
        llSleep(0.05);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,-.001>]);
        llSleep(0.1);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]);
        llSleep(0.05);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,.001>]);
        llSleep(0.05);
        llSetLinkPrimitiveParamsFast(LINK_ROOT, [PRIM_POSITION, <0,0,0>]);
    }
}

Edit: updated demo with 0.001 positional movements and even smaller sleep values to closer match OP's intent

Edited January 13, 2021 by Fenix Eldritch

[Nova Convair]

SLPPF can change 100s of things per second without a problem.
But that is irrelevant. You only see a difference when the simulator sends an update to your viewer - then you get to see what has changed in the world.
By my observations that can happen about 15 times per second or much less. Depends on how busy the sim is and how important it "thinks" this viewer-update is.

llSetPos and SLPP (without F) seem to be in sync with the viewer updates. (but have a 0.2 sec delay - obviously for a reason) SLPPF is not in sync.