LogOut/Region Change - Events in scripts

[Wandering Soulstar]

Hi All,

99% sure I know the answer already, but thought I'd check. From code in a HUD we can identify when an AV (and thus the HUD and script) changes regions, when they log-in, and when they attach/remove the HUD .. but from the code in the HUD:

• We cannot tell when the user logs out
• We only know about the region change when we arrive in the new region, nothing about us leaving the previous region

From everything I have read in the wiki the above two limitations hold true. My question is, am I missing something somewhere that would allow my code (in the HUD) to identify these two events?

[LissomePrey]

As a relative amateur I await a response form someone more experienced but

• Log-out I understand can't be detected, I use heartbeat scripts to show continuing presence
• Change of region surely doesn't happen till you arrive as if the teleport fails for any reason you'll still be in the old region.

Edited February 20, 2019 by LissomePrey
typing even worse than usual today

[steph Arnott]

4 hours ago, Wandering Soulstar said:

Hi All,

99% sure I know the answer already, but thought I'd check. From code in a HUD we can identify when an AV (and thus the HUD and script) changes regions, when they log-in, and when they attach/remove the HUD .. but from the code in the HUD:

• We cannot tell when the user logs out
• We only know about the region change when we arrive in the new region, nothing about us leaving the previous region

From everything I have read in the wiki the above two limitations hold true. My question is, am I missing something somewhere that would allow my code (in the HUD) to identify these two events?

Could use a timed ping back so if no ping the agent has left.

[Wandering Soulstar]

2 minutes ago, steph Arnott said:

Could use a timed ping back so if no ping the agent has left

I did think about that .. the problem though is twofold:

• The scripts in the HUD would not know that the user has logged out as they 'disappear' so could not do their internal clean up
• The worker scripts that would also need to do cleanup could be very numerous and having 100+ timers running constantly would not be a good use of system resources

[steph Arnott]

Just now, Wandering Soulstar said:

I did think about that .. the problem though is twofold:

• The scripts in the HUD would not know that the user has logged out as they 'disappear' so could not do their internal clean up
• The worker scripts that would also need to do cleanup could be very numerous and having 100+ timers running constantly would not be a good use of system resources

I was thinking that the agent script outputed a timed key message every five or ten mins. If the main does not recieve it then it does its thing. Was just a thought.

[Qie Niangao]

1 minute ago, Wandering Soulstar said:

I did think about that .. the problem though is twofold:

• The scripts in the HUD would not know that the user has logged out as they 'disappear' so could not do their internal clean up
• The worker scripts that would also need to do cleanup could be very numerous and having 100+ timers running constantly would not be a good use of system resources

This is confusing. Can you explain what sort of cleanup you have in mind, or otherwise why you want these events? I mean, there's no HUD scripts to run after the user has logged out -- there's literally no there there. So, whatever it's supposed to be doing, "code (in the HUD)" simply doesn't exist to do it until the next login rezzes the HUD again.

If instead you're wanting scripts on the simulation outside the HUD to do cleanup when the avatar disappears, the standard approach is to poll llGetAgentSize() for a ZERO_VECTOR result; at some point somebody figured out it was the least expensive query for avatar presence on the simulation.

[Wandering Soulstar]

1 minute ago, steph Arnott said:

I was thinking that the agent script outputed a timed key message every five or ten mins. If the main does not recieve it then it does its thing. Was just a thought

Agree .. is a good path, but as I said, my concern is the number of agent scripts, running timers and sending the messages, that would need to be responded to by the HUD. This is for a builder 'toolbox' that I am creating and so every prim in the build (while it is in work) contain the agent script and so potentially hundreds of timers continually running, and, even if every 5-10 minutes, a tonne of messages flying back and forth.

[Qie Niangao]

1 minute ago, Wandering Soulstar said:

 This is for a builder 'toolbox' that I am creating and so every prim in the build (while it is in work) contain the agent script 

Can you have a single box that regularly polls for the HUD-wearing avatar's absence, then llRegionSay() broadcasts an obscure channel alert to all the little unlinked prims waiting on listen()s?

[steph Arnott]

5 minutes ago, Wandering Soulstar said:

Agree .. is a good path, but as I said, my concern is the number of agent scripts, running timers and sending the messages, that would need to be responded to by the HUD. This is for a builder 'toolbox' that I am creating and so every prim in the build (while it is in work) contain the agent script and so potentially hundreds of timers continually running, and, even if every 5-10 minutes, a tonne of messages flying back and forth.

Lost me, you said agent not a build.

[Wandering Soulstar]

1 minute ago, Qie Niangao said:

Can you explain what sort of cleanup you have in mind, or otherwise why you want these events? I mean, there's no HUD scripts to run after the user has logged ou

Thinking about it .. you are right .. the HUD itself does not need to clean up .. that is taken care of in the on_rez when logging back in ...

 

4 minutes ago, Qie Niangao said:

