LSL EEP Scripting Documentation

[Rider Linden]

The LSL wiki has not yet been fully updated with the new functions.  I'm posting them here for reference. 

 

---

llReplaceAgentEnvironment

Override the entire environment applied to an agent.  

Function

Integer llReplaceAgentEnvironment(key agent_id, float transition, string environment)

 

The llReplaceAgentEnvironment function overrides the current region and parcel environment seen by an agent. The new environment persists until the agent crosses to a new region or this function is called with the NULL_KEY or empty string for the particular agent. This function must be executed as part of an experience. 

• agent_id: The key for an agent in the region.  The agent must be in the region and must be participating in the experience. 
• transition: The number of seconds over which to transition to the new settings.
• env: The name of an environmental setting in the objects inventory or the asset ID for an environment.

Return Values

Value	Constant	Description
	1	The agent has been instructed to change their environment.
ENV_NOT_EXPERIENCE	-1	The script is not running as part of an experience with a valid experience key.
ENV_NO_EXPERIENCE_PERMISSION	-2	The agent has not granted permission.
ENV_NO_ENVIRONMENT	-3	The environment inventory object could not be found.
ENV_INVALID_AGENT	-4	Unable to find specified agent.

Caveats

• The agent's viewer may choose to ignore this command.
• An environment set locally on the viewer will override any environment set from this function
• If a UUID is passed as the environment parameter and that UUID does not specify an environment setting, the viewer will quietly ignore the instruction.

 

---

llSetAgentEnvironment

 

Rider Linden

Last modified Jan 16, 2019

 

Sets the environment values for an agent.  

Function

Integer llSetAgentEnvironment(key agent_id, float transition, list params)

 

This function sets environment values for an individual agent in an experience.  The changes to the environment persist until the agent moves to a new region or llSetAgentEnvironment is called for an agent with an empty list.

• agent_id: The key for an agent in the region.  The agent must be in the region and must be participating in the experience. 
• transition: The number of seconds over which to transition to the new settings.
• 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. 

Return Values

Value	Constant	Description
	1	The agent has been instructed to change their environment.
ENV_NOT_EXPERIENCE	-1	The script is not running as part of an experience with a valid experience key.
ENV_NO_EXPERIENCE_PERMISSION	-2	The agent has not granted permission.
ENV_INVALID_AGENT	-4	Unable to find specified agent.
ENV_INVALID_RULE	-5	There was an issue with one of the rules.

Caveats

Note.  The list of valid parameters differs from those available for llGetEnvironment.

Parameters

parameter		return values	description
SKY_CLOUDS	2	vector color, float coverage, float scale, float variance, vector scroll, vector density, vector detail	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.
SKY_CLOUD_TEXTURE	19	string texture_ident	Name of item in inventory or UUID for texture to be used for the clouds.
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_colorfloat size, float focus	Glow color applied to the sun and moon.
SKY_MOON	9	rotation rot, float scale, float brightness	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
SKY_MOON_TEXTURE	20	string texture_ident	Name of texture in inventory or UUID for texture to be used for the moon.
SKY_STAR_BRIGHTNESS	13	float brightness
SKY_SUN	14	rotation rot, float scale, vector sun_color	Detailed sun information rot: The current rotation applied to the sun. scale: The current scale applied to the sun's texture sun_color:
SKY_SUN_TEXTURE	21	string texture_ident	Name of texture in inventory or UUID for texture to be used for the sun.
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_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
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_NORMAL_TEXTURE	107	string texture_ident	Name of texture in inventory or UUID of texture to be used for the water normal.
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.

 

---

llGetEnvironment

 

Rider Linden

Last modified Jan 16, 2019

 

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_colorfloat size, float focus	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_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, float 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.

 

 

---

llGetSunDirection/llGetRegionSunDirection

Returns a normalized vector to the current sun position at the location of object containing the script.  llGetSunDirection is the vector to the parcel's sun, llGetRegionSunDirection is the vector to region's sun. If there is no custom environment set for the current parcel llGetSunDirection returns the direction to the region's sun. These functions are altitude aware.

Function

