Knowing when someone crashed or relogged

[Loki Eliot]

I'm having trouble deciding how best to manage players who crash during a game. 

My experiences always use huds to tell stories and manage the expereience, and XPtools allows me to temp attach huds and streamline the experience. But the area i'm still not fully happy with is a situation where the player crashes and relogs loosing the temp HUD right in the middle of the experience. 

Im trying to work out what possible solutions to this situation there might be?

I need to somehow know the user does not have a the HUD and reattach it. Does anyone have any ideas?

[Qie Niangao]

Maybe there's a simple solution, but I'm wondering how you ordinarily handle the return of already enrolled experience participants -- not after a crash & relog -- days or weeks after they were last present on the experience sim(s). I'm supposing you try to re-attach a HUD in those cases, too, so how is the crash / relog situation different?

Maybe your sim uses teleport routing or something so all new arrivals are easily detectable, but if not, you might already poll llGetAgentList() to detect those new arrivals, and in some cases that will detect when somebody goes missing from a crash, and can then handle them as a normal return participant when they relog.

A quick relog, however, can sneak in between any reasonable llGetAgentList() polling interval* and those arrivals need to be detected, too. Because you presumably have no persistent attachments on these avatars, you can't detect on_rez in them, so maybe have the HUDs respond to llRegionSay() polling, and if for some agent in the sim there's no HUD response in a short interval, that might be a relogged crash.

If you're not using llGetAgentList() and have some other process for handling normally returning participants, then another option might be to keep polling llGetAgentSize() of everybody you've detected, so you can maintain a current participant list, and thus know when to reattach after somebody has gone missing and returned. I think you'd still want to send llRegionSay() pulses for acknowledgement by your HUDs, because the relogs could sneak in between the llGetAgentSize() polling just as easily as llGetAgentList().

_________

* llGetAgentList()  is an expensive function, especially on a sim with many avatars present.

[Rolig Loon]

One of the best features of Experience tools is the ability to save information as KeyValues.  Script your HUD to record a player's progress as s/he proceeds through your game.  Each time the player passes an important physical marker or achieves a paricular goal, record it as a bit it some progress string that is saved immediately as a KVP with the player;s UUID in it for ease of recovery.  If a player logs out or crashes in the middle of a game, all you have to do is poll that KVP as soon as the player logs in again and autoattaches a new HUD.  Tell the HUD to pick up where it left off.  That could mean simply updating scores in a HUD display but it could also mean teleporting immediately to the last physical marker where the player was.

As for knowing when to autoattach a new HUD, the easiest thing to do is to poll llGetAgentList every few seconds from a central watchdog script and have it ping everyone on the list.  If a player's HUD doesn't reply with a confirming ping, autoattach a new one.  For good measure, send a llDie command with llRegionSayTo just before your autoattach, just in case the player really did have a HUD and it wasn't pinging properly.

[Estelle Pienaar]

You can reduce the amount of communication between scripts if you first compare the list of present agents on the Sim with the previous list of agents. For example: If you check every 10 seconds, then check in the second step who has not been there before. It is unlikely that someone crashes and relogs in 10 seconds right?

Then you only ping the HUDs of the people who are new on the sim. If they do not respond you attach a new one (EDIT: Better run a second check before attaching as sometimes communication between scripts fail when there is lag in the sim). As a result there should not be too much communication going back and forth unless you expect dozens of players entering and leaving your region every minute.

For the rest of Rollig's advice, the storing of data in the database, I can tell you from experience that it creates no lag problems at all.

 

[Estelle Pienaar]

Oh and llGetAgentList is not a scanner, it's a slim way for getting agent data. A timer and llGetAgentList does not put any stress on your Sim.

[Rolig Loon]

Estelle's got it, saying the same thing I did but with clearer words.  You asked, "What polls a KVP as soon as a user logs in? "  The HUD does, as soon as it's attached.  It's first action is llReadKeyValue, asking the dataserver to tell us what's already in the saved KVP associated with that player's UUID.  If nothing is, then this is a new player, so create the KVP.  Is there is something saved, read it and update the HUD accordingly.

Running llGetAgentList every 15 seconds or so isn't going to kill a region.  Nor is having the central brain and each of the HUDs trading llRegionSayTo pings.  It's a trivial load.

[Estelle Pienaar]

Sorry Rollig, I also thought that I wrote exactly the same thing as you and then I deleted it (because I didn't want to be accused of plagiaism). I shouldn't have done it.     :matte-motes-confused:

[Loki Eliot]

thanks everyone, ill take a look at this and see if i have time to write it a system

[Qie Niangao]

Couple of things. First, llGetAgentList() is not as cheap as all that. I agree that once every 15 seconds shouldn't be too much load, but the problem is that it returns a list of agents on the sim, and a calling script presumably will do something with that list -- something at best linear in the number of agents. The thing is, it's exactly when sim load is already high -- when it's most crowded -- that using this function will add the most load. It is part of the right approach here, most likely, but that sampling interval can't be sub-second.

And that's the second thing: We cannnot rely on the disappearance and later reappearance of an agent in llGetAgentList as the sole signal to detect somebody relogging and losing their temp-attached HUD. Some will be able to relog too quickly for any practical llGetAgentList sampling interval. (Yes, easily within ten seconds!) That's why it's better to let those intervals be longer and use the results only to maintain a list of participants currently present, and on a similar leisurely interval poll all those who are present to make sure their HUDs are still attached.

[irihapeti]

another ways is to look at the interactions a player is having with the game objects to determine this

there is the LInden Realms way

like a on collision when a player comes into vicinity of each interaction. have the invis collision object ask for the presence of the HUD. If is no response then give it

Linden Realms works this way when the players portal onto the arena

+

load wise

there would be max 65 collisions events when 65 avatars hit a collision object at the same time

+

if want to allow them to relog back onto the arena at the exact crash point (instead of have to re-enter the arena thru a portal (Linden Realms style)) then best to use a mat-style vicinity  collider surrounding each interactive game object/section

+

also as well. Is the simplist direct way

when the player does interact then there is a two-way communication between HUD and interactive object ? if so then easy for the interactive to know if HUD missing, so give

if not two-way then can think about making it two-way if only to check for the HUD