Jump to content

Recommended Posts

I'm happy to announce that the first EEP related LSL functions are in the latest roll of the EEP servers. The documentation will be up on the wiki very soon.

llGetEnvironment

Retrieves the current environmental settings for a region or parcel in the specified layer. 

Function

list llGetEnvironment(vector pos, list params)

 

These functions return the current environment values for the parcel and the region as a list of attributes. They take a list of attributes to retrieve in params and returns them in the order requested.

  • pos: A position in region coordinates. X and Y are in region coordinates and determine the parcel.  If X and Y are both -1 the environment for the entire region is inspected.  Z is the altitude in the region and determines which sky track is accessed. 
  • params: A list of parameters to retrieve from the current environment. See table below for details.

If an unknown rule is encountered in the parameter list an error is emitted to the debug channel. 

Caveats

  • If the script can not run in the requested parcel this function returns an empty list and issues a warning in the debug channel.

 

Parameters

parameter return values description
SKY_TRACKS 15 float sky2, float sky3, float sky4 Altitudes for sky transitions in the region.
SKY_AMBIENT 0 vector ambient_color The ambient color of the environment
SKY_TEXTURE_DEFAULTS 1 Integer bloom_is_default, integer halo_is_default, integer rainbow_is_default Checks if the textures are currently set to use the default. For default values the returned integer is 1, if the texture uses something other than the default this value is 0.
SKY_CLOUDS 2 vector color, float coverage, float scale, float variance, vector scroll, vector density, vector detail, integer is_default

Environmental cloud information.

  • color: The color used for the clouds. 
  • coverage: The coverage percentage.
  • scale: The scaling applied to the cloud textures. 
  • variance: A randomizing factor applied to the main cloud layer
  • scroll: The scroll speed of the clouds. 
    X is east/west
    Y is north/south
    Z is unused
  • density: The X/Y and D parameter used to generate cloud density
  • detail: The X/Y and D parameter used to generate cloud details.
  • is_default: 1 if the clouds are using the default texture.
SKY_DOME 4 float offset, float radius, float max_altitude

Sky dome information.

  • offset
  • radius
  • maximum altitude
SKY_GAMMA 5 float gamma The gamma value applied to the scene.
SKY_GLOW 6 vector glow_color Glow color applied to the sun and moon.
SKY_MOON 9 rotation rot, float scale, float brightness, integer is_default_texture, vector direction, vector ambient_color, vector diffuse_color

Detailed moon information

  • rot: The current rotation applied to the moon.
  • scale: The current scale applied to the moon's texture
  • brightness: The moon's brightness
  • is_default_texture: 1 if the moon texture is set to the default. 0 otherwise
  • direction: A unit vector pointing at the moon.
  • ambient_color: The ambient color of the moon
  • diffuse_color: The diffuse color applied to the moon.
SKY_STAR_BRIGHTNESS 13 float brightness  
SKY_SUN 14 rotation rot, float scale, vector sun_color, integer is_default_texture, vector direction, vector ambient_color, vector diffuse_color

Detailed sun information

  • rot: The current rotation applied to the sun.
  • scale: The current scale applied to the sun's texture
  • sun_color: 
  • is_default_texture: 1 if the moon texture is set to the default. 0 otherwise
  • direction: A unit vector pointing at the moon.
  • ambient_color: The ambient color of the moon
  • diffuse_color: The diffuse color applied to the moon.
SKY_PLANET 10 float planet_radius, float sky_bottom_radius, float sky_top_radius

Planet information used in rendering the sky

  • planet_radius
  • sky_bottom_radius
  • sky_top_radius
SKY_DENSITY_PROFILE_COUNTS 3 integer rayleigh_count, integer mie_count, integer absorption_count Number of profiles currently active for atmospheric scattering.  Currently all values will return 1.
SKY_RAYLEIGH_CONFIG, integer profile_num 18 float width, float exponential, float exponential_scale, float linear, float constant

