test whether an object is a light source

Hello

I have a question

in the llgetprimitiveparams example page there is an example of using it to determine if an object is a light source

http://wiki.secondlife.com/wiki/LlGetPrimitiveParams

but as far as I understand this function can only be used to get the current object's properties

I need to make a sensor that detects light sources
I want to ask how can I find out if an object detected by this sensor is a light source


sensor(integer total_number)
{

for (agentNum=0; agentNum<total_number; agentNum++)
{
llDetectedKey(agentNum);

}
}

thank you in advance

If that was allowed, you'd be able to go around copying everyone's light on/off setting. It's a slippery slope and before long people would want the ability to find out what color it was. (It's not allowed)

most prim properties in other prims are not available from basic functions for the exact reason that design implementation is a trade secret, to allow creators some amount of control of their products.

for this reason ll does not directly provide any means to discover these settings so that content creators can remain secure in their intellectual property rights.

I have to do a project for school(college) for a robotics class
I have to make a robot an arena and make the robot navigate that arena(avoiding other objects) whilst following a light source.
Is there any other way I could do this?

thanks in advance

Make the bot follow the light source, not the light itself. That is, if you set up the arena, and so on, you can script the light source to also do other things, or be named a specific thing, etc, and have the bot follow that, rather than following the actual visible light.

Does it really have to be a 'light source' or is that just a convenient stimulus?

/me would try to figure out the properties of what it's tracking and fake it some other way. Like, if a laser is what the project calls for, something like llSensor on the named 'light' object might work. For something like, say, an area light, you'd probably have to be more clever and do something that allows for the bot to figure out if it's getting closer to the 'light' as it moves around..

well I am doing llSensor and getting all objects that have the word "light" in their description now ... like a workaround
hope this is ok ... the guy specifically said I cannot hardcode the object's key into the script ...

any idea how I can make my robot avoid objects? I am finding this to be really difficult

thanks again

Keywords..

sensor
- focus a sensor forward.
bounding box
- determine the size of the prim in front of you.

And yes, this is going to be EXTREMELY complicated, especially with the relatively tiny maximum script size/memory. This is why most autonomous stuff in SL just walks around randomly and bumps into stuff, or homes in on people / other objects.

Another approach could be to use collission detection and/or volume detection.. and adding a larger invisible prim around the bot, so it can "hit" the objects without appearing to hit them.

Or you could have the robot "rez" a sensor bullet. the bullet would be the size of the robot, and would travel forward. If it hit an object it could report back, and then the bot could stop, rotate, and fire again. Sortof like sonar.

Who is telling you to do this? and more to the point, why are they telling you to do it in SL?

the teacher is telling me to do this ...
why I don't know but I cannot question his authority
if I don't do this I don't pass
don't get my degree
and pay a fine

I want to avoid all those things

are there no examples of objects avoiding other objects?
I am really lost

P.S. I am using the bounding box but I cannot figure out how to navigate around the object
Please if you have any ideas and especially code that might help me out it would mean a lot to me. Thank you in advance

I hate to harsh on you here.. but we're not actually here to do your homework for you.

Perhaps you should go back to the original assignment, and rethink your approach. Make sure you know the minimum requirements, and start solving those. Maybe Second Life is the wrong way to complete this assignment.

You say that you need to follow a light. We've pointed out that lsl can't do that.
We've suggested you make a prim called "a light" and follow that using a sensor to find it. You mention that you can't hardcode the uuid.

You know that it has to avoid obstacles. We've explained 3 different ways in which you could detect obstacles. You mention that you can't understand how to avoid them.

How much of your homework are you going to be doing exactly?

Your homework isn't about the technical skill needed to assemble the script, the assignment is about your process of problem solving, and how you decide to build an automated process to express your solution to the problem presented. It's not just about putting together a script that compiles.. it's about how you got there.

Except we seem to be doing all the solving FOR you.

If you can't solve your homework without us doing it for you, maybe.. just maybe, you're taking the wrong classes.

