Jump to content

Light for objects in linkset


ainst Composer
 Share

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

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

Recommended Posts

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
Link to comment
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
Link to comment
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!

Link to comment
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);
        }
    }
}

 

Link to comment
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
Link to comment
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.

Link to comment
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)

 

Link to comment
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.

Link to comment
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
Link to comment
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;

 

Link to comment
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
Link to comment
Share on other sites

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
Link to comment
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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 924 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...