bigmoe Whitfield Posted January 7, 2019 Share Posted January 7, 2019 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 More sharing options...
Qie Niangao Posted January 7, 2019 Share Posted January 7, 2019 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.) 3 Link to comment Share on other sites More sharing options...
chibiusa Ling Posted January 7, 2019 Share Posted January 7, 2019 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"); } } } 1 Link to comment Share on other sites More sharing options...
KT Kingsley Posted January 7, 2019 Share Posted January 7, 2019 (edited) 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 January 7, 2019 by KT Kingsley 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 7, 2019 Share Posted January 7, 2019 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 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted January 7, 2019 Share Posted January 7, 2019 (edited) 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 January 7, 2019 by Rolig Loon 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
animats Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted January 8, 2019 Share Posted January 8, 2019 Sorry Steph .. then I must have misunderstood what you meant by occupant pads ... how does that work? 1 Link to comment Share on other sites More sharing options...
steph Arnott Posted January 8, 2019 Share Posted January 8, 2019 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. 1 Link to comment Share on other sites More sharing options...
bigmoe Whitfield Posted January 10, 2019 Author Share Posted January 10, 2019 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 More sharing options...
Recommended Posts
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