Profaitchikenz Haiku

And with Linux, you're the beta-tester. Remember that old tale about if Airlines were like Operating Systems? I have a machine running Windows 10 on 4GB Ram, it manages fairly well after a lot of tweaking, but an identical machine with Windows 7 uses less system resource doing the same thing. Initially I wasn't going to migrate any further machines from Windows 7 to 10 but having now measured what system resources things like malwareBytes will take up in order to give me a similar amount of security on Windows 7, I'd say that Windows 10 is looking like the lesser of two evils. For those diehards out there thinking "Ok, no problem, I'll stick to Windows 7 and compile one of the TPVs to run on it", don't forget that amongst the things for which support will be dropped are dotNet and Visual Studio...

I don't see anything in your proposal that would causer issues. The thing to be careful of is what the objects to be controlled are going to be doing, and here you might want to look through the rules about follower or capture prims. Having a hollowed hemisphere move wherever a certain avatar is detected so that they could not move freely outside the radius of the hemisphere would not be a good idea, as an example. It might be worth your looking at variable-rate timers, or timers triggered by certain events such as moving_start. It the object is just sitting there then checking it every second is just wasting time. If you have a list of things that you want to monitor such as movement, sitting-upon, being collided with, etc, then you could have a set of these events that all start the 1-second timer going only when monitoring is actually needed?

One of the prims that gets the link message can be told to chat it on a specific channel, and you can then have a listening script in another prim to receive the messages and send them to you via llOwnerSay, or else in the prim that can receive the link message, send them on via llOwnerSay, but be careful, RLV and possibly OpenCollar make use of llOwnerSay quite a bit and you might risk intefering with the flow of information

Sometimes simply orbiting your camera view around the head will do the trick.

I just repeated the test but now using collision events, and only the last detected position I was at was chatted out, so collisions store none or one, and it's always the last one. I've realised that the sequence of the touch events being stored can be quite useful. Imagine you have a number pad and you tap away at the numeric keys, then realise this thing isn't responding, and you tap a cancel key. When it does come back to life, it will record the first of many keys, but also the last, which you can test for, and if it's cancel, take appropriate action, but it does mean shifting the touch processing out into a function instead of within the event.

Confirmed. I created a cube and had a 10-second sleep in State_entry, then added touch_start, touch and touch_end blocks, within each of those I chatted out the face that had been touched. Reset the script and touched a sequence of three faces. The resulting chat showed that Touch_start chatted back the first face I had touched Touch_end chatted back the last face I had touched Touch also chatted back the last face. I tried different sequences of faces just in case the face number dictated the ordering, but the results above were consistent.

Thanks both Fenix and Wlfie, and I have a feeling Rider's work on event-ordering last year might have some bearing on this? Just thinking, touch can have also a touch_start and touch_end, would it distinguish those as well?

Now I've seen the OP's code, I can see no other reason for the extension of the light other than chat messages passed to a script that is sleeping DO get queued and the waking script then DOES get the events that occurred whilst it was supposedly unresponsive: I think this needs further testing. I'll bash a few prims together tomorrow and report back.

// Light script vector LIGHT_COLOR = < 1.0, 1.0, 1.0 > ; // Light color lsl RGB integer LIGHT_PRIM = 0; // Light prim number or LINK_THIS integer LIGHT_FACE = ALL_SIDES; // Light face number or ALL_SIDES integer lightOn = 0; default { state_entry() { llListen(-1234567, "", "", ""); /* Listen to anybody saying anything on channel -1234567 */ } listen(integer channel, string name, key id, string msg) { if (msg == "light_on") /* That is, if the message was light_on */ { if( lightOn == 0) { // On llSetLinkPrimitiveParamsFast(LIGHT_PRIM, [PRIM_GLOW, LIGHT_FACE, 1, PRIM_POINT_LIGHT, TRUE, LIGHT_COLOR , 1.0 , 10.0 , 0.2 ]); lightOn = 1; // llSleep(5); // Off Timer llSetTimerEvent(5.0); } } } timer() { llSetTimerEvent(0.0); // stop any repeating llSetLinkPrimitiveParamsFast(LIGHT_PRIM, [PRIM_GLOW, ALL_SIDES, FALSE, PRIM_POINT_LIGHT, FALSE, ZERO_VECTOR , 0.0 , 0.0 , 0 ]); lightOn = 0; } } Try that, you might have to check brace-matching, I didn't get a chance to try it inworld

This cropped up in another thread, I think it was decided that events arriving when a script was sleeping just got quietly dropped?