you could look at this, I have no idea if it's useful to you or not though

/54/f3/275057/1.html

this might help also for pathfinding
https://wiki.secondlife.com/wiki/Basic_A-Star_Pathfinder

Hardcoding keys isn't a good idea, because they change every time something's rezzed. So I can see why he didn't want you to do that.

Does he, though, have any objection to your storing the key as a variable? You could, for example, have the follower discover its target's key in the first place by telling the follower to listen on a specific channel for objects belonging to its owner and have the listener shut down after it's received a message from the target. It then grabs the target's key (target = id; in the listen event) and uses http://wiki.secondlife.com/wiki/LlGetObjectDetails in a timer to check on the target's position, sort of like this:

	
    timer()
 	{
 		vector pos = llList2Vector(llGetObjectDetails(target,[OBJECT_POS]),0);
 		vector offset =<-1,0,0>;
 		pos+=offset;
 		llMoveToTarget(pos,.3);		
 	}
 	

As to collision avoidance (/me would be tempted to cheat and make the thing phantom.. "....but you didn't say how I should avoid collisions, Professor!" and for several interesting scripts, you might take a look at http://www.lslwiki.net/lslwiki/wakka.php?wakka=TutorialRobotics as well as the other references.

Hope this helps.

My sister had a test in psych class, it was simple, everone was givven a rubics cube that was scrambled, the first 10 to solve it were given A's, the rest b's if they solved it, and C's otherwise.

My sisters immediately popped it apart and put it back together in order and handed it in. she and 3 others (that were inspired to do that after seeing her do it) got A's.

moral of the story? if you follow the rules as layed out, unique if different solutions are still valid. (although phantom may arguably not be a method of avoidance of obstacles, so you'd better be sure, because and F for failure to adhere to instructions is a long ways from an A for ingenuity)

Ripping all the stickers off is a solution too.

I have a question.. what part of your homework allows you to come to the forums and ask us to solve it for you?

... but libSL does!

and there is a reason I said "directly" =P

I don't understand ...
make the robot phantom? how will that help?
won't that just make it go throught walls?
it does that now withouth being phantom if I don't make it physical
can you please explain
thanks

If something's phantom it doesn't, as far as I know, cause any collision events (other, it would seem from the wiki, ground collisions).

So it rather depends on how your lecturer is defining a collision.

If the test is that your object should be able to navigate an obstacle course by moving round obstacles rather than through them, making the object phantom won't, of course, help.

However, if the test is just that your object should be able to navigate an obstacle course without triggering any collision events, then making it phantom would do the trick. Try putting

 collision_start(integer total_number)  {
        		llOwnerSay(llDetectedName(0)+" collided with me");
        	} 

in your obstacles and

 collision_start(integer total_number){
        		llOwnerSay("I collided with "+ llDetectedName(0));
        	}

in your light-seeking object; if you make the object phantom it should negotiate the course by passing through everything but without triggering either of these. This will work even if the object is physical, but if you do that, please remember to use llSetBuoyancy( ) to avoid the risk of it falling through the floor when it's not actually aquired its target.

Though, as Void suggested, do double-check what the lecturer's instructions actually say!

this is what is required
there was never any question about this but maybe I didn't express this clearly and this lead to a confusion, sorry

so the robot must navigate an arena until in reaches the light and go around anything else
currently when my robot bumps into a wall it keeps bumping into it and doesn't go around this is the problem ... I tryed making it go around the objects it collides with
within the collision_start even but still it doesn't work ... I don't know why

does MoveToTarget not work within collision_start?
oooops never mind it works ... my bad

The real problem is knowing wich side of a colided item I am coliding with

Are you allowed to make it remote-controlled?

nope

Para,

It is going to be much easier to help if you keep all of your questions confined to one thread instead of starting multiple threads. This gives everyone the correct context for the question and lets us know what has already been tried and suggested.

Are you allowed to script the barrier objects?

ok, sorry
I just thought this thread was about detecting light sources at first so that is why I asked about collision in the other thread