Nova Convair

I suggest to simply rename the files (add an x for example) and then rename back. When testing this I didn't see any difference. Didn't see any side effects too so it seems I don't use affected things. :) It may work for older hardware or craptops though but everybody can test that for their system.

That's a question of geometry. I make a prim root and use it as show/hide button and link the hud to it. Then perform a 180° rotation so the hud is rotated off screen. If you make the backside of the hud the same as the front side you can use this construct for left and right margin. Can be constructed for top and bottom margin the same way. For sliding get the size with llGetScale and move the exact width/height into the right direction and back. In this case you want the show/hide button connected to the side of the hud so it will stay on screen.

I've seen quite some failures over time and never trusted undocumented timings or that things happen in an expected order. So I'm not affected here. Having a string as rez parameterr would simplify rezzing quite a bit though.

llSitTarget() has a range of about 300m, so it's easy to hide someone the moment they sit. But the avatar will stay there on unsit so not reappear. That requires more efforts. An animation with an offset has a range of 10m - enough to hide underground - and the avatar will reappear on unsit. Making the avatar invisible is the most difficult way and requires preparations made by the avatar b4 usage plus active RLV - so that doesn't sound practical - except you only want it for yourself.

If all of your huds were affected by a crash - the scripts in your body and head and every other scripted thing will be affected too. So replacing the body hud will not help - you need to replace the body too.

Well you gave not the answer the op wanted. You even wanted details but the op never makes mistakes so doesnt need to give details. Instead you bring up things like copyright. A total waste of time. And then the snowflake melted. 😋 Hmmm .. I think I will not check here for answers .. people tend to think I'm always serious. However that was entertaining.

Just block the op in advance, then you are save - for now. 😎

You need to search for the exact name, not characters just looking alike. So you can try to copy and paste it into the search or rename it into something useful. SL has problems with unicode characters and different tables work/don't work in different places/name fields/search strings. Maybe it even doesn't work at all here.

One detail: I have 200ms ping for many years and that's quite normal and the minimum (I can not get less) for a europe to west coast connection. (To east coast a 120 is possible) No disconnects here, so if ping is a factor it needs to be much higher. I have 0% packet loss though - always - (well whenever I looked 😎) That's probably more a factor to keep an eye on. (no wifi here)

I never script inworld. Testing and debugging I do inworld - usually at SL-home-location.

And why can I only add 2048? Ok, some more but 8192 is far out of scope It's obviously 16 bytes per element in my example and 4 in your example.

I made a test. 1st thing I encounterd - 8192 integers do not fit into memory at all. Although I see NO error in your method of doubling the list - it obviously doesn't work. // // Memory allocation test - do we get free memory back? // integer listcnt = 2047; default { touch_start(integer total_number) { llOwnerSay("Free mem before allocating list: " + (string) llGetFreeMemory()); list buf = [1]; integer i; for (i=0; i<listcnt; i++) { buf += [i]; } // llSleep(0.5); llOwnerSay("Free mem after allocating list of " + (string)llGetListLength(buf) + " integers: " + (string) llGetFreeMemory()); buf = []; // release memory llSleep(0.5); llOwnerSay("Free mem after releasing list: " + (string) llGetFreeMemory()); } } And the result is: [03:41] Object: Free mem before allocating list: 61140 [03:41] Object: Free mem after allocating list of 2048 integers: 28228 [03:41] Object: Free mem after releasing list: 28228 [03:41] Object: Free mem before allocating list: 28228 [03:41] Object: Free mem after allocating list of 2048 integers: 28228 [03:41] Object: Free mem after releasing list: 28228 The last 3 lines repeat over and over on every click. So what happens: - You need to use llSleep before you you llGetFreememory or you will not get a valid result. - After adding 2048 single integers to the list the occupied memory is not freed - On the next run there is no stack/heap collision - that means an automatic garbage collection was performed an so we can run this forever. It makes no sense that you could allocate 8192 integers to the list. Some math: an integer needs 4 bytes but every list element needs at least a pointer (4 bytes) and most probably some extra info like type flag and stuff not to mention a backward pointer so I don't see how 8192 elements will fit into 64k. I've read that scripts can exceed the 64k limit for a short time - in this case a garbage collection is forced - and if the result is still over 64k a stack/heap error is generated. Probably this doesnt work like expected here. Edit: clicking after 15 mins gave this result: [04:09] Object: Free mem before allocating list: 61140 [04:10] Object: Free mem after allocating list of 2048 integers: 28228 [04:10] Object: Free mem after releasing list: 28228 If seems that garbage collections are performed when the script idles long enough.

You don't need a special viewer. You just need to compile in world and NOT in inventory.

Yes, insanely fast But not over time like it happens here. If the script continues to run then you have left the recursive stack. You can't accumulate used memory on the stack that way in LSL. Either you crash or the recursion has ended. If processing stays in the function then you will have no events in that time. Edit: I get the impression that it's not known how recursion works. Example: - We call a function - let's call the level we are in: incarnation 0 - Now the function calls itself - the processing happens in incarnation 1 now - same function - Now we do it again - the processing is in incarnation 2. - The function ends - but that means incarnation 2 stops to exist and is removed from the stack and the processing ends in incarnation 1 - at the next statement after the recursive function call. - The function ends again - incarnation 1 is removed and the processing continues in incarnation 0 - The function ends again - now that we are leaving incarnation 0 the control goes back to the event where the function was called the 1st time. As you can see - you can not leave until the whole stack on incarnations is worked off - you can not leave things back on the stack. If that would be possible - LSL wouldn't be able to do recursion at all. But LSL can do recursion! So there are only 2 possibilities - the recursive call crashes your script - or leaves with a clean stack.

LSL is single threaded - as long as an event or a function is processed - no other event will fire. If processing is in an incarnation of a recursion that will block any other events. If processing leaves this incarnation it will continue in the previous incarnation of that function and still block events. The script will only continue to process events when all incarnations of the function are left. The stack is cleared then. So in the end it's no difference to any other non recursive function.