Rayleigh scatting profile parameters. profile_noshould be passed along with this parameter to request a specific profile index.  Currently only one profile is supported.

  • width
  • exponential
  • exponential_scale
  • linear
  • constant
SKY_MIE_CONFIG, integer profile_num 17 float width, float exponential, float exponential_scale, float linear, float constant, float anisotropy

MIE scatting profile parameters. profile_noshould be passed along with this parameter to request a specific profile index.  Currently only one profile is supported.

  • width
  • exponential
  • exponential_scale
  • linear
  • constant
  • anisotropy
SKY_ABSORPTION_CONFIG, integer profile_num 16 float width, float exponential, float exponential_scale, float linear, float constant

Absorption profile parameters. profile_no should be passed along with this parameter to request a specific profile index.  Currently only one profile is supported.

  • width
  • exponential
  • exponential_scale
  • linear
  • constant
SKY_REFRACTION 11 float moisture_level, float droplet_radius, float ice_level

Sky refraction parameters for rainbows and optical effects. 

  • moisture_level
  • droplet_radius
  • ice_level
SKY_LIGHT 8 vector light_direction, vector fade_color, vector total_ambient

Miscellaneous lighting values

  • light_direction: unit vector indicating the direction of the dominant light source. 
WATER_BLUR_MULTIPLIER 100 float multiplier Multiplier applied to blur the scene when under water.
WATER_FOG 101 vector color, float density, fload modulation

Fog parameters applied when underwater

  • color: The color of the underwater fog
  • density: Density exponent applied to the fog
  • modulation: 
WATER_FRESNEL 102 float offset, float scale

Fresnel scattering applied to the surface of the water.

  • offset
  • scale
WATER_TEXTURE_DEFAULTS 103 integer normal_is_default, integer transparent_is_default Checks if the textures are currently set to use the default. For default values the returned integer is 1, if the texture uses something other than the default this value is 0.
WATER_NORMAL_SCALE 104 vector scale Scaling applied to the water normal map.
WATER_REFRACTION 105 float scale_above, float scale_below

Refraction factors when looking through the surface of the water.

  • scale_above
  • scale_below
WATER_WAVE_DIRECTION 106 vector large_wave, vector small_wave

Vector for the directions of the waves  Y represents north/south and X represents movement east/west.

  • large_wave: Large wave speed and direction.
  • small_wave: Small wave speed and direction.
  • Like 4
  • Thanks 2

Share this post


Link to post
Share on other sites

OMG!
I wasnt expecting so many LSL goodies, and so soon! The things we can do with that are exciting, let the imagineering begin!

giphy.gif

Edited by Macrocosm Draegonne
  • Haha 1

Share this post


Link to post
Share on other sites

I can't wait for:

llSetEnvironment(vector pos, list params);

Or even better....

llSetEnvironmentTo(key avatar, list params);
llSetEnvironmentAt(vector pos, list params);

 

  • Like 4

Share this post


Link to post
Share on other sites

From Inara Pey's blog:

 

Quote

 

EEP

The next EEP function to see light of day should be llReplaceAgentEnvironment, that should allow an experience to override any environment setting currently being used by an avatar within that experience.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Hmmmm???

Can ya then go back and set your own manual adjustments?   Or is that considered breaking the Experence? 

 I was just thinking.    So with Grid Wide Experiences eventually in the mix,  what tricks are gonna be needed to force this?

environment_sample.thumb.png.77ce44d3ac6f27c4ac22386a7156acea.png

Avatar Animation Info is Displayed for contrast, Both Images have ALM enabled, Option A - Firestorm Orac-Drawing red,  Option B  [TOR] SPECIAL - USE with full bright (oops, no full bright around)

And..... What tricks are gonna be needed to undo it?

Is it just gonna be Unaccept / Block an experience?  And Grid Wide Experiences, aren't they supposta be set up to be already opted in, so you gotta opt out?  Or go back and figure out what to opt out of?   

Or can I just clicky and make the lighting on my screen back to normal boring lighting without having to negate the entire experience?

