Detached but still attached bug

I've just spent 30 minutes tracking a wierd bug in a combat system.

Each avatar wears a HUD and weapon, and the weapons talk to opposing HUDs.

I removed the HUD and weapon from one avatar yet the other HUD and weapon acted as if the opposing avatar still wore the HUD. When the weapon was pointed at the HUDless avatar it could still detect the avatar's HUD and shoot it.

After logging the HUDless avatar out and relogging it back in the problem vanished.
I can't reproduce it.

Has anyone else heard of a HUD acting as if its attached when it is has been definitely detached?

By the way, there were no other HUDs and weapons within a few 4000m

If you could reproduce it, I'd suspect that once your HUD detects an opponent's HUD it starts tracking that HUD's owner rather than the HUD itself.

When you say the HUD was "definitely detached," do you mean it was dropped or that it was in the av's inventory? And was it definitely detached in the same manner in both cases?

Unfortunately the HUD can't track an avatar because it does not use the llSensor command as commonly used by trackers scanners etc. It uses the chat commands on a special channel, with avatar UUIDs to ensure that it cannot listen to itself, only to other HUDs worn by avatars.
In order to detect another HUD it needs to receive a known reply command on a ping channel and comms between them follows a specific protocol to prevent hacking.

Yes, the HUD was detached using the pie menu and existed only in the inventory - it was not left on the ground. Only one HUD was in action and it needs replies from another HUD to function properly.

I wish i could have reproduced this then reported it to the JIRA but hopefully it is a rare fluke. It is still worrisome though.

You are right to question this because I've learnt that bugs in my software are nearly always caused by my errors and not caused by the language or operating environment.

There is a known problem with mono scripts still running after being removed from the sim.

I can't find the jira, but some people are having to repeatedly reset regions to really kill removed scripts.

Thank you, i didn't know about this - our scripts are indeed mono - now to think about a work-around.

IT may not only be mono scripts. It's obviously something hard to track.

On the other paw, I would recommend not using mono scripts in a HUD. Mono scripts have much more overhead when crossing sim boundaries.

Is that true? I built a HUD for group use last fall, expecting people to use it as they roam across the sims in our general region. I compiled it in Mono, as I usually do these days, and haven't noticed any ill effects. As HUDs go, it's a pretty passive one, so maybe the effect is too small to see. Or am I missing something?

Sim crossing isn't working super-well anywhere right now, and the effect is small for any given script, but where an LSL script simply involves copying 16k of data from one server to another, the mono one has to halt the script in the mono vm, and then traverse the code and data of the program to package up all the variables and lists, to produce a "serialized" version of the program. Then at the other end it has to reverse this operation. It's a bloody brilliant piece of work, but is a mite time-consuming if you have many scripts involved.

Ah. That's more complex than I thought. It's probably still not an issue for my small passive script, but worth keeping in mind. Thanks.

The script is probably still getting the attach event. Maybe you can use that or llGetAttached to trigger the script to respond with "I'm not really here" messages.

Yes, I'll have to look into this so the scripts know they should be inactive and cannot process any comms requests and just idle.

When opening this post I never thought it would raise so many issues - its been an eye-opener - like opening a can of worms. Just hope this hanging script problem is fixed soon as compiling scripts backs to LSL from Mono is a real problem due to smaller memory available.

I thought I saw something about some scripts refusing to unload in relation the 1.27 server rollout but cannot find the reference and don't know as to whether the problem is fixed or not. It mentioned something about sim owners only being able to rid the sim of these scripts by a doing a sim restart. Perhaps someone knows the answer to whether server 1.27 fixes this issue.

believe it or not, LSO and MONO memory limits are rather close to equal when it comes to raw storage of string data, and MONO only really sees a significant memory boost in math/numeric heavy scripts (and speed of course). why? strings in MONO are UTF (yes keys too) and apparently many of the functions take more byte code too. couple that with MONO not being as Sim Friendly on border crossings and TP's (because of the way the MONO VM works). so while you have twice the memory available, you also used about twice as much to do the same things (math and numeric data excepted). just something to keep track of when you're scripting.