Jump to content

LSL EEP Scripting Documentation


You are about to reply to a thread that has been inactive for 444 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

1 minute ago, CoffeeDujour said:

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. 

No, not at all.  You appear to have the wrong impression.  If I am not wanted at a place due to my choices I will gladly leave.  However if I am allow to stay, it does not give the land owners absolute rights to my viewer.  I have covered this in another thread on the flying topic.  There is a line where the rights of the land owner meet the rights of the viewer operator.  The land owner may decide to eject/ban but at that point, that is all the power they should have over my viewer preferences.

  • Thanks 1
  • Confused 1
Link to comment
Share on other sites

22 minutes ago, CoffeeDujour said:

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. 

Please bear in mind that when I am engaging in discussions like this about EEP and Experiences, I feel it is really a discussion about where the line between land owners rights and viewer operator rights should be.  Some of these features asked for do not exist and so there is no existing right just a potential for one to be created and abused.  I am here to put the case that there should be limits on what can automatically applied or overridden for the viewer/avatar.  This is to make my voice heard for the record so that hopefully these can be considered along with the cases that are often being made have features automatically applied without consent.  Obviously Wulfie was not doing that here and that is my only misconception.

Let me make an example to try to show you where I am coming from better:

Whilst any land owner can "inform" all visitors that they must go naked on their sim or leave and that is their right.  If they petitioned LL to create a feature to automatically do this when you teleport to their land, hopefully we could agree that those petitioners are asshats and that there is no way that LL should add such a feature to do this automatically.  Even though some land owners (such as naked beaches) may have a good reason to *ask*, it should not be something to be applied to an avatar but should always be that the avatar has to take steps to comply or leave.

If you don't agree with the above statement then we have no common ground for further discussion on this topic.

Edited by Gabriele Graves
typos
  • Thanks 1
Link to comment
Share on other sites

You have a choice to accept the experience and participate, or not and have a nice a day.

Being able to accept an experience and then cherry pick the parts you like is not a tenable situation. You're either in and agree to be bound by the experience's rules, or you don't. It is impossible to create anything that requires a consistent set of rules if those rules may or may not apply on the whims of the participants.

You may opt out of the entire experience at any time, but don't presume for one moment that doing so entitles you to anything more than your freedom to the previously mentioned nice day. Any allowances are the purview of the land owner and should not be hard baked into the scripting system, if they wish to add exceptions to their systems to cater to you, they are more than able to do so.

10 minutes ago, Gabriele Graves said:

Whilst any land owner can "inform" all visitors that they must go naked on their sim or leave and that is their right.  If they petitioned LL to create a feature to automatically do this when you teleport to their land........

If you are entering a game type experience where you play the role of a dinosaur, removing your entire avatar and replacing it with the required mesh is a necessity.

Cutesy demands this not be done immediately following a TP and with informed consent, however, once given you should not have the capability while in that experience to switch the dinosaur for any other random thing you like. Nor should you have the capability to change the lighting, force enable flight, etc.

Experiences can easily be reported in the case of abuse. 

  • Like 1
Link to comment
Share on other sites

On 6/16/2019 at 2:16 AM, Lucia Nightfire said:

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.

I'm not so sure.   This is the description of the function's return value 1:

Quote

The agent has been instructed to change their environment.

That simply tells me that the instruction has been successfully sent (and that it didn't fail for one of four possible reasons, like script wasn't set to the experience, or the list of settings was malformed).   It doesn't tell me if it was actually received and, if it was, what happened next.

I will have to do some tests (or possibly bug someone who can give us a definitive answer) but it seems to me that if I  go to World>Environment and uncheck the option "Used Shared Environment" in the EEP viewer, then it would not be unreasonable to expect my viewer to ignore all external attempts to change my personal settings, whether those of the region's own windlight settings or those of scripted objects.   Possibly that's what -2, "The agent has not granted permission" (ENV_NO_EXPERIENCE_PERMISSION) means.