Eh... Probally Ima just wondering about nothing.   

 

Share this post


Link to post
Share on other sites
9 minutes ago, StrayWanderer said:

And Grid Wide Experiences, aren't they supposta be set up to be already opted in, so you gotta opt out? 

Grid wide experiences have been confirmed as manual opt-in. It's been specifically said they are not like the Lab/Firestorm ones that run in the starter zones.

10 minutes ago, StrayWanderer said:

Or can I just clicky and make the lighting on my screen back to normal boring lighting without having to negate the entire experience?

Most likely. You can also leave the experience and/or report it for harrasment if what it's doing is like your screen shot.

Share this post


Link to post
Share on other sites

Well the screenshot was an extreme example but I did use off the shelf windlights in Firestorm as examples, implying is not hard to find a template thingie.

And while not very probable, Gee... it would be a pain if a previously accepted grid wide experience could 'change it's mind'.   If it worked like that.   Would make it fun to disable them all one-by-one.   

An additional thought was for the other more extreme use case of end users that may need some different lighting.   Something like needing high contrast / super bright, etc.   Because they are visually impared.   So manual end user override is just a case of not being mean. 

So as long as end user can opt back out / override without a lotta effort,  is good enough.      

     And a lotta effort is spending more than a min to be able to see what you could last time you were logged in somewhere.

Ima not saying its 'Not a Neat Thing'.   Ima just used to breaking stuff.. Um.... I mean stuff breaking.    

 

Oh and of course now we gotta see if 'that may break the experience' is gonna be a thing that is about as Evil as cheating outta RLV    😄    

Share this post


Link to post
Share on other sites
1 hour ago, StrayWanderer said:

Or can I just clicky and make the lighting on my screen back to normal boring lighting without having to negate the entire experience?

You will always be able to override a parcel/region/experience forced environment locally.
On EEP viewers, it's as simple as choosing your environment setting in inventory, right clicking it & choosing "Apply only to myself".

Once you have applied an environment locally, you will continue to see that local environment for the rest of the session.

RLV/RLVa needs some fixes to work correctly with EEP, but it will be possible to force a certain environment onto an RLV/RLVa user & lock it in, as you can already do with legacy windlight.

 

Edited by Whirly Fizzle
  • Like 2

Share this post


Link to post
Share on other sites

Thank you Whirly!    Good.   I figured that it would be the case that final control of the inworld view would be in the hands of the end user.    Just nice to know for sure.   

  • Like 1

Share this post


Link to post
Share on other sites

As someone who works on SL games I'd really really really dislike it if someone can simply locally override an experience applied windlight.  Ducking out of experience to shake off windlight is perfect behavior.  We always need an escape option.  But overriding a valid experience override that you are still part of is not cool.

Let's say You set a rather dark windlight in one combat map through the combat hud and experience because you want to make a certain combat map a unique experience.  Well what if players could just set it to bright sunny day at a click?  It defeats the point.  You can't just trust an honor system of no cheaters.  

Such power should of course be stapled to an experience.  And ducking out of the experience should shake off all the effects.  I can detect people leaving experience, I can react accordingly.  But just saying nuts to my game experience and injecting your own rules.  That's not cool.

If you don't like what the experience is doing to your windlight.  Don't be in it, or better yet explain to the person who coded it why you didn't like it.  I mean, we got spectator areas that don't require the combat meter and you can use whatever windlight you want for photography.

LL didn't pull punches with the force-sit capabilities for experience tools and made it pretty powerful.  I rather appreciate that they did that.  I'd like a way to keep a windlight locked on until someone leaves experience.

  • Like 1
  • Thanks 2

Share this post


Link to post
Share on other sites
On 11/23/2018 at 3:01 PM, Whirly Fizzle said:

You will always be able to override a parcel/region/experience forced environment locally.
On EEP viewers, it's as simple as choosing your environment setting in inventory, right clicking it & choosing "Apply only to myself".

