How do I make individual object float in a linkset

[HoneyB18]

I've already got help from a creator about how to make individual rotating parts and i don't want to bug them again about how to make individual floating parts as i have never seen that in their creations, so i have come here to the forums for guidance... i already tried something from the wiki and my object ended up floating into  the abyss (it went off world).

This is the effect i am looking to create without making the entire linkset float:

// Heights in meters

float moveMPerStep = 0.001; // Move x meters per step
float changeStage = 0.001; // Increment speed to quicken then slow move
integer steps = 40; // Number of steps per cycle
float topWait = 0.0; // Wait duration at top position till descending
float botWait = 0.0; // Wait duration at bottom position before ascending

integer top;
integer count;
vector pos;
float Z;

default
{
    on_rez(integer start)
    {
        llResetScript();
    }
    
    state_entry()
    {
        top = FALSE;
        count = 0;
        llSetTimerEvent(0.01);
    }
    
    timer()
    {
        vector pos = llGetPos();
        
        if( count != steps )
        {
            if( top )
            {
                if( count < steps/2)
                {
                    moveMPerStep += changeStage;
                }
                else
                {
                    moveMPerStep -= changeStage;
                }
                pos = llGetPos(); 
                pos.z -= moveMPerStep;
                llSetRegionPos(pos);
                count ++;
            }
            else
            {
                if( count < steps/2)
                {
                    moveMPerStep += changeStage;
                }
                else
                {
                    moveMPerStep -= changeStage;
                }
                pos = llGetPos();
                pos.z += moveMPerStep;
                llSetRegionPos(pos);
                count ++;
            }
        }
        else if(  count == steps )
        {
            if(top)
            {
                top = FALSE;
                llSleep(botWait);
            }
            else
            {
                top = TRUE;
                llSleep(topWait);
            }
            count = 0;
        }   
    }
}
 

This is the script i was given for individual rotating objects in a linkset:

default
{
    state_entry()
    {
      llTargetOmega(<0,-1,0>,0.3,1.0);
    }

}