ETA 1:  This is informed speculation, but I suspect the fact that this function returns an integer value rather than triggering an experience_permissions event implies that while the function may the experience tools technology at the server level to communicate with the viewer,  it doesn't rely on experience permissions, so the usual expectations based on our experience of experience tools may not be particularly applicable.    But I don't know about that.   

I will try, by one means or another, to find out.

ETA 2:  Furthermore,  when an experience_permissions call fails, that triggers an experience_permissions_denied() event, with a far longer list of possible reasons, including 4, XP_ERROR_NOT_PERMITTED ("Experience permissions were denied by the user") .    That really strengthens my feeling that this function shouldn't be expected to behave in the same way as anything called in the experience_permissions() event as a result of an llRequestExperiencePermissions() call.

 

Edited by Innula Zenovka
  • Thanks 1
Link to comment
Share on other sites

  • Lindens

In all cases, the Linden Lab EEP viewer allows the agent to override any simulator applied environment setting.  This includes environments applied to the region, the parcel, and through scripts functions such as llSetAgentEnvironment and llReplaceAgentEnvironment.  The simulator is unaware of any such override and can not track it through llGetEnvironment. This function works only to report on the state of the parcel or region settings.

 

  • Thanks 5
Link to comment
Share on other sites

  • Lindens
On 6/15/2019 at 4:44 PM, Wulfie Reanimator said:

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 have corrected this oversight on the wiki.

  • Thanks 5
Link to comment
Share on other sites

1 hour ago, Rider Linden said:

In all cases, the Linden Lab EEP viewer allows the agent to override any simulator applied environment setting.  This includes environments applied to the region, the parcel, and through scripts functions such as llSetAgentEnvironment and llReplaceAgentEnvironment.  The simulator is unaware of any such override and can not track it through llGetEnvironment. This function works only to report on the state of the parcel or region settings.

 

Use case .. There is little point in making a spooky haunted house if everyone can just SHIFT+CTRL+Y the moment they land, and then play the game with none of the atmosphere. This ends in a script that jackhammers the environment to force a shared experience.

Lighting and atmospherics is one of the only major paint brushes we have for creating locations in SL, the only optional EEP lighting should be that which is simply applied to the parcel not experience tools.

It would be better if a script could tell and use that as it's que that a user is taking a break (for whatever reason) and pause.

  • Like 1
Link to comment
Share on other sites

Though if someone wants to ruin the experience of going round the spooky haunted house with their local lighting set to midday.  then isn't that their problem rather than yours?

I can see it being an issue in combat RP, where participants can gain an unfair advantage by tinkering with their settings and thus seeing far better than they should during a night attack, but is it such a big deal otherwise?

Link to comment
Share on other sites

On 6/15/2019 at 11:26 PM, CoffeeDujour said:

Cutesy demands this not be done immediately following a TP and with informed consent, however, once given you should not have the capability while in that experience to switch the dinosaur for any other random thing you like.

I would be afraid it is a trick, and they will send a giant asteroid while I’m a Dinosaur. 

Link to comment
Share on other sites

  • Lindens

In seriousness... the minimum distance between two frames in a day cycle is 2.5%.  This works out to 6 minutes for a 4 hour day cycle.

You could move the moon to near the zenith with a small scale factor and have it move to somewhere near the nadir with a large scale factor.  This would give the appearance of a large rock(s) hurtling to the earth (it would cross the horizon at roughly the 3 minute mark.)  If you had the sun and moon alternating positions (making the heavenly body unnoticeable when it reset to the zenith)  you would certainly be able to simulate your own personal Perseids Meteor Shower.  

  • Like 3
  • Thanks 2
  • Haha 1
Link to comment
Share on other sites

  • 6 months later...
On 12/25/2019 at 12:49 PM, Desiree Moonwinder said:

Is there any way have two planets?  I am looking to model the Three Moons of Gor.  I don't see any way to do it without using the sun for one. 

If you don't need them to move independently, you could make one large texture with both planets and use that for the moon texture.