I assume we will still be able to adjust a sky via the environment editor as well? Super useful when I'm out doing photos.

 

Edited by Marianne McCann
always typos

Share this post


Link to post
Share on other sites
On 11/25/2018 at 4:11 AM, Bellimora said:

As someone who works on SL games I'd really really really dislike it if someone can simply locally override an experience applied windlight.  Ducking out of experience to shake off windlight is perfect behavior.

There are pros and cons to this. Not everyone in SL is able bodied being the main one. One of my subs has epilepsy, it can be light triggered. I need to be very careful of any lighting effects I use at home and in play for this reason.  Quite a number of others are visually impared  and need to have certain screen settings to actually play SL. 

On the other hand, it is an equivelant right for the experience owner to perform an action they have permission for, as it is to set up a ban orb and keep all people with a certain attribute out of the region. "Don't like my rules, then you are free to leave"

 

It's a hard one to balance. One way to balance it way might be that grid wide environment is not allowed, it must be a land/region based setting. Then lock it. People who don't like the lighting chosen can leave and go elsewhere.

But the larger question here comes down to permissions. The current permissions system is not great. If I want to TP someone and set a suggested lighting I am also asking them for permission to force attach, permission to track their camera (look how many people turn off lookat in the TPV's to see how camera privacy is considered) and permission to force sit, and lock in place. Which of course means, I have been granted permission to apply any animation I desire.

If the permissions system were more granular, that i could ask for Teleport and Lighting only, it might be possible to also then say "grid wide lighting, or land only lighting"

Share this post


Link to post
Share on other sites

Can anyone call llGetEnvironment anywhere? If you can, environments are copyable. If you can't, you can't change just one thing locally.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, animats said:

Can anyone call llGetEnvironment anywhere? If you can, environments are copyable. If you can't, you can't change just one thing locally.

Valid point, these things are designed to be bought and sold. (One assumes without a transfer only permission)

Share this post


Link to post
Share on other sites
On 24 November 2018 at 5:11 PM, Bellimora said:

If you don't like what the experience is doing to your windlight.  Don't be in it, or better yet explain to the person who coded it why you didn't like it.

Because an experience creator being an "Artiste wannabe", does NOT guarantee that they are any damn good at editing windlights, and because it does not guarantee them a right to urinate on peoples graphics preferences.

"Hell with your non-20/20 vision, I am an ARTISTE with the Extra E, and I have a gawd given right to abuse your grant of permission to use a teleporter portal, as a weapon to grief you by setting your screen to too-damn-dark-to-see mode, because ARTISTE wannabe Integrity Entitlement! Don't like me screwing with your scene gamma and render divisor so you think you've developed cateracts? don't give permission for the bar stool to animate your avi!"

Now, you can promise till you are blue in the face that you won't do that, and that you will use the power "only for good", but just like the attach permissions and the sit permissions, reality is there are a whole mess of Zero-Talent Ego-Whores out there who will abuse forced windlights as they abuse forced tp, forced sit, forced attach, forced look, forced animate, etc., and just give people yet more reasons to say "accept experiences from strangers? HELL NO!".

Experiences are too damn ALL or NOTHING, and so for many they will be nothing.
 

  • Haha 1

Share this post


Link to post
Share on other sites
6 hours ago, Klytyna said:

Because an experience creator being an "Artiste wannabe", does NOT guarantee that they are any damn good at editing windlights, and because it does not guarantee them a right to urinate on peoples graphics preferences.

"Hell with your non-20/20 vision, I am an ARTISTE with the Extra E, and I have a gawd given right to abuse your grant of permission to use a teleporter portal, as a weapon to grief you by setting your screen to too-damn-dark-to-see mode, because ARTISTE wannabe Integrity Entitlement! Don't like me screwing with your scene gamma and render divisor so you think you've developed cateracts? don't give permission for the bar stool to animate your avi!"

Now, you can promise till you are blue in the face that you won't do that, and that you will use the power "only for good", but just like the attach permissions and the sit permissions, reality is there are a whole mess of Zero-Talent Ego-Whores out there who will abuse forced windlights as they abuse forced tp, forced sit, forced attach, forced look, forced animate, etc., and just give people yet more reasons to say "accept experiences from strangers? HELL NO!".

Experiences are too damn ALL or NOTHING, and so for many they will be nothing.
 

Would be interesting if you could opt into the specific parts of the experience you want and ignore those that you don't. Case in point a teleport. If it pops saying "OMGAWWD WE WANT ALL YOUR PERMISSIONS" then you could just tick the teleport box and ignore the rest and click submit. Or maybe go into the experience itself and de select the permissions you do not wish it to have.

Edited by chibiusa Ling
  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, chibiusa Ling said:

Would be interesting if you could opt into the specific parts of the experience you want and ignore those that you don't. Case in point a teleport. If it pops saying "OMGAWWD WE WANT ALL YOUR PERMISSIONS" then you could just tick the teleport box and ignore the rest and click submit. Or maybe go into the experience itself and de select the permissions you do not wish it to have.

Interesting yes, but you won't see it any time soon...

Witness the "Artiste-Wannabe with the Extra E" whine earlier in the thread when it was discovered that despite being able to set peoples screens to "bloody awful badly made windlight", that we, mere users, can give the artiste-wannabes the middle finger and change back to what suits us...

Can you imagine the level of Artiste-Wannabe Entitlement-Whine if we could pick and choose permissions to grant "experience abusing artiste-wannabes"?

On 23 November 2018 at 11:01 PM, Whirly Fizzle said:

You will always be able to override a parcel/region/experience forced environment locally

On 24 November 2018 at 5:11 PM, Bellimora said:

But overriding a valid experience override that you are still part of is not cool.

On 24 November 2018 at 5:11 PM, Bellimora said:

I'd like a way to keep a windlight locked on until someone leaves experience.






 

Share this post


Link to post
Share on other sites
3 hours ago, Klytyna said:

Interesting yes, but you won't see it any time soon...

Witness the "Artiste-Wannabe with the Extra E" whine earlier in the thread when it was discovered that despite being able to set peoples screens to "bloody awful badly made windlight", that we, mere users, can give the artiste-wannabes the middle finger and change back to what suits us...

Can you imagine the level of Artiste-Wannabe Entitlement-Whine if we could pick and choose permissions to grant "experience abusing artiste-wannabes"?
 

Yep. Im 100% with you on this. When it comes to wind light I usually turn it off after a few minutes by setting my SL time to midday. More power to the effect the region designer is trying to achieve but after 10 minutes of looking at either the SUPER DUPER AWESOME BLINDING WONDER LIGHT or the SUPER MURKY *squints* I CANT SEE SH*** light, I just want to switch back to midday and get on with whatever it is I am doing. If it was forced on me I would have to locate a more questionable way of accessing SL that allowed me to disable it xD. As for thinking that overriding an experience is not cool....they do realise that by accepting an experience your not bending straight over and presenting your rear and saying "Please oh sim owner....***** me as hard as you can". You are allowed to disable things and opt out entirely. 

I only keep experiences in my experience list whilst I am in the sim that is using them. After that I remove them and half the time I don't even accept them and If I want to teleport around il use the IT hud to locate where people are and port to them. Personal preference.

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, chibiusa Ling said:

I only keep experiences in my experience list whilst I am in the sim that is using them. After that I remove them and half the time I don't even accept them and If I want to teleport around il use the IT hud to locate where people are and port to them. Personal preference.

assuming that the experience-enabled parcel owner allows you to stay when you don't accept. Which seems to be the case so far for you

for roleplay games like Bellimora is talking about then what typically happens is that if we don't grant experience permissions, or remove ourselves from the experience, or detach the experience game HUD,  then we get sent home

what Bellimora is requesting as a roleplay/game host then they would like is to at least be able to detect if a player has changed their environment settings on the game arena parcel, and when so be able to eject them from the game/roleplay

i think this is a perfectly reasonable request.  LL experience-enabled games  like Linden Realms eject us from the game when we detach the game HUD. On the simple basis that we are are there to play the game. If not then bye.  People who play these types of games accept this happening to them as  normal and expected behaviour

  • Like 2

Share this post


Link to post
Share on other sites

Ellestones hit the nail on the head really.  

If someone is in the combat area I want them to have the shared windlight as everyone else.

If they are fighting in a shadowy nighttime environment I don't want them cheating themselves some midday sun.  So I use an experience to staple a windlight to them.

If they do not like the windlight and duck out of experience.  I will detect that via some easy to run LSL checks and my script will ask them nicely to get to the spectator area or get back in experience with a hud.  If they fail to comply I'll eject them.  If they don't take the hint I'll upgrade that to a ban.  Automation for the win.

I have accepted a heap of experiences.  None have played rough with me to date.  One experience tossed annoying messages when I tried to cam around and it had features that didn't make me comfortable (even though I didn't run afoul with them) so I simply just left the sim and moved on with my life.  If ones does I'll revoke it's privleges.  I'll lose maybe 1 minute of my life.  Considering all the time I saved by being lazy and not micromanaging all the accepted experiences I consider it a fair deal.