vector llGetSunDirection() vector llGetRegionSunDirection()

See Also

• llGetMoonDirection/llGetRegionMoonDirection
• llGetSunRotation/llGetRegionSunRotation
• llGetMoonRotation/llGetRegionMoonRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayOffset//llGetRegionDayOffset

 

---

llGetMoonDirection/llGetRegionMoonDirection

Returns a normalized vector to the current moon position at the location of object containing the script.  llGetMoonDirection is the vector to the parcel's moon, llGetRegionSunDirection is the vector to region's moon. If there is no custom environment set for the current parcel llGetMoonDirection returns the direction to the region's moon. These functions are altitude aware.

Function

vector llGetMoonDirection() vector llGetRegionMoonDirection()

See Also

• llGetSunDirection/llGetRegionSunDirection
• llGetSunRotation/llGetRegionSunRotation
• llGetMoonRotation/llGetRegionMoonRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayOffset//llGetRegionDayOffset

 

---

llGetSunRotation/llGetRegionSunRotation

Return the rotation applied to the sun for the parcel or region at the location of the object containing the script.  These function are altitude aware and so will pick up the sun for their current track. llGetRegionSunRotation returns the rotation applied at the region level, llGetSunRoation does the same for the parcel.  If there is no custom environment applied to parcel llGetSunRotation returns the same value as llGetRegionSunRotation.

Function

rotation llGetSunRotation() rotation llGetRegionSunRotation()

See Also

• llGetSunDirection/llGetRegionSunDirection
• llGetMoonDirection/llGetRegionMoonDirection
• llGetMoonRotation/llGetRegionMoonRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayOffset//llGetRegionDayOffset

 

---

llGetMoonRotation/llGetRegionMoonRotation

Return the rotation applied to the moon for the parcel or region at the location of the object containing the script.  These function are altitude aware and so will pick up the moon for their current track. llGetRegionMoonRotation returns the rotation applied at the region level, llGetMoonRoation does the same for the parcel.  If there is no custom environment applied to parcel llGetMoonRotation returns the same value as llGetRegionMoonRotation.

Function

rotation llGetMoonRotation() rotation llGetRegionMoonRotation()

See Also

• llGetSunDirection/llGetRegionSunDirection
• llGetMoonDirection/llGetRegionMoonDirection
• llGetSunRotation/llGetRegionSunRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayOffset//llGetRegionDayOffset

 

---

llGetDayLength/llGetRegionDayLength

Return the number of seconds in the day cycle applied to the current parcel and region. llGetDayLength returns the number of seconds for the current parcel, llGetRegionDay length is the number of seconds in the day cycle applied to the entire region.

Function

integer llGetDayLength() integer llGetRegionDayLength()

See Also

• llGetSunDirection/llGetRegionSunDirection
• llGetMoonDirection/llGetRegionMoonDirection
• llGetSunRotation/llGetRegionSunRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayOffset//llGetRegionDayOffset

 

---

llGetDayOffset/llGetRegionDayOffset

Return the number of seconds added to the current time before calculating the current environmental time for the parcel or the region.  llGetDayOffset returns the value for the current parcel, llGetRegionDayOffset produces the same value for the entire region.

Function

integer llGetDayOffset() integer llGetRegionDayOffset()

See Also

• llGetSunDirection/llGetRegionSunDirection
• llGetMoonDirection/llGetRegionMoonDirection
• llGetSunRotation/llGetRegionSunRotation
• llGetDayLength/llGetRegionDayLength
• llGetDayLength/llGetRegionDayLength

 

---

llGetTimeOfDay/llGetRegionTimeOfDay

 

Rider Linden

Nov 08, 2018

 

Gets the number of seconds, with sub-second precision, since environmental midnight.  llGetTimeOfDay returns this value for the current parcel, llGetRegionTimeOfDay returns the seconds since midnight for the entire region.

Function

float llGetTimeOfDay() float llGetRegionTimeOfDay( )

 

Caveats

This function previously assumed a 4 hour day.  Day length is now configurable for regions and parcels. 

Edited February 15, 2019 by Rider Linden