(although, being able to add more independently moving objects through the sky would be great.)

  • Like 1
Link to comment
Share on other sites

14 minutes ago, Penny Patton said:

If you don't need them to move independently, you could make one large texture with both planets and use that for the moon texture.

(although, being able to add more independently moving objects through the sky would be great.)

Is it a flat projection planet texture?  If so, that will work. 

I don't see a planet texture in the script guide, and the sun and moon textures seem to be wrapped around spheres. 

Edited by Desiree Moonwinder
Link to comment
Share on other sites

  • Lindens
On 12/28/2019 at 5:07 PM, Desiree Moonwinder said:

Is it a flat projection planet texture?  If so, that will work. 

I don't see a planet texture in the script guide, and the sun and moon textures seem to be wrapped around spheres. 

The sun and the moon are flat images on the sky dome.

The only planet textures that I included in the library were one of Jupiter and "Blue Marble".  But any that you make yourself should work.

  • Thanks 2
Link to comment
Share on other sites

On 1/6/2020 at 12:13 PM, Rider Linden said:

The sun and the moon are flat images on the sky dome.

The only planet textures that I included in the library were one of Jupiter and "Blue Marble".  But any that you make yourself should work.

There is no SKY_PLANET_TEXTURE in the API.  There are: SKY_CLOUD_TEXTURE, SKY_MOON_TEXTURE, SKY_SUN_TEXTURE, WATER_NORMAL_TEXTURE

Link to comment
Share on other sites

  • 4 months later...

Ok, i am disappointed. I was waiting over a year for EEP to happen. I now got my hands on the functions llReplaceAgentEnvironment and llSetAgentEnvironment  and then i learn that these only work when the user has *not* chosen any other setting? because as soon as the user choses any other light setting, the option "used shared environment" in the viewer is disabled. and i have, as far as i can see, no chance to enable that via script for my user again.

That sucks. there is no other word for that.

If a user has joined my experience then they already agreed by that to accept all the permission requests that come with the Experience. Why can they now simply disable this part with one mouseclick? Most of them will do so involuntarily, by accident - and are then out of that EEP -ascpect.

I was hoping for a much more immersive experience to be scripted for my visitors but if it stays this way i will just bin my projects on that aspect.

Edited by Tantrica Banana
Link to comment
Share on other sites

Tantric, when EEP was being designed there was some discussion about

integer llSameEnvironment(key agent_id)

which would return TRUE when the agent's environment is the same as the parcel environment. FALSE otherwise

if FALSE then set with llSetAgentEnvironment()

if still FALSE after this then do something to them. Like warn, prevent gameplay, eject, etc

but Linden never gave it to us.  Maybe we might get some day one day

Link to comment
Share on other sites

  • 1 year later...
On 6/11/2020 at 4:13 PM, Tantrica Banana said:

Ok, i am disappointed. I was waiting over a year for EEP to happen. I now got my hands on the functions llReplaceAgentEnvironment and llSetAgentEnvironment  and then i learn that these only work when the user has *not* chosen any other setting? because as soon as the user choses any other light setting, the option "used shared environment" in the viewer is disabled. and i have, as far as i can see, no chance to enable that via script for my user again.

That sucks. there is no other word for that.

If a user has joined my experience then they already agreed by that to accept all the permission requests that come with the Experience. Why can they now simply disable this part with one mouseclick? Most of them will do so involuntarily, by accident - and are then out of that EEP -ascpect.

I was hoping for a much more immersive experience to be scripted for my visitors but if it stays this way i will just bin my projects on that aspect.

I also face this problem as well. and to use llReplaceAgentEnvironment,  we have to ask permission everytime they tp to sim,   so what if I do llrepeatscan agent and found avatar then ask permission to change their eep,  and keep repeat the loop again and again.    
for right now,  I will ignore last visit avatar that come back within 4 hr since last visit.   but when I tp back to sim within 4 hr.  script won't ask permssion and replace agent eep won't happen as well, 

  • Thanks 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 444 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...