Granted I'm the sort of person who has no security or banlines on their house.  I reckon if someone irritates me I'll right click and ban them and get on with my life.

I mean if I wanted to make your life miserable I wouldn't staple a weird windlight to you, I'd rez an annoying prim to follow you while it emits a high pitched shriek while using llSEtTextureAnim to cycle through bright colors at epilepsy inducing frequencies.  But I wouldn't, because that's be an increadibly jerk move, and most people, thankfully, are not jerks.  It's just that when you do get a jerk boy its it memorable.

But that shouldn't hamstring our tools.  We don't need them hamstrung.  You have the power of no, you have the power of escape.

If a sim uses experiences in an annoying way, don't be there.  Don't try to bend the rest of the grid to your rules.

  • Like 1

Share this post


Link to post
Share on other sites

If you have to resort to enforced EEP and Experiences to *try* to prevent cheating in a game then you are doing it wrong.

What will be next? Control over our draw distance, throttle GPU and network speed and many other viewer features to prevent "cheating"?
Seriously, if you were serious about stopping cheating, there are no end of things you would have to be able to disable in the viewer, or you know, you could just lighten up and let people have fun and realise that kind of serious gaming where you need to lock things down so much is just not suitable for SL.

If it is really needed that badly, make a gamers viewer with much of the standard features ripped out and where you give total control to the game environment.  Sort of a RLV for games.  Let's not cripple the general purpose viewer for the rest of us.