Please help ^.^'''''

[Profaitchikenz Haiku]

Don't use llSetRegionPos.

I assume this script is to go into the child prim to be moved up and down, so you need to use llSetPos, and the position you are going to be getting and varying should be relative to the position of the root prim in the link set.

Use llGetLocal Pos which gives a vector of the child position relative to the root prim, and after adding to or subtracting from this value, use llSetPos to reposition the child prim.

[shaniqua Sahara]

39 minutes ago, Profaitchikenz Haiku said:

Don't use llSetRegionPos.

I assume this script is to go into the child prim to be moved up and down, so you need to use llSetPos, and the position you are going to be getting and varying should be relative to the position of the root prim in the link set.

Use llGetLocal Pos which gives a vector of the child position relative to the root prim, and after adding to or subtracting from this value, use llSetPos to reposition the child prim.

i was curious about this script so i tried it......i used llSetPos and llGetLocal Pos. when i put the script in the root prim, the entire linkset floated up and down. when i put the script in a child prim, it floated up, but then just like the happened to the OP, the prim flew out into the universe, god knows where. edit- i should have said the entire object shot away.

Edited October 30, 2019 by shaniqua Sahara

[Qie Niangao]

The downside of llSetPos is the 0.2 second built-in delay, so something like 
                llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_POS_LOCAL, pos]);
might be smoother (still assuming llGetLocalPos and the script is in the "floating" link).

Note, though, that this thing is going to send a constant stream of object updates, in stark contrast to llTargetOmega() which is "set and forget" as far as the sim and script are concerned. Best to tune the timer interval as high as possible within the bounds of acceptable smoothness.

[HoneyB18]

i need it to move a 3 prim object that's linked together as if it where one object without moving the entire build i been asking in the scripts group and i think i did get a script that might work BUT i have yet to try it.... i was however wondering if there was a one line or 5 line scripting option because this is a lot of code!

[Profaitchikenz Haiku]

Confusing, a 3-prim object linked together is one object, so just move the root to wherever you want it to go, with the caveat that you can't move more than 10 metres at a time (unless you use llRegionSetPos)

If you're saying that in a large build there are three children that you want to move together as if they were a linked set than it becomes a matter for using PRIM_LINK_TARGET in llSetLinkPrimitiveParamsFast, but you will have to calculate three separate local position adjustments for the children.

Edited November 2, 2019 by Profaitchikenz Haiku

[HoneyB18]

No it's one item with three prims linked together that i want to add to a bigger build that has around 6 prims linked but i only want the 3 to move equally (i will actually be adding 4 of these 3 linked prims) without it moving completely apart from each other BUT to move separate from the rest of the build

Edited November 14, 2019 by HoneyB18

[Qie Niangao]

Sorry but it's still not clear. Those three prims you "want to add to a bigger build", by adding them, do you mean linking them, so end-game there's one big linkset in this build? That's what we've all been kind of assuming, I think. If instead you want the "build" to consist of two separate linksets, one of which has only three prims and moves around relative to the other, that's doable too although it entails some obvious logistics problems inherent to multi-linkset builds.

(Also, to repeat something I said above: this kind of oscillation is much more "expensive" to sim and network than the simple llTargetOmega() rotation. If it's something that happens only occasionally on command, it'll be fine, but if it's something that just keeps oscillating all the time, you want to be sure there can never be many of these in view at the same time. The only way to make that efficient would be to use Animesh, which would be a whole project for something this simple, and would come with absurdly high Land Impact.)

[HoneyB18]

I’m unsure how to make it more clear.... I can tell you what the object is and how many total prim count the entire build is when the objects are connected

the build I want to float in sync without ruining the position of the linked item is a flower candle... the flower and the candle are a separate prim linked together and I linked a flame particle prim to the candle as well. I want 3 of these flower candles floating on the main build (12 prims with the flower candles added) without it moving the entire build just the flower candles. Each flower candle will float over a pedestal.

basically I want them in sync with their linked items while not moving the pedestals, base and the main item which is a pentacoastal.

i have a script that will possibly work thanks to the scripts group but I have yet to test it tho I was wondering if there was a way to script it without needing so much code.

Edited November 15, 2019 by HoneyB18

[HoneyB18]

And yes the end result will be that all items get linked together as I said but only the flower candles will be floating while the pentacoastal rotates and the rest of the build stands still. The land impact I know for a fact is 12 in total when I link them without any script (idk how a script would increase land impact and prims)

Also I’m not rigging an entire build that I’ve already finished perfecting and have already uploaded.

Edited November 15, 2019 by HoneyB18

[Mollymews]

Honey, sometimes is best to take a simple path to get the smoothest rotation for the least amount of scripting effort. For example, a simple path is:

1) link the candles arrangement to a transparent central prim. The central prim set to llTargetOmega() which will smoothly rotate the candles arrangement

2) the pedestal is a separate object

3) put them both in a rezzer box. Which rezzes the pedestal and then rezzes the candles arrangement above it

[Profaitchikenz Haiku]

As I understand it, the OP wants the candles to move up and down, not rotate. 

[Qie Niangao]

Well, here's a simplified SAMPLE of a script that might be relevant to the task, assuming I understand what's being attempted here:

/* 
 Public Domain, 2019, Qie Niangao
 
 NOTE WELL: THIS DOES *NOT* SUPPORT RESIZING OR ADJUSTING THE OBJECT WHILE IN MOTION

 If any adjustment is to be made, the script must be stopped and reset 
 and links moved to their new home positions before the script is started again
 
 SIMPLIFIED by assumption that root prim's Z axis points straight upward in world coordinate system
 (it's not THAT complex, but hire a scripter already, huh?)
*/

list FLOATING_LINK_NAMES = ["Candle", "Flame", "Flower"];
float UPDATE_INTERVAL = 0.1;   // Make this as LARGE AS POSSIBLE while motion is still acceptably smooth
integer STEPS = 20; // Use as FEW AS POSSIBLE while still obtaining acceptably smooth motion
float MAX_Z_OFFSET = 0.5;

integer twoSteps;
integer step;

list floatingLinkHomes; // positions only, they won't rotate
integer homeListLength;

// Interpolated motion http://wiki.secondlife.com/wiki/Interpolation/Cosine/Float
float fCos(float x, float y, float t) {
    float F = (1-llCos(t*PI))/2;
    return x*(1-F)+y*F;
}   // Released into public domain. By Nexii Malthus.

default
{
    state_entry()
    {
        integer link;
        for (link=llGetNumberOfPrims(); link>0; link--)
            if (~llListFindList(FLOATING_LINK_NAMES, [llGetLinkName(link)]))
            {
                floatingLinkHomes += link;
                floatingLinkHomes += llList2Vector(llGetLinkPrimitiveParams(link,[PRIM_POS_LOCAL]), 0);
            }
        twoSteps = STEPS * 2;
        homeListLength = llGetListLength(floatingLinkHomes);
        llSetTimerEvent(UPDATE_INTERVAL);
    }
    timer()
    {
        step = (step + 1) % twoSteps;
        integer zStep = step;
        if (step > STEPS)   // past halfway so moving downwards
            zStep = twoSteps - step;
        list parmList;
        integer homeListIdx = -2;
        while ((homeListIdx+=2) < homeListLength)
        {
            parmList += PRIM_LINK_TARGET;
            parmList += llList2Integer(floatingLinkHomes, homeListIdx);
            parmList += PRIM_POS_LOCAL;
            vector thisHome = llList2Vector(floatingLinkHomes, homeListIdx+1);
            parmList += <thisHome.x, thisHome.y, 
                fCos(thisHome.z, thisHome.z+MAX_Z_OFFSET, (float)zStep/(float)STEPS)>;
        }
        llSetLinkPrimitiveParamsFast(0, parmList);  
    }
}

The idea is that the prims that are to move up and down are all named "Candle", "Flame", or "Flower" but that can be changed with the list constant FLOATING_LINK_NAMES. It assumes that all those are supposed to move up and down in lockstep; if they're supposed to move as separate subassemblies: hire a scripter. If the Z orientation of the root prim isn't aligned with the world coordinate system: hire a scripter.

As I was writing this, I realized I probably should have just said "hire a scripter" to begin with, but maybe this is a place for them to start.

Anyway, assuming this is relevant to the desired effect, please toggle Develop / Show Info / Show Updates to Objects (Ctrl-Alt-Shift-U) and watch the blue boxes streaming up from the prims. Contrast that with the simple llTargetOmega() spin. This is why this effect is so expensive.

Incidentally, the update volume could be reduced by two-thirds by instead using a single mesh model that combines the flower and candle, with its origin at the point from which particles are to be emitted, axes oriented the same as the particle emitter prim you're using now.

The general rule there is that scripted objects should always be modeled to accept a script, not scripted to fit a model.