[Ivanova Shostakovich]

   Yay! We get custom Environment transition times!

[KT Kingsley]

Just noticed that both in the OP and in the wiki, the description for the SKY_SUN parameter for llGetEnvironment refers to "moon" rather than "sun" in the last four bulleted items.

[Rider Linden]

On 3/23/2019 at 5:29 PM, KT Kingsley said:

Just noticed that both in the OP and in the wiki, the description for the SKY_SUN parameter for llGetEnvironment refers to "moon" rather than "sun" in the last four bulleted items.

Thank you KT.  I've fixed the documentation. 

[Wulfie Reanimator]

I noticed llSetAgentEnvironment doesn't have the same caveats as llReplaceAgentEnvironment.

Can the environment settings from llSetAgentEnvironment be overridden locally, or ignored by the viewer?

It would be very functionally useful to be able to force a specific environment onto everybody within a parcel of an Experience, particularly for the purposes of games, combat, or roleplay. (For example, a foggy environment can be used to limit everybody's field of view fairly, same with having a dark/night environment. It could also facilitate roleplay by having all of the characters adapt to the intended time of day, rather than individual preference.)

Edited June 15, 2019 by Wulfie Reanimator

[Coffee Pancake]

35 minutes ago, Wulfie Reanimator said:

It would be very functionally useful to be able to force a specific environment onto everybody within a parcel of an Experience, 

If you have everyone on a parcel in an experience, use a temp attachment as a proxy to sync.

[Wulfie Reanimator]

6 minutes ago, CoffeeDujour said:

If you have everyone on a parcel in an experience, use a temp attachment as a proxy to sync.

I couldn't accept that as a viable alternative if the intention was a controlled environment. (It's better than nothing, but not functional.) People could still override their settings after the sync to "cheat" and it would require some back-and-forth talk between each avatar's attachments and some central object, which would have to rez new temp attachments if no response is heard within some margin of error.

Edited June 15, 2019 by Wulfie Reanimator

[Mollymews]

15 minutes ago, Wulfie Reanimator said:

 "cheat"

there was some chat a while ago between arena game makers, somewhere way down in this forums, about players cheating the EEP on the arena. Like when the parcel arena gameplay calls for say a night environment and an arena player overrides the night to day to gain an advantage

the idea that came out of the chat, was that there be something similar to llSameGroup().  The idea in its simplest form was llSameEnvironment(key id).  Return TRUE when the player id has the same EEP as the parcel. FALSE if they do not.  When FALSE then llSetAgentEnvironment(). Enable polling in the LSL scripted gameplay engine. On the 2nd occasion FALSE then warn the player and llSetAgentEnviromnent() again.  On the 3rd occasion FALSE then eject the cheater from the arena

not sure if this was ever submitted to LL as a JIRA request. Seemed like a good idea to me tho

 

[Coffee Pancake]

Avoiding "cheats" isn't practically possible in SL, it's not even seen as cheating by users of game based RP systems because "everyone does it". Routinely fiddling with rendering types, bounding boxes, wireframe and lookats to gain some slight perceived advantage is just what people do, and if an experience EEP was forced there would be very quickly be an option in a certain third party viewer to "correct" that in response to a torrent of outraged residents screaming about the nerve of anyone imposing a level playing field ( ... see the push back restricting flight gets).

Attempts have been made in the past do do this with RLV, but what happens in practicality is those with power refuse point blank to use it, while using that power to demand everyone else does. 

I would absolutely be in favor of experience tools being all on or all off with no fuzzy middle ground, developing complicated anti cheat mechanics is a major hindrance to game development in SL.

 

[Mollymews]

6 minutes ago, CoffeeDujour said:

I would absolutely be in favor of experience tools being all on or all off with no fuzzy middle ground, developing complicated anti cheat mechanics is a major hindrance to game development in SL.

 

yes agree that arms races never end well 

[Gabriele Graves]

10 hours ago, Wulfie Reanimator said:

It would be very functionally useful to be able to force a specific environment onto everybody within a parcel of an Experience, particularly for the purposes of games, combat, or roleplay.

