Jump to content

Sensor Lighting


bigmoe Whitfield
 Share

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

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

Recommended Posts

What do I have wrong here, I'm trying to do an auto light that people trigger going to the lift and once they leave it turns back off, I 
using volume detect but while that kinda worked, I have no idea how to make it turn back off lol.  

Any ideas?

integer isLightTurnedOn;

default
{
    state_entry()
    {
        llSensor("", NULL_KEY, AGENT, 2.0, PI);
    }
 
    sensor( integer detected )
    {

{
//      toggle isLightTurnedOn between TRUE and FALSE
        isLightTurnedOn = !isLightTurnedOn;
 
        if (isLightTurnedOn)
        {
            llSetPrimitiveParams([
                //PRIM_FULLBRIGHT, ALL_SIDES, FALSE,
                PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 1.0, 5.0, 0.6]);
        }
        else
        {
            vector COLOR_WHITE  = <1.000, 1.000, 1.000>;
 
            llSetPrimitiveParams([
               // PRIM_FULLBRIGHT, ALL_SIDES, TRUE,
                PRIM_POINT_LIGHT, TRUE, COLOR_WHITE, 1.0, 5.0, 0.6]);
        }
    }
}

Link to comment
Share on other sites

I like the volume detect collision-based approach better, but if you're using a sensor, won't you want llSensorRepeat and a no_sensor event to detect when to turn it off? (You could certainly trigger it by some other event, too... like some interval after the lift reaches destination and opens its doors, or whatever... or track the sensor-detected rider through OBJECT_LOCATION... etc., etc., but you're already using sensor events for the initial detection.)

  • Like 3
Link to comment
Share on other sites

4 hours ago, bigmoe Whitfield said:

etc..

If your looking for a sensor only option you could do it like this :

integer isLightTurnedOn=0;

default
{
    state_entry()
    {
        llSensorRepeat("", NULL_KEY, AGENT, 3.0, PI, 2.0);
    }
    no_sensor(){
        if(isLightTurnedOn){
            llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 1.0, 5.0, 0.6]);
            isLightTurnedOn=0;
            //llOwnerSay("Light is off");
        }
    }
    sensor(integer num){
        if(!isLightTurnedOn){
            vector COLOR_WHITE  = <1.000, 1.000, 1.000>;
            llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, COLOR_WHITE, 1.0, 5.0, 0.6]);
            isLightTurnedOn=1;
            //llOwnerSay("Light is on");
        }
    }
}

The only downside is to be effective you would need to run the sensor at very short intervals to ensure the light switched on fairly shortly after the avatar entered the lift. I think volume detect would be less impact on sim resources and probably a better option. Doing something like this worked perfectly for me every time I tested it 

integer isLightTurnedOn=0;

default
{
    state_entry()
    {
        llVolumeDetect(TRUE);
    }
    collision_start(integer x){
        if(!isLightTurnedOn){
            vector COLOR_WHITE  = <1.000, 1.000, 1.000>;
            llSetPrimitiveParams([PRIM_POINT_LIGHT, TRUE, COLOR_WHITE, 1.0, 5.0, 0.6]);
            isLightTurnedOn=1;
            //llOwnerSay("Light is on");
        }
    }
    collision_end(integer x){
        if(isLightTurnedOn){
            llSetPrimitiveParams([PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR, 1.0, 5.0, 0.6]);
            isLightTurnedOn=0;
            //llOwnerSay("Light is off");
        }
    }
}

 

 

  • Like 1
Link to comment
Share on other sites

If the lift accommodates more than one person turning the light off in the collision_end event risks leaving additional passengers in the dark. (I think you get a collision_end for each individual collider. I could be wrong, though.)

Edited by KT Kingsley
  • Like 1
Link to comment
Share on other sites

17 minutes ago, KT Kingsley said:

If the lift accommodates more than one person turning the light off in the collision_end event risks leaving additional passengers in the dark. (I think you get a collision_end for each individual collider. I could be wrong, though.)

If it is a lift the light could be simply turned on at arrival and turned off after a min at exit arival

  • Like 1
Link to comment
Share on other sites

timer()
{
    llSensor("","",AGENT,3.0,PI);
}

sensor (integer num)
{
    // Turn light on
    llSetTimerEvent(2.0);
}

no_sensor()
{
    llSetTimerEvent(15.0);
    // Turn light off
}

collision_start(integer num)
{
    llSetTimerEvent(2.0);
}

 

Edited by Rolig Loon
  • Like 1
Link to comment
Share on other sites

I had this same requirement in the elevator scripts I wrote recently. The posted solution in the Library worked somewhat, but I updated and should as well update there but ...

  • I have single prims that are in the space the elevator occupies at the top and bottom (only a one stop elevator). This has llVolumeDetect set TRUE. When it gets a collision it sends a message to the Main script (which controls the lights).
  • The Main on being advised of the collision sends a message to a separate Sensor script (same prim as Main), and turns on the lights (if not already on).
  • The Sensor then sets a llSensorRepeat to check every second (if not already on).
  • As long as it detects anyone it lets the Main know how many. If it gets a no_sensor event it turns off the sensor and advises Main that no one is there.
  • When the Main is advised that no one is there, it turns off the lights.
  • Like 1
Link to comment
Share on other sites

How reliable is that?

