Tactical UwU

It's ultimately up to sim/arena owners to set up and enforce what they want to permit in their respective combat zones. There will always be bad actors as a result of malice, incompetence, or both. If people want to preserve creativity and a content creator's ability to make unique items, then it's going to be up to both the owners and content creators to work together on a solution. It's going to take time for people to figure out how to best utilize these new features, and that's with any new system so this should be nothing new to most people who have participated in any combat community for any significant length of time whether that be VICE, LLCS, or one of the dozens of -CS systems. My primary concern regards auditing system interaction which so far looks very solid. This will allow people to create a lot of tools for identifying and addressing bad actors, especially with other existing features such as region experiences. This could very well include some forms of automated administration as well in extreme cases of abuse. One issue I do have is with the anti-grief @Rider Linden. Creating a prompt for teleporting home could actually lead to the grief being worse. Many combatants in LLCS already have to disable certain features like loading screens for teleports due to the prompt locking up the client when spammed due to failed teleports, rapid teleports (ie. getting spawn camped), or region/client latency. Instead, a better solution would be allowing sim owners to define a grace period after respawn inwhich the avatar cannot be damaged, aka spawn invulnerability. The anti-grief itself could simply be a forced grace period as well which will allow participants an opportunity to address or decide how to deal with the ongoing situation. Though to be blunt, if your spawn zones have damage enabled that's more of a sim design issue than a griefing issue.

As someone who has owned and ran multiple clubs and sims, no. It is not against the TOS is verify someone's age if you believe them to be wrongfully accessing adult content you provide. Considering you as the owner can be held liable and even suspended from SecondLife for exposing underage residents to explicit material, taking proper measures against people who have falsified their credentials to get past SecondLife's restrictions is part of your due diligence. That said, I would restrict such actions to those who's age has cause for doubt as opposed to making it a general requirement for all patrons. Just remember you are not allowed to share any information you collect from this as that in and of itself is a TOS violation.

Context: https://jira.secondlife.com/browse/BUG-228939 I've been noticing lately and getting reports of an increasing issue with scripts containing on_rez events having their functions delayed for up to several seconds. This was tested at all 3 beta sandboxes. Only BlueSteel was unaffected.

I honestly don't see why this is necessary when we already have a system in region Experiences that makes the teleport-related functions a largely 1-time opt-in anyway. All you need to do is run a llAgentInExperience call and you could even go as far as to require it. I have a security system checks this and will not give you a land pass if you don't use it. It's really not hard to set something like that up. Anything short of that is an open-door to misuse and abuse.

llManageEstateAcess is a good alternative if you're an EM or EO for the region you manage. Tbh, the limits put on place of llTeleportAgent are fair and can easily handled via an Experience. If land owners getting too out of hand (anymore than they are already able to) with it, you can simply not go to their land. I do believe it should be restricted to EMs and EOs though and not just parcel owners.

llSetVelocity() will force an object/avatar to the velocity given and is by far the most reliable for maintaining a set speed. Something to note however is that, for avatars, movement is heavily restricted by the engine and you will need to constantly reapply the desired speed. In addition, in damage-enabled lands, the friction from this and whatever the avatar is standing on is enough to kill the user.

Can confirm this started around 6am EST.

A single region is allotted a fixed amount of resources. While prim limits and land size can be limited by the size of the parcel itself, parcels otherwise share all the region's resources with each other. Anyone's who rented in a region knows that one person who makes the sim run terrible which is why some rental groups have strict limitations on what can be on what sim with many downright banning certain establishments (namely clubs) due to the problems they cause for other tenants. That said, if you want to host clubs or large businesses, it's better to dedicated an entire region for that purpose as opposed to lumping it in with a residential sim. Regularly high latency will quickly run off potential or current tenants.

It is and there are 2 methods: The first uses llSensor("","",1,FOV,96.0); The limitation of this method is it only works within 96m of where you are but it is the easiest to program and less-region intensive. The second involves llGetAgentList and a lot of math. Not recommended but it's able to work across an entire region and it can even work in 3rd person. Something of note is that some TPVs have this built into their client and it is recommended you use that over something scripted.

The more important thing is understanding the limits of what you can do and how you can do it. You have to understand how to work within the limitations of the engine and what those limitations are. Many would-be scripters absolutely fail at this and it's the difference between someone who just slaps things together until something works and someone who can create entire experiences without the sim running like DOS machine on a hamster wheel.

The wiki may be inaccurate in several instances because I made a thread about this issue last year. IIRC "PASSIVE" and "SCRIPTED" cannot be returned at the same time now since "PASSIVE" objects are considered unscripted (???). I've since started using functions like llGetObjectDetails() in combination with broader Sensor flags to distinguish objects between scripted, passive, and active as a result.

To answer your question, if you saw the "You died and have been teleported to your home location." message, you were killed on damage-enabled land. You can not be killed through this method if server-side damage is disabled. However note that when this setting is toggled some viewers do not immediately display your health and this can cause some confusion.

Griefers of this nature do it for the attention and distress it causes you. Usually the best thing I can recommend outside of manually banning them is to set up a security system that will ban an avatar if they were created recently (2 months or 60 days minimum recommended). Having a parcel in a region that requires payment info to access is also a good way to pre-emp stalking attempts. At that point, the worst you have to worry about is maybe a few rude IMs when you log in, just mute the accounts being used and continue with your day from there.

Same issue. Not able to get a key as the button is gray'd out.

I use Singularity as well and had to upload the animations as .ANIM files because the BVH files wouldn't initialize. My only issue with this is that there was no way to preload the file ingame unlike BVH so I spent close to 200L trying to adjust the animation due to upload fees.