DO NOT WANT.  Nobody should be able to override my viewer settings.  You cannot guarantee it would be seen anyway even if you get a "force" feature, we can always de-render the sky or turn off ALM or even be there on a text viewer.  I swear to all that is unholy I will learn how to make my own viewer and take it out if forcing is attempted.

Edited June 15, 2019 by Gabriele Graves
took out an extra "even".

[Coffee Pancake]

1 hour ago, Gabriele Graves said:

DO NOT WANT.  Nobody should be able to override my viewer settings.  You cannot guarantee it would be seen anyway even if you get a "force" feature, we can always de-render the sky or turn off ALM or even be there on a text viewer.  I swear to all that is unholy I will learn how to make my own viewer and take it out if forcing is attempted.

For the context of creating a game environment. You either accept the rules of the game as provided and leave your god powers at the door, or you don't play .. which is fine, no one can make you participate. Anything else would be akin to playing greedy and letting you pick your own dice rolls.

Strong experience based rules are a fundamental requirement. The are not to impose on your freedom, they are to ensure all players have a uniform experience, that they can all see the same, move the same, jump the same, cam the same.

[Ana Stubbs]

2 hours ago, CoffeeDujour said:

For the context of creating a game environment. You either accept the rules of the game as provided and leave your god powers at the door, or you don't play .. which is fine, no one can make you participate. Anything else would be akin to playing greedy and letting you pick your own dice rolls.

Strong experience based rules are a fundamental requirement. The are not to impose on your freedom, they are to ensure all players have a uniform experience, that they can all see the same, move the same, jump the same, cam the same.

And I would like to use experiences to provide enviromental effects that go along with what is happening on the sim... so that if the sun is supposed to rise at the end of a sunrise service, it actually will.

Noone can force you to join an experience, that is your free choice. You can attend my church without ever joining one. But if it were possible to opt out while in the experience, i guarantee that people would do so (deliberately or accidentally) and then complain bitterly at the end that it wasn't what was advertised. From a technical support perspective it would be much much harder.

Most of our visitors are not technically minded, so currently we have to go around every single person, find out what viewer they're using, find out how to set "use region windlight" in that viewer, explain how to do it, and how to set it back off when they leave... a simple Yes/No option to cede control to an Experience would be a dream.

[Gabriele Graves]

6 hours ago, CoffeeDujour said:

For the context of creating a game environment. You either accept the rules of the game as provided and leave your god powers at the door, or you don't play .. which is fine, no one can make you participate. Anything else would be akin to playing greedy and letting you pick your own dice rolls.

Strong experience based rules are a fundamental requirement. The are not to impose on your freedom, they are to ensure all players have a uniform experience, that they can all see the same, move the same, jump the same, cam the same.

I am aware of this and don't care about games as they will not affect me.  Can you guarantee that this feature will only be used by game makers for their games though?  I doubt it.  The moment it is available, every control freak on the grid will use it regardless of the type of place they have for no good reason other than "because I can".

[Gabriele Graves]

4 hours ago, Ana Stubbs said:

And I would like to use experiences to provide enviromental effects that go along with what is happening on the sim... so that if the sun is supposed to rise at the end of a sunrise service, it actually will.

Noone can force you to join an experience, that is your free choice. You can attend my church without ever joining one. But if it were possible to opt out while in the experience, i guarantee that people would do so (deliberately or accidentally) and then complain bitterly at the end that it wasn't what was advertised. From a technical support perspective it would be much much harder.

Most of our visitors are not technically minded, so currently we have to go around every single person, find out what viewer they're using, find out how to set "use region windlight" in that viewer, explain how to do it, and how to set it back off when they leave... a simple Yes/No option to cede control to an Experience would be a dream.

There is nothing wrong with offering this and that sounds really nice but not so useful if I want to take pictures under the moonlight which might equally be as awesome at your place.  Some regions today *suggest* what settings that will look the best but they do not and cannot force it.  This is ideal and does not cause a grid-pocalypse in any way.  That is what real choice looks like, to not have to accept the settings but still be allow to stay and visit the area with whatever I want to use even though it may not fit with your idea of what is "best".  What is the harm in that I miss your sunrise if that is my choice?  You would never even know and I may have visited a thousand times already and seen it.  My points above above still stand, even with a force feature, I would still be able to disrupt what you want to force on me should I choose and you would still never know.  So what is the point of going to ridiculous lengths to force it?