If instead you're wanting scripts on the simulation outside the HUD to do cleanup when the avatar disappears, the standard approach is to poll llGetAgentSize() for a ZERO_VECTOR result

This looks interesting .. removes the back and forth communication overhead ... but still have the issue of the hundreds of timers constantly running ... would that not be a major drag on system resources?

[Qie Niangao]

1 minute ago, Wandering Soulstar said:

This looks interesting .. removes the back and forth communication overhead ... but still have the issue of the hundreds of timers constantly running ... would that not be a major drag on system resources?

No, just one timer on the thing that's polling and, eventually, llRegionSay()ing the notification of the avatar's absence.

There'd be hundreds of listens, but on an obscure channel, they're trivially inexpensive.

[Wandering Soulstar]

1 minute ago, steph Arnott said:

Lost me, you said agent not a build. 

sorry .. by agent was referring to the scripts that reside in the prims .. outside of the HUD

 

3 minutes ago, Qie Niangao said:

Can you have a single box that regularly polls for the HUD-wearing avatar's absence, then llRegionSay() broadcasts an obscure channel alert to all the little unlinked prims waiting on listen()s?

have considered that as well ... and could add the code into the HUD to ensure that said 'monitor' always existed in the Region .. was just hoping there was an easier, event driven, way to do it.

 

[Wandering Soulstar]

@Qie Niangao, @steph Arnott

Thanks for the discussion ... The idea of a 'monitor' prim using llGetAgentSize is a good answer answer to the lack of events, but for it to work 100% would need to make the existence of the monitor something that the HUD does, otherwise at the whim of the user actually rezzing the monitor, and leaving it out.  And to do it automatically would need to check on a regular basis if one was in region .. and if not whether the User is currently on land that the monitor can be rezzed to

[steph Arnott]

5 minutes ago, Wandering Soulstar said:

Lost here. First we talking about a HUD which an agent wears, now we are talking about a build prims.  Sorry i can not wrap my head around what you mean.

[Qie Niangao]

7 minutes ago, Wandering Soulstar said:

was just hoping there was an easier, event driven, way to do it.

Yeah, I see what you mean, it would be handy if there were a "de-rez" event, kinda like the last dying gasp we get in the attach() event when a script detaches.

You know, I think it's worth trying it without the monitor object first, going ahead with a timer in each of the prims' scripts that did the polling. A timer can't be all that expensive until it fires, and it shouldn't need to fire often -- and can be reset each time it hears from the HUD (assuming it chats with these prims occasionally).

In fact, if the individual prims' timers don't end up synchronized, you could kind of combine the approaches by having the one that first detects absence do the broadcast message to all the others, so they don't have to wait for their timers to trigger -- but in this application that may not be worth all the extra listens, I'm not sure.

[steph Arnott]

5 minutes ago, Qie Niangao said:

Yeah, I see what you mean, it would be handy if there were a "de-rez" event, kinda like the last dying gasp we get in the attach() event when a script detaches.

You know, I think it's worth trying it without the monitor object first, going ahead with a timer in each of the prims' scripts that did the polling. A timer can't be all that expensive until it fires, and it shouldn't need to fire often -- and can be reset each time it hears from the HUD (assuming it chats with these prims occasionally).

In fact, if the individual prims' timers don't end up synchronized, you could kind of combine the approaches by having the one that first detects absence do the broadcast message to all the others, so they don't have to wait for their timers to trigger -- but in this application that may not be worth all the extra listens, I'm not sure.

Be better to have management prim. The others are irrelivent.

[Wandering Soulstar]

23 minutes ago, steph Arnott said:

Lost here. First we talking about a HUD which an agent wears, now we are talking about a build prims.  Sorry i can not wrap my head around what you mean.

Again .. sorry for being confusing. The full system is:

• HUD worn by the user
• Individual script(s) in the prims that are being used to build whatever it is we are building

The HUD controls which build function (script) is active in the prims, and for the more complex tools may deliver specific information on request to the prims, or facilitate the communication between them.

21 minutes ago, Qie Niangao said:

A timer can't be all that expensive until it fires

Isn't the fact that the timer is running enough to be a bit of load .. the system needs to be doing something. I know it may not be much individually, but in the hundreds?

[steph Arnott]

1 minute ago, Wandering Soulstar said:

I know it may not be much individually, but in the hundreds?

Would make no difference at all.

[Qie Niangao]

38 minutes ago, Wandering Soulstar said:

I know it may not be much individually, but in the hundreds?

The very existence of hundreds of scripts has some impact on performance of other scripts in the sim, even if those hundreds aren't doing anything -- in fact, even if they couldn't possibly do anything because they only have state_entry event handlers. That's because they add to the items on the scheduler queue... but if the sim gets through 100% of the scripts each frame, it really doesn't matter.