There's no "collision" event with llVolumeDetect. Just collision_start and collision_end. If you save the key of anything seen at collision_start, and remove it at collision_end, is that reliable? Or do events get lost?

I bought a scripted door that uses llVolumeDetect. It detects objects entering the volume fine, but is not very good about deciding when nobody is in the door area. It seems to be collision_start plus a timer.

  • Like 1
Link to comment
Share on other sites

6 minutes ago, animats said:

How reliable is that?

There's no "collision" event with llVolumeDetect. Just collision_start and collision_end. If you save the key of anything seen at collision_start, and remove it at collision_end, is that reliable? Or do events get lost?

I bought a scripted door that uses llVolumeDetect. It detects objects entering the volume fine, but is not very good about deciding when nobody is in the door area. It seems to be collision_start plus a timer.

I really do not understad why you are making something so simple so complicated. Call the lift, if it already in place tell it to turn the light on. If it not then trigger at move end. If the floor triggers detect a no volume detect turn the light off. There are several ways to acheive the results other than having to scan constantly which is totally pointless. Scanners are not intended for doors etc.

  • Like 1
Link to comment
Share on other sites

1 hour ago, steph Arnott said:

I really do not understad why you are making something so simple so complicated.

Probably because there are so many ways to do the simple things, and it's hard to find a rule that says one way is always better than another.

1 hour ago, steph Arnott said:

Scanners are not intended for doors etc.

True.  Scanners are intended for scanning.  We can use them in anything we wish.  The silly little script I posted above uses a sensor.  It's very simple.  It's not necessarily the best solution for this application, but it will certainly work and is essentially foolproof. 

Your choice of how to script something like the OP's challenge depends on personal experience.  I tend to distrust collision_end events. They often give me false results, so I end up needing to add reality checks to be sure that they aren't lying.  In my experience, sensors tend to be more reliable, so I probably use them more often than you do.

  • Like 1
Link to comment
Share on other sites

1 minute ago, Rolig Loon said:

Probably because there are so many ways to do the simple things, and it's hard to find a rule that says one way is always better than another.

True.  Scanners are intended for scanning.  We can use them in anything we wish.  The silly little script I posted above uses a sensor.  It's very simple.  It's not necessarily the best solution for this application, but it will certainly work and is essentially foolproof. 

Your choice of how to script something like the OP's challenge depends on personal experience.  I tend to distrust collision_end events. They often give me false results, so I end up needing to add reality checks to be sure that they aren't lying.  In my experience, sensors tend to be more reliable, so I probably use them more often than you do.

True, but i have recently had to sort an RP sim out for lag' Every damned door, which 90% were only used once in week if not at all had a scanner running 24/7. Personally i do not use a collision event in lifts. The floor has agent locking pads. Each one registers an active lock.

  • Like 1
Link to comment
Share on other sites

3 hours ago, animats said:

How reliable is that?

There's no "collision" event with llVolumeDetect. Just collision_start and collision_end. If you save the key of anything seen at collision_start, and remove it at collision_end, is that reliable? Or do events get lost?

I bought a scripted door that uses llVolumeDetect. It detects objects entering the volume fine, but is not very good about deciding when nobody is in the door area. It seems to be collision_start plus a timer. 

That is why I used the collision_start as simply the catalyst to start the sensor. It is the sensor that tracks who is in the space of the lift, not the collision events. There area lot of other problems with the start/end events and situations where they do not fire, making them unreliable (in my view) for tracking how many people were in the lift.

  • Like 1
Link to comment
Share on other sites

3 minutes ago, Wandering Soulstar said:

That is why I used the collision_start as simply the catalyst to start the sensor. It is the sensor that tracks who is in the space of the lift, not the collision events. There area lot of other problems with the start/end events and situations where they do not fire, making them unreliable (in my view) for tracking how many people were in the lift.

Usual method is occupant pads. Each registers the occupation as a pose value. When all at zero the lift is empty.

  • Like 1
Link to comment
Share on other sites

18 minutes ago, steph Arnott said:

Usual method is occupant pads. Each registers the occupation as a pose value. When all at zero the lift is empty. 

That works if you only want to turn on/off the lights when an AV 'sits'/'unsits' but does not if you want to set the lights, or other things, based on them being in the space of the elevator. Closing doors for example when the elevator is empty.

  • Like 1
Link to comment
Share on other sites

1 minute ago, Wandering Soulstar said:

That works if you only want to turn on/off the lights when an AV 'sits'/'unsits' but does not if you want to set the lights, or other things, based on them being in the space of the elevator. Closing doors for example when the elevator is empty.

Does not.

  • Like 1
Link to comment
Share on other sites

10 minutes ago, Wandering Soulstar said:

Sorry Steph .. then I must have misunderstood what you meant by occupant pads ... how does that work?

Look there are several ways to do this. First if it an enclosed lift then leave the light on permanently. Second, if a glass lift set the light level to sim day/night. Thirdly, turn light on when called and a min after the pose pads are vacated.

  • Like 1
Link to comment
Share on other sites

Thank you, thank you,  I now have a working non sensor based setup and a sensor based setup working fully,  one at ground level for the sensor,  the upper is using the collision event,  found out the light was not happy with avatars near it.    but this has been a learning experience and thank you for all of your great insight!

Link to comment
Share on other sites

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...