Jump to content

Recommended Posts

Posted (edited)

Hello! need a script for linkset of several objects, allowing one object to emit light and turn off for the rest in a circular chain. I managed to add a light to all objects but I can’t turn of for the rest. What is the way to do this?

Edited by ainst Composer

Share this post


Link to post
Share on other sites

Do it in two steps:

1. Turn OFF all lights.

2. Turn ON the one light that you want lit at the moment.

Not only is that logical, it's also most efficient.  It guarantees that the only light that will be on is the one that you want, without needing to address each of the others individually.

  • Thanks 1

Share this post


Link to post
Share on other sites
2 minutes ago, Rolig Loon said:

Do it in two steps:

1. Turn OFF all lights.

2. Turn ON the one light that you want lit at the moment.

Not only is that logical, it's also most efficient.  It guarantees that the only light that will be on is the one that you want, without needing to address each of the others individually.

You're genious, Rolig! Thank's a lot!

Share this post


Link to post
Share on other sites
//this is a crude example of storing the link numbers for data usage
integer gFace = ALL_SIDES;
list primData = [];

Data(string name)
{
	integer l = llGetNumberOfPrims();
	integer i = 1;
	for(; i<=l;i++)
	{
		name = llGetLinkName(i);
		if( name == "two" )
		{
			if (llListFindList(primData,[name]) == -1)
				primData = [ name, i ] + primData;
		}
	}
}

default
{
	state_entry()
	{
		//
		//
	}
	on_rez(integer start_param)
	{
		primData = [];
		Data("two");
		primData = llListSort(primData, 2, TRUE);
		llOwnerSay( llList2CSV(primData) );

	}
	 changed(integer ch)
    {
        if(ch&CHANGED_OWNER)
            llResetScript();
        else if(ch&CHANGED_LINK)
        {
            primData = [];
            Data("two");
            primData = llListSort(primData, 2, TRUE);
        }
    }
}

 

Share this post


Link to post
Share on other sites

@steph Arnott Your function doesn't work. I'm posting from my phone so I can't format properly, but here goes:

17 hours ago, steph Arnott said:

Data(string name)

name = llGetLinkName(i);
If( name == "two" )

Your function overwrites the input parameter, and doesn't use the input parameter in the way you intended it to be used. If you try to find a link named "one" but there is another link with a different name, you will change "one" to another name. Even if you fixed that, the if-check becomes 'if( "one" == "two")' which obviously still doesn't pass.

I also really enjoy the irony of someone who has sn unhealthy obsession with efficient memory usage to be adding things to a list like this:

17 hours ago, steph Arnott said:

primData = [ name, i ] + primData;

While this is a completely valid way to preprend things to a list, you later sort this list after the function has finished. You are objectively spending memory with no purpose or benefit.

  • Haha 1

Share this post


Link to post
Share on other sites
23 minutes ago, Wulfie Reanimator said:

It was written that way on purpose. The word 'crude' was explicit and intended to get the person to study it, understand it and write it better rather than keep getting others to write their entire projects. So far the OP has done nothing except ask/demand  As for for not working, it outputs the name of prim and its number if you simply addd a touch call. And to be clear because you appear to want to preen your feathers i would not use a clearly obvious kludge.

Share this post


Link to post
Share on other sites

I can keep going.

18 hours ago, steph Arnott said:

if (llListFindList(primData,[name]) == -1)

This one line has two problems, one of them I already covered, but I'll clarify.

Most importantly, nothing is added to primData unless this check passes. The issue is that primData starts empty. This if-check will always be false.

And again, it is more memory efficient to use typecast than constructing a new list. What I mean:

1 hour ago, Wulfie Reanimator said:

if (llListFindList(primData,(list)name) == -1)

 

Share this post


Link to post
Share on other sites
Just now, Wulfie Reanimator said:

I can keep going.

This one line has two problems, one of them I already covered, but I'll clarify.

Most importantly, nothing is added to primData unless this check passes. The issue is that primData starts empty. This if-check will always be false.

And again, it is more memory efficient to use typecast than constructing a new list. What I mean:

 

I already know that. It was written that way deliberatly.

Share this post


Link to post
Share on other sites

Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code?

I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here.

  • Like 1

Share this post


Link to post
Share on other sites
12 minutes ago, Qie Niangao said:

Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code?

I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here.

The point was that it was meant to be bad. A baseline understanding would have changed it to a simple list load and index find.

    integer i;
	for(i=1;i<=llGetNumberOfPrims();++i)
	{
		primNames += [llGetLinkName(i)];
	}
 
                                        
   integer LnkIndex = llListFindList(primnames, [the_prim name i want]) + 1;

 

Share this post


Link to post
Share on other sites
50 minutes ago, Qie Niangao said:

Well, whatever you two both seem to know is news to me. Is there really some penalty (runtime allocation, or even just bytecode size) to prepending to a list, as opposed to appending? And is there really a difference between typecasting a list and explicitly creating the list in the code?

I tried these things with some simplistic llGetFreeMemory() testing and couldn't find any consistent pattern one way or another. I could certainly refine the measurements with script profiling, but maybe I'm just not quite understanding what everybody else seems to know here.

From http://wiki.secondlife.com/wiki/Typecast

"For casting a variable myVar to a single-item list, the syntax (list)myVar is about 30% more efficient under LSL Mono than the syntax [myVar]. The same (list)myVar syntax is also slightly more efficient under LSL-LSO."

  • Thanks 1

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Wulfie Reanimator said:

From http://wiki.secondlife.com/wiki/Typecast

"For casting a variable myVar to a single-item list, the syntax (list)myVar is about 30% more efficient under LSL Mono than the syntax [myVar]. The same (list)myVar syntax is also slightly more efficient under LSL-LSO."

30% more efficient to what? Even Linden can not explicitly determine what code is and is not more efficient unles it is grossly bad because each server is different. This is an example of fixed laboratory condition data as opposed to actual reality. It is nonsense.

Edited by steph Arnott

Share this post


Link to post
Share on other sites

Well, I think I understand what's being compared, but I sure can't find an efficiency difference -- neither in execution time nor in allocated memory use. It's true that my tests produce a range of results for each test case, so it's not the purest laboratory conditions, but I come from a social science background so I'm not scared of an error term.

Anyway, call me skeptical of a 30% efficiency advantage here -- frankly I doubt there's any difference at all. It's the most recent update to that Typecast wiki page, made in November 2018. I wonder if there was some special condition that produced that result.

Share this post


Link to post
Share on other sites
Posted (edited)
29 minutes ago, Qie Niangao said:

Well, I think I understand what's being compared, but I sure can't find an efficiency difference -- neither in execution time nor in allocated memory use. It's true that my tests produce a range of results for each test case, so it's not the purest laboratory conditions, but I come from a social science background so I'm not scared of an error term.

Anyway, call me skeptical of a 30% efficiency advantage here -- frankly I doubt there's any difference at all. It's the most recent update to that Typecast wiki page, made in November 2018. I wonder if there was some special condition that produced that result.

If it works that is all that i care about. Personally Lua makes LSL  look pathetic.

Edited by steph Arnott

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...