So then it becomes a question of what the scripts are doing. Waiting on an interval timer is not much different from waiting on a listen() message. In this case, though, it's probably marginally cheaper to compare strings extracted from a listen message than to make the llGetAgentSize() library call when a timer expires; that's why I speculated about adding listens as well as timers, to avoid needing every script to make that library call... but my hunch is it's very unlikely to ever matter.

Now, if those hundreds of scripts were going to sit idle for days, it might be worth keeping around a registry of which objects are scripted, and have all the scripts delete themselves until, when they're needed again, they're reloaded from the registry with llRemoteLoadScriptPin(). That only makes sense, though, if they don't have a lot of state that needs storing during that extended idle interval. 

[steph Arnott]

24 minutes ago, Qie Niangao said:

 

Well that was the case about scripts before Mono but if you had fifty odd copies of the same compiled script in the same sim that is not the case. I have no idea why one would have that many scripts in the first place on a build. The agent size will not register a de-attatced HUD if the agent was still in the same sim. Firing a key message every ten odd mins on a region say  would cost nothing. Preferably not on the public channel. Also the messages would staggared from the time the HUD was in use.

Edited February 20, 2019 by steph Arnott

[Wandering Soulstar]

44 minutes ago, steph Arnott said:

I have no idea why one would have that many scripts in the first place on a build.

The worker scripts do things like moving, distributing, sizing prims, as well as setting/matching textures. The only way that works is if they are in the prims that are being created to make the build. And when doing the initial build of any house or building, the numbers can easily get into the hundreds. 

 

1 hour ago, Qie Niangao said:

have all the scripts delete themselves until, when they're needed again, they're reloaded from the registry with llRemoteLoadScriptPin().

The reload could take quite a long time due to the inbuilt delay. There could be multiple worker scripts in each prim (only one running at any one time), so say 200 prims, 3 worker scripts, 2 sec delay per (if I remember properly) = 20mins to reload. 

[steph Arnott]

7 minutes ago, Wandering Soulstar said:

The worker scripts do things like moving, distributing, sizing prims, as well as setting/matching textures.

Well that alone is going to lag the heck out of the sim.

[Wandering Soulstar]

6 minutes ago, steph Arnott said:

Well that alone is going to lag the heck out of the sim.

How so? How does calling llSetLinkParamsFast from one or even 5 prims at any moment, when the prims are clicked do that? This is the third version of this. Have been using the previous version for nearly 4 years and have not noticed any lag in the sims I’ve built in. 

This is just an updated version with a better HUD, and updated capabilities. 

[steph Arnott]

1 minute ago, Wandering Soulstar said:

How so? How does calling llSetLinkParamsFast from one or even 5 prims at any moment, when the prims are clicked do that? This is the third version of this. Have been using the previous version for nearly 4 years and have not noticed any lag in the sims I’ve built in. 

This is just an updated version with a better HUD, and updated capabilities. 

You state that many people in a sim are all going to be rezzing prims, getting the script in the prims to mod them selves, move it etc etc. I can not see that not lagging the sim. If it works for you then good for you but it certainly would bother me in my sim. But i am only going by your comments so it maybe not as heavy as you appear to make it sound. Personally i use vector distance, if the modules are further away than ten meters (SL) it will throw up a message to move closer. The HUD issue still needs to ping it is active to a central manager script. If no ping is recieved after say ten mins it will determine non active. The non present in sim code will be the main determinant but if the person detaches the HUD it will not tell the manager script that it is non-active if that agent is stil in the sim.

[Qie Niangao]

1 hour ago, steph Arnott said:

Well that was the case about scripts before Mono but if you had fifty odd copies of the same compiled script in the same sim that is not the case.

The topic was runtime, not memory use. The only thing about multiple identical copies that Mono introduced was the shared code section of script memory -- and with LSL, even that can be less than one might hope because there's no such thing as declared constants (which could be shared) as distinct from state variables (which obviously can't be shared). That's one advantage of using literals -- even repeated literals -- rather than "constant" variables in LSL, unthinkable in "real" programming languages.

1 hour ago, steph Arnott said:

The agent size will not register a de-attatced HUD if the agent was still in the same sim.

As I understand the application, that's a feature not a bug. If the user re-attaches the HUD, they can just resume where they left off, until they actually leave the sim and cleanup happens. But if it were desirable to trigger cleanup when the HUD detaches, there's an event for that, so the HUD could llRegionSay() broadcast a cleanup trigger when attach() fires with a NULL_KEY avatar parameter.

36 minutes ago, Wandering Soulstar said:

The reload could take quite a long time due to the inbuilt delay. There could be multiple worker scripts in each prim (only one running at any one time), so say 200 prims, 3 worker scripts, 2 sec delay per (if I remember properly) = 20mins to reload. 

Yeah, it's actually 3 seconds, so even worse. I mean, if it were make-or-break, each script could start by propagating itself to a list of targets supplied by the registry, thus growing the set of populated scripts exponentially, but this all seems way out of scale and scope for this application -- which, as you say, hasn't been a problem before.