Jump to content

Singular Scripted Child Prims -> LlSetLinkPrimitiveParamsFast = Feasible?


Tommy Rampal
 Share

You are about to reply to a thread that has been inactive for 4140 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

So to my understanding (I don't keep up to date with LSL changes as I should), this is to replace the scripting practices of those who put singular link_message scripts in child prims to save up on sim resources.

My case is a little different, I use this method to work with quite an advanced prim based GUI (around 38 prims) where it sends out unique commands to child prims depending on which prim was touched; each prim reacting/changing differently to each command (e.g. a prim turns into a button, then into text, or hides if it is not needed).

Now I was thinking, I could just recursively use LlSetLinkPrimitiveParamsFast's for each prim - but not only would that make the GUI change in a very transitioned manner, like you'd see a flood of chat text (compared to all changing at the same time); it would also drain the main script memory, which could be used for other things.

Has anyone got any ideas of how I can work around this? Or should I not worry and carry on as usual?

Link to comment
Share on other sites

It probably wouldn't be too noticable, I think.

One thing though is that... you could probably cut down on those 38 prims by using various functions like llDetectedTouchST, llDetectedTouchFace, llSetTextureAnim, llSetLinkTextureAnim, llSetLinkPrimitiveParamsFast, and clever texturing.

 

Anyway, it probably be too noticable, especially if you're using Mono which would run quite a bit faster.

I did a quick test and mono can run this line:

            llSetLinkPrimitiveParamsFast(LINK_THIS,[PRIM_TEXT,"TESTETSET",<llFrand(1.0),0.0,0.0>,1.0]);

about 1,000 times per second.

Link to comment
Share on other sites

I have a hud with slider controls too.  Needs 1 prim per slider, but all controlled from the root.

To handle anything that requires a script in the child,  I create the  child prims with a PIN, and then load the script into them via llRemoteLoadScriptPIN when it is needed.   So far, I have only needed to do this to make formerly-child prims delete themselves after being unlinked.

 

Link to comment
Share on other sites

You are correct that linkset changes are not allowed while an object is attached.

I defer those changes until the HUD is dropped on the ground.

That hud has a configuration slider for the number of marker prims.   Any change to that parameter causes it to request permission to change the linkset, if it does not already have that permission,  then it checks the land permissions and either instructs the user to drop the HUD, or instructs the user to drop the HUD when he arrives on land where he has rez permission.

When the HUD has been dropped, it does whatever prim creation and deletion and linkset changes are needed, then reattaches automatically.

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4140 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...