If you use llSleep() then nothing else can happen during that sleep period. A better approach is to use a timer and set it to perhaps 5 seconds. For what you are asking, the fix is quite easy. In the script that gets the message, create a global integer called light. When you turn the light on, set it to 1, when you turn the light off, set it to 0. The test to make when you get the message to turn the light on is to see if the value of this variable is 0, and if so, turn the light on, set the value to now be 1, and set a timer event to go in 5 seconds. When the timer event occurs, set the timer event to 0.0. turn off the light, and set the variable to 0, so that the next message turns it back on. integer lightOn = 0; /// stuff here for state_entry and so on if ( msg == "light on") { if ( light == 0) { // turn light on lightOn = 1; llSetTimerEvent(5.0); } } timer() { llSetTimerEvent(0.0) // turn light off lightOn = 0; } Warning, untested snippet,

The explanation given at the server user group meeting on the script issue was that it was a one off, the code is fine, it was a change in the startup procedure they use.

Probably because of the script-saving issue. My home region has just begun a third restart, although that might be the region owner restarting yet again with poor performance issues.

Can you confirm that in addition to the two above versions, there are restarts on versions 533447? I've seen restarts on two 533447 regions but none on the 533895 I know of.

I've checked two places running 533447 and although I'm not crashing it's not possible to save scripts, as per the grid status tweet a couple of hours ago. I tried a parcel on 533895 and it saved as expected, but I don't think it has had a restart today, the other two places did have restarts.

Also look in Help - bumps and pushes and see if you're being swept across the place by an invisible prim.

None of the regions have gone there yet. I'd suggest opening a ticket with LL, they are best placed to look into this. It's not easy doing diagnostics with anything less than the estate console, and even then, if the problem isn't your region but another one that happens to be on the same server, you wouldn't be able to find it.

This might be in the same category that we've segued to at the tail end of a scripting thread about functions jumping about, I experience a similarly aperiodic loss of and sudden regaining of touch-actions on a parcel monitor. It doesn't work as anticipated and then after some time, all the actions from the repeated clicks pop up in a rush. It's not demonstrable so I can't file a Jira or even do any sensible testing on it. It's on the top of my keep-an-eye-on-it list right now. All I can suggest is keep recording each incident, what didn't happen, what then did happen, what other things you might have done that released the floodgates. After a while something might just emerge.

Have a look at llSensor in the LSL portal wiki, and also look at no_sensor, because that is going to be how you drop back to idle mode, when there's nobody near. llSensor will give you a count of how many avatars it has found within the range. You step through a for loop 0 to num_detected - 1, and do some checking on each avatar that is found. llDetectedPos(index) will give you the place where that avatar is, so llVecDist(llDetectedPos(index). myPos) will then tell you how far away they are. myPos is going to be where you are as given by llGetPos(), but as you aren't going to be moving around much it makes sense to only read this once, say inside the llSensor event (you might end up getting bumped around a bit during your adventures so it makes sense to regularly refresh it, just not every iteration through the loop) And I bet Molly has just said everything I'm saying only better

But my region is a 99.99% scripts run, and if there's another 3 avatars on the rest of the place I start to feel crowded ... It does get the event because as I mentioned, they suddenly all arrive once I do manage to get a dialog working. The implication then is that once 64 have been queued, new ones get dropped, it's not going to scrap old ones in favour of fresh? Sounds like vulture-scheduling to me, it prefers the dead...

Ah, good point, I use Opera, I'd better see if others show similar behaviour.

I'm not worried about recursion, although the industries I worked in prohibited them or any other coding technique that could not be predicted, it was the realisation that giving a user-defined function a long and complicated task would effectively freeze all other events, it's the equivalent to having no interrupts whatever in a PLC, there's no way to force it back to a responsive state except for the reset method. In practice then, should a script go into a non-responsive state, the events for it will begin to pile up and probably get discarded on a first-in first-overboard protocol. What has piqued my curiousity here is something I've been trying to investigate for several weeks, it's a non-repeatable problem that nevertheless occurs several times a week: at login, I make my way to a parcel monitor and touch it, expecting a dialog to pop up. Usually it does, but sometimes no dialog pops up. I touch the prim a couple more times in case I missed it, but no dialog. I then do things such as click on a door to make sure touch itself is working, then touch something like the train, and almost always get a dialog. I clear this away, and there on the screen behind it are all the queued dialogs that should have been presented to me when I first clicked the monitor. I can't produce this on demand, and once cleared, it behaves as normal, so I can't log in on a different viewer to see if this is a bit of TPV-misbehaviour or what. I suspect it's a touch event issue, something has convinced the script that it's too busy to respond to the touch immediately. It does have global functions, but no states, and no recursion, and the lines I added to monitor free memory show there's loss of free memory.

I hope that there aren't regions slowly grinding to a halt because we're experimenting with recursion, stack-heap collisions, infinite loops, and state-changing in global functions.

Thankyou both Qie and Wulfie. So recursive functions will also risk either a stack-heap collision or else lock the script from handling anything else.

I've also noticed strike-through isn't there when I edit a post I've already made, only when I'm making a new post? ETA just edited this to confirm, It's odd, I would have thought that strike-through was essential when editing a post but superfluous when creating one.