SL is changing and in some ways it is not for the better.  This stuff is starting to seep into areas where it just doesn't matter (and never did) if people don't share the exact same Experience.  For example: the Winter Wonderland region that will teleport you home if you disable the Experience and you cannot even get there unless you accept, I might cheat at a snowball fight or a snowmobile race, basically cheat at having fun?  Really, WTF! I despair at people sometimes.

The more of these kinds of controls creep in, the more people will use them inappropriately, it is guaranteed.
Sure, I don't have to visit such places but then we wonder why people might prefer to stay in their sky boxes.
 

Edited by Gabriele Graves
  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, Bellimora said:

If someone is in the combat area I want them to have the shared windlight as everyone else.

If they are fighting in a shadowy nighttime environment I don't want them cheating themselves some midday sun.  So I use an experience to staple a windlight to them.

If they do not like the windlight and duck out of experience.  I will detect that via some easy to run LSL checks and my script will ask them nicely to get to the spectator area or get back in experience with a hud.  If they fail to comply I'll eject them

 

thinking about how this might be done.  Am not sure of the current status of the LSL commands but reading Inara Pey's last blogs about these then so far seems it is:

llGetEnvironment() which reads the parcel property and llSetAgentEnvironment() and llAdjustAgentEnvironment(). So all good on being able to get the parcel environment and set the players windlights using a script

