Light for objects in linkset

[ainst Composer]

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 April 4, 2019 by ainst Composer

[Rolig Loon]

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.

[ainst Composer]

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!

[steph Arnott]

//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);
        }
    }
}

 

[Wulfie Reanimator]

@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.

[Wandering Soulstar]

/me gets out the popcorn

[steph Arnott]

23 minutes ago, Wulfie Reanimator said:

@steph Arnott

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.

[Wulfie Reanimator]

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)

 

[steph Arnott]

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.

[Qie Niangao]

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.

[steph Arnott]

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;

 

[Wulfie Reanimator]

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."

[steph Arnott]

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 April 5, 2019 by steph Arnott

[Qie Niangao]

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.

[steph Arnott]

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 April 5, 2019 by steph Arnott