Nova Convair

I run pings of 180 to 250 for many years. That's a normal ping for an US west cost connection from europe. Zero problems, zero crashes - ok maybe 1-2 crashes per year. Paket loss is 0 all the time though - I think thats more important than the ping. AWS didn't change anything. Seems the ping is pretty constant at 230 now.

You'll not see my crosshair - switched off You'll not know if i take a screenshot - silent You'll not know if and what I inspect or edit You'll not get my IP except I want to hear that DJ 😁 LL stopped that others get to know what viewer you are using - good What's left is the online status that can't be hidden and your last login in group infos. All small things which I have no problems to deal with accordingly. That doesn't change the fact that I dislike it and therefore make the average snoopers life harder. 😎

Just some thoughts (1) If a script wants to check the active group of an avatar and this group is NOT the group of the object. It will check the avatars attachments and compares the group uuids of attachment and the hardcoded group uuid in the script. Hud's don't count here as a script can't see huds. That prevents the need to set the object to the required group. The assumption is - that every avatar has at least a body/head/hair/shoes/clothes. So if someone sets up a clean system avatar with huds only - the script will find no group. (2) In heavy lag conditions we'll see if a script is designed properly or not 😁 (3) Normally a script that spams status messages in open chat triggers in me some prejudices about the scripter - but in this case I can see the need to not run into throtteling of llRegionSayTo. Open chat is the easy way 😁

What happens if you give it to your alt and the alt rezzes it? on_rez - triggers maybe changed - triggers and resets for sure run_time_permissions - most probably never get's a chance to complete 1st - there is no guarantee that the events fire in a specific order. If you want a script that does not run by coincidence you need to code it so it runs in any order of events. 2nd - why do you reset it? there is no reason. The script overwrites the permissions every time it's rezzed. There is no owner variable and no open listens or anything else bound to an uuid. So the only reason to reset is to follow bad example scripts. 😁

If you switch off attached sounds - all sounds attached to an avatar are switched off (like gestures) including your own avatar. So you want to switch off other avatars gesture sounds but keep hearing your own? nope 😁

Es gibt die (alten) AO's, die überladen die Standard Animationen. Wenn also eine Animation die Beine frei lässt, sieht man die niedrig priorisierte Standard Animation zusätzlich. Moderne AO's ersetzen die Standard Animationen. Hat den Vorteil dass zur Ausführung kein aktives Script mehr benötigt wird, bedeutet aber auch, dass da keine Standard Animation mehr vorhanden ist. Do benötigst also entweder eine neue Animation (mit Beinen) oder eine alte AO (ZHAO).

No that's not a problem. If you have a 1v1 combat system in mind - leveling is crap completely. You need a class system then (class1, class2, ...) Duels within same classes. In a group combat 2 to 1 advances don't matter. Synergy of the powers and teamwork will win if the groups aren't too different in numbers and levels. For the formula - you don't need to limit on logN or log10 although log10 looks good I think. But that can be taylored as needed.

You need to put a logarithmic function into the calculation of the abilities. That way the increase per level will slow down the more the higher you get. That will prevent godlike charakters.

I have a rezzer at 2000m that rezzes ground scenes. If I derez one and TP down it's still visible. I can right click on every object or TP out and back in or log out and in. Anything that forces the viewer to reload the environment. This does not happen when I derez stuff in range. That always vanishes instantly. So it has nothing to do with llDie but with viewer updates.

And if you don't want to get muted you need to maintain a list of all avatars you already greeted and don't greet them over and over again. 😁 If you want to do a "welcome back" greeting you need to track the ones that were already greeted but come back.

What Lucia says and some more. But That means that LL runs a processing host. Not a problem for the Amazon cloud but that's not for free. Of course you can't give that away for free. People would play Doom and mine bitcoins. 😁 It's not a problem - but only if they have to pay for it on their own. 😎

I have stopped to waste my time with multisit a quite a while ago. Maybe there is wrong thinking on your side. This is SL not RL. It doesn't matter on what prim an avatar sits. You can put the sit target freely in a radius of about 300m around that prim. In a multi prim object - set 3 sit targets on 3 different prims and setup the sit targets so the avatar is placed at the prim you want them to sit on. Easy, quick, reliable. If you prefer multisit that will be painful. 😁