It is best to suggest, nothing more in my opinion.

Edit: I realise you said that people can visit without accepting the Experience and I applaud you for that.  Even if someone accepted the experience, what would it really matter?.  You get a complaint, you say "You turned the sunrise off" end of issue.  The points I made above are really about being forced with EEP and Experiences in general and not "your" region.  You can take to "You" and "Your" to be generally anyone's place.

Edited June 15, 2019 by Gabriele Graves
Clarifying my thoughts.

[Wulfie Reanimator]

40 minutes ago, Gabriele Graves said:

I am aware of this and don't care about games as they will not affect me.  Can you guarantee that this feature will only be used by game makers for their games though?  I doubt it.  The moment it is available, every control freak on the grid will use it regardless of the type of place they have for no good reason other than "because I can".

The solution to this is to just not accept the Experience permission prompt, or revoke the Experience. Experiences are tied to land, so your EEP will be unaffected as soon as you leave the area.

You can also report Experiences for abusive behavior, if you feel truly violated by the particular EEP applied by an Experience you just joined.

The argument of "my personal freedom" is quite silly anyway and can be used right back at you. A land owner can make joining an Experience a requirement for entry (and I've seen sims that do this), but who are you to tell that land owner what to do with their land? They're paying for it -- and Premium -- so they're more than within their rights to force EEP on their visitors if it suits them. You don't seem interested in that kind of thing, so they will lose you as a visitor. That's okay.

Edited June 15, 2019 by Wulfie Reanimator

[Ana Stubbs]

13 minutes ago, Gabriele Graves said:

There is nothing wrong with offering this and that sounds really nice but not so useful if I want to take pictures under the moonlight which might equally be as awesome at your place.  Some regions today *suggest* what settings that will look the best but they do not and cannot force it.  This is ideal and does not cause a grid-pocalypse in any way.  That is what real choice looks like, to not have to accept the settings but still be allow to stay and visit the area with whatever I want to use even though it may not fit with your idea of what is "best".  What is the harm in that I miss your sunrise if that is my choice?  You would never even know and I may have visited a thousand times already and seen it.  My points above above still stand, even with a force feature, I would still be able to disrupt what you want to force on me should I choose and you would still never know.  So what is the point of going to ridiculous lengths to force it?

It is best to suggest, nothing more in my opinion.

No harm at all. The forcing is there for people who WANT to see it, and it's entirely opt-in. If you opt-in by mistake, you can always opt-out again.

Noone is going to come to your house and physically force you to opt in, and if they did, you would be best to call the police.

Perhaps a better analogy would be the RLV options in some viewers. They allow ways to force someone to remove their clothing, to blind them, to control their movement - all fairly intrusive actions. But the user has to opt-in to being controlled. Thankfully, noone can walk up to you in SL and force you to be their BDSM sex slave unless you first enable those options.

[Gabriele Graves]

1 minute ago, Wulfie Reanimator said:

The solution to this is to just not accept the Experience permission prompt, or revoke the Experience. Experiences are tied to land, so your EEP will be unaffected as soon as you leave the area.

You can also report Experiences for abusive behavior, if you feel truly violated by the particular EEP applied by an Experience you just joined.

That is still not even remotely a good enough reason in my opinion to give greater powers over the viewer preferences.  They are called preferences for a reason.  There should be limits to the "on my land" argument when it comes to what I view or are you also going to advocate that I can no longer derender objects or avatars I do not want to see whilst I am on your land?  This is a long road to travel and much we can do in the viewer today would have to be disabled "on your land".

Besides, this would circumvent the Experience permissions as you have said.  Why would LL make Experiences need permissions that can then be overridden?  That doesn't give a good message in my opinion.

[Gabriele Graves]

6 minutes ago, Ana Stubbs said:

No harm at all. The forcing is there for people who WANT to see it, and it's entirely opt-in. If you opt-in by mistake, you can always opt-out again.

Noone is going to come to your house and physically force you to opt in, and if they did, you would be best to call the police.

Perhaps a better analogy would be the RLV options in some viewers. They allow ways to force someone to remove their clothing, to blind them, to control their movement - all fairly intrusive actions. But the user has to opt-in to being controlled. Thankfully, noone can walk up to you in SL and force you to be their BDSM sex slave unless you first enable those options.

Great, that is the idea, no forcing anything.  However, that is not what is being asked for in this derail.  Wulfie is asking for the very opposite, to be able to force EEP without permissions.

[Wulfie Reanimator]

4 minutes ago, Gabriele Graves said:

Wulfie is asking for the very opposite, to be able to force EEP without permissions.

What? NO. That's ridiculous.

The functions introduced in this thread require Experience permissions to work at all. I did not ask to be able to use them without permission. I was asking whether they differ from each other, because that is unclear from the specifications and it would be useful.

Edited June 15, 2019 by Wulfie Reanimator

[Gabriele Graves]

1 minute ago, Wulfie Reanimator said:

What? NO. That's ridiculous.

The functions introduced in this thread REQUIRE Experience permissions to work. I did not ask to be able to use them without permission. I was asking whether they differ from each other, because that would be useful.

Then I apologise, I must have read it incorrectly and misinterpreted what you said.

[Gabriele Graves]

19 hours ago, Wulfie Reanimator said:

I noticed llSetAgentEnvironment doesn't have the same caveats as llReplaceAgentEnvironment.

Can the environment settings from llSetAgentEnvironment be overridden locally, or ignored by the viewer?

It would be very functionally useful to be able to force a specific environment onto everybody within a parcel of an Experience, particularly for the purposes of games, combat, or roleplay. (For example, a foggy environment can be used to limit everybody's field of view fairly, same with having a dark/night environment. It could also facilitate roleplay by having all of the characters adapt to the intended time of day, rather than individual preference.) 

I think the misinterpretation happened because you mentioned "within a parcel of an Experience" which to me indicated a parcel that has an Experience present and not necessarily "people in the experience" which would indicate people have accepted the Experience.  Again, I apologise.

Edited June 15, 2019 by Gabriele Graves
corrected quote.

[Wulfie Reanimator]

4 minutes ago, Gabriele Graves said:

Then I apologise, I must have read it incorrectly and misinterpreted what you said.

Then let's go all over this again, just in case...

On 1/24/2019 at 1:11 AM, Rider Linden said:

llReplaceAgentEnvironment

This function must be executed as part of an experience.

Caveats

• The agent's viewer may choose to ignore this command.
• An environment set locally on the viewer will override any environment set from this function
• If a UUID is passed as the environment parameter and that UUID does not specify an environment setting, the viewer will quietly ignore the instruction.

llSetAgentEnvironment

This function sets environment values for an individual agent in an experience.

Caveats

• Note.  The list of valid parameters differs from those available for llGetEnvironment.

The real difference between these functions is that one uses an EEP asset, the other uses a list of parameters. But notice how llSetAgentEnvironment does not have the two big caveats on it. I wanted to know whether this is a case of incomplete documentation, or those big caveats don't affect llSetAgentEnvironment.

I accept the apology though.

[Lucia Nightfire]

AFAIK, the claim that "an agent's viewer may choose to ignore this command" simply means the target must be participating in the same experience as the script making the call for it to be effective else there is an error code generated with the function's return type. llRAE() and llSAE() have the same behavior in that regard.

[Coffee Pancake]

3 hours ago, Gabriele Graves said:

I am aware of this and don't care about games as they will not affect me.  Can you guarantee that this feature will only be used by game makers for their games though?  I doubt it.  The moment it is available, every control freak on the grid will use it regardless of the type of place they have for no good reason other than "because I can".

You seem to be operating under the misconception that you have a right to go wherever and do whatever you like, in reality you are a guest and should your host politely make a request, the only right you have is to leave.