LL may have already thought about being able to detect what environment setting a player has, but it wouldn't hurt to make a jira about it if you want Bellimora

if so then I would suggest a jira request for something like:  integer llSameEnvironment(key agent_id, key environment_id)

is similar to how llSameGroup() works. So not to be too nosey about visitors to the region. On the game arena we just want to know if the player is using the arena environment or not

a code example of how this can go:

key player = "some player uuid";
key environment = "our environment uuid";
integer warned;
integer game_on;

if (game_on)
{
   if (!llSameEnvironment(player, environment))
   {
      llSetAgentEnvironment(player, "our environment name", 1.0);
      if (warned)
      {
         llRegionSayTo(player, 0, "You are gone!");
	 llTeleportAgent(player, ...somewhere_not_here...);
         warned = FALSE;
      }
      else
      {
         llRegionSayTo(player, 0, "Environment change violation. You are warned.");
         warned = TRUE;    
      }   
   }
}       
else // person is not in the game
{
    // so do nothing
}

 

  • Thanks 1

Share this post


Link to post
Share on other sites
On ‎12‎/‎8‎/‎2018 at 2:26 AM, Gabriele Graves said:

If you have to resort to enforced EEP and Experiences to *try* to prevent cheating in a game then you are doing it wrong.

What will be next? Control over our draw distance, throttle GPU and network speed and many other viewer features to prevent "cheating"?
Seriously, if you were serious about stopping cheating, there are no end of things you would have to be able to disable in the viewer, or you know, you could just lighten up and let people have fun and realise that kind of serious gaming where you need to lock things down so much is just not suitable for SL.

If it is really needed that badly, make a gamers viewer with much of the standard features ripped out and where you give total control to the game environment.  Sort of a RLV for games.  Let's not cripple the general purpose viewer for the rest of us.

SL is changing and in some ways it is not for the better.  This stuff is starting to seep into areas where it just doesn't matter (and never did) if people don't share the exact same Experience.  For example: the Winter Wonderland region that will teleport you home if you disable the Experience and you cannot even get there unless you accept, I might cheat at a snowball fight or a snowmobile race, basically cheat at having fun?  Really, WTF! I despair at people sometimes.

The more of these kinds of controls creep in, the more people will use them inappropriately, it is guaranteed.
Sure, I don't have to visit such places but then we wonder why people might prefer to stay in their sky boxes.
 

Cripple the viewer?  Nope.  

You got to realize the core aspect of experiences that makes them awesome is you can nope your way out of them.

This is way better then the old-school permission system because once you said yes you had to relog.

Heck, for non-global experiences you can just step out of the parcel that has the experience and all your experience attachments fall off your avatar.

Me (Avatar for firestorm users) -> Experiences -> Allowed tab, drop it.  DONE.  Not even a minute of work.  And if you look there's this handy dandy little "report" button for experiences that got downright abusive with you.  So you can be rid of the experience and report the creator in one fell swoop.  There's a block button too so you'll never get another permission prompt ever again.

If you aren't sure what did what there's a rather convenient events tab which spells out who did what to you so you can dump them.

When they do that llAgentInExperience() will toss a FALSE.  As a programmer I can ask them to get back in experience or get to the spectator booth.

There was apparent wailing and gnashing of teeth when LL added the ability to force sit and LOCK an avatar to an object making them unable to rise unless the script said they may.  And everything seems fine.  If someone really gets abusive with it there's a "report"

IF this were RLV you'd have to toggle an option and then reboot your entire viewer and it would be kludgy and you'd have to use specific viewers which would remove entire portions of your user base.  And that reboot would disable every other RLV thingy not just the offending object.  Experiences are way superior.  Finer control for the end user and the ability to take abusive elements to task.

The ability of these tools do not need to be hamstrung.  All the power is at your fingertips.  The power of nope is readily yours.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×