I use 2 global variables: integer gnumber_of_prims; integer gDirty = TRUE; at startup the linkset is scanned and I get link#s for the names and i set the number of prims changed event: dirty flag is set if the linkset is changed AND NOT if an avatar sits/unsits changed(integer change) { if (change & CHANGED_LINK) gDirty = gnumber_of_prims!=llGetObjectPrimCount(llGetKey()); } and b4 accessing the links: if (gDirty) call_the_linkset_scanner - scans linkset, sets gnumber_of_prims and resets gDirty; Some overhead involved but not too much by my taste, object can be changed and can be sat upon and script will still work. And: it will not scan the linkset permanently. The linkset scanner for a door gets the distance to the "prims" and only takes them when they are under a certain distance! If too far away - keep looping. That way I can link multiple doors to the same object and there is no need to use different names. I am way too lazy to set up every single door, they have to work once linked.

What I do in some cases is taking clicktime. (touch_start takes time and touch_end evaluates) A normal click will run option1 and a long click (hold button maybe 2 seconds) will run option 2 No need for an extra menu and since resize will be used rarely that works for option2.

This works too: searchfor = ["nametag1","nametag2","nametag3"]; if (~llListFindList(searchfor,[press])) llSay(0,"found "+press); else llSay(0,"not found"); I stumble about the question about speed. How many times per second you want to do this? 😁 However, enclose the solutions in a loop from 1 to 100000, get time b4 loop and after loop and show the difference. Then you get the answer about speed.

You and others treat SL like RL. That's ok. But you think others have to see it the same way. That's a complete wrong expectation. 😁 Others see it as a game and think others have to see it that way. Definitely a wrong expectation. 😁 There are people that respect nothing. In RL they get punished or shot, so they behave. Not because they want but have to. In SL there is no punishment. Go figure. So I don't see much hope for you. Install a zero-time orb, then you don't need to deal with that. If you're place doesn't allow it - wrong place. If you use the parcel ban list add a time to the ban so the list will not fill up and ppl usually don't come back. But that's way too much efforts. I prefer instant kill - fully automatic - so that I don't have to think about it. I have been on such a parcel once. An automatic asskicker helps 💪 At the moment I am on a quiet place and don't need to deal with unwanted visitors.

What Navy1 says. I can always enter access restricted places without wearing the group tag. That's handled by the sim/viewer and my groups are known it seems. A script on the other hand knows absolutely nothing about my groups. It can only see the group tag I wear at this moment. If you need a script you need to wear the tag.

A gesture is handled only by the viewer. There is nothing you can do with it by scripts.

If you attach to the left side - the center of the root of your hud is placed on the left side of the screen. Y = 0 is at the left screen border then and if you attach to the right side Y=0 is at the right screen border. Same applies to Z for top and bottom. Once attached you use llSetLocalRot and llSetPos to set your hud on a proper position and rotation. For the center attachments Y=0 and Z=0 is in the middle of your screen. That means you dont know where the borders are. Imagine a small notebook screen and a widescreen. The X-axis is the depth and has no visible effect, except you have 2 overlapping huds. Then you can control who is in front.

Sooner or later you will find out that it is not that easy to copy a large number of items into a box. In this case you want to read: https://harleyquinadventure.com/zdrop-for-firestorm-users-move-animations-inventory-fast/

I removed flash quite some years ago from my system. So there are no upcoming changes from my point of view and I did not encounter any problems all the time. (not seeing garbage flash stuff was and is no problem for me) 😁

That is longer than 16k - so in LSL you get a json string that is cut in half and that will surely not work properly.

The knowledge of an IP does not give you any banning ability. In my case I don't even need a VPN to have a different IP everytime I visit this forum. It's a technical necessity to give the web server your IP so it can send you the data. Logging the IP will not give LL the general ability to ban someone or locate someone - only if the people's connection allow them to do so. The OPs concern is a possible localisation by other users - not possible here if there are no security holes/misconfigurations in the forum software. If there are serious concerns - a VPN is needed and never trust anybody to do things right.

Someone that fears their IP is public in a forum doesn't ask in that forum but uses a VPN instead.

attach is triggered: attach from ground, attach from inventory, login, detach on_rez is triggered: attach from inventory, login So both are good in this case. One detail: integer perm = llGetPermissions(); if (perm & PERMISSION_TRIGGER_ANIMATION) <you already have that permission>