Jump to content

EEP LSL Scripting


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

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

Recommended Posts

On 12/1/2018 at 4:17 PM, 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.

 

Permissions are a very simple contract that you can break at any time and at no cost.

If you don't want to give your permissions, don't join the experience.

Edited by Kyrah Abattoir
Link to comment
Share on other sites

5 hours ago, Kyrah Abattoir said:

 

Permissions are a very simple contract that you can break at any time and at no cost.

If you don't want to give your permissions, don't join the experience.

You totally missed the point of what i was saying. I was commenting on a new way of possibly handling them. I'm aware of how permissions work.  I also mention literally a comment or so before that....that I don't join experiences if I don't want to. So please...

A : Read what people actually write

B : The entire thread so you see what other things they have already written

Link to comment
Share on other sites

7 minutes ago, chibiusa Ling said:

You totally missed the point of what i was saying. I was commenting on a new way of possibly handling them. I'm aware of how permissions work.  I also mention literally a comment or so before that....that I don't join experiences if I don't want to. So please...

A : Read what people actually write

B : The entire thread so you see what other things they have already written

Trying to lecture me isn't going to earn you any sympathy.

Link to comment
Share on other sites

On 12/11/2018 at 5:29 AM, Bellimora said:

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.

I really wish people would stop attempting to explain the Experience system over and over to those of us who already understand how it works just because we disagree with how much control has to be given over to it and by doing so manage to miss the point completely.  Granting full control to everything the Experience is setup to demand or not being able to visit only offers the illusion of choice.

True choice looks like this:

In addition to being able to wander around a nice build, possibly buy things and soak in the ambience without needed to grant permissions, I could also decide on a case-by-case basis whether I wanted to sit or be animated by something or not.  If I didn't trust it or just didn't feel like being animated by that octopus that does naughty things to my avatar, I could just not use those items around me and yet still could appreciate the build and take photos for example.  No permissions necessary.

Those of us with viewers such as FS can already revoke sitting and animation permissions - good enough for me.

Sure, you are building a game and so I would never visit your place and I have already expressed that I don't believe SL to be suitable for the kinds of games that need total control of the viewer.  However people building games inside SL is in a large part what is driving this push for more and more control of the viewer being made accessible through the Experience feature.  For many places it will and is being used just to grab control and there is no idea up front if what they want to do with it can be trusted.

"Don't like it?  Don't visit" rhetoric is just a way of coercing people to accept it without giving any real choice.  Well guess what?  Under those terms, why would I want to visit?  If ever it becomes that most of SL uses Experiences (including Linden builds with grid-wide Experiences) then I won't even want to login to SL any more.  Drop in the ocean, I am sure but then these features aren't helping those user retention figures either are they?

Link to comment
Share on other sites

@Gabriele Graves

I have to respectfully disagree on the belief that it is coercion. You don't want to visit places that have mandatory experience permission requirements, that's perfectly fine, SL is a lot of things and there are many places I am not interested in visiting either.

A lot of places in SL already have staff enforced rules that you have to abid to in order to visit, and joining an experience while refusing any and all permissions seem dishonest in a "I will pretend to join the experience to gain access" way.

Edited by Kyrah Abattoir
  • Like 1
Link to comment
Share on other sites

I think that changing the experience permissions menu to make it granular is a non-starter, since it would (I assume) involve both changing things server-side to make the server check what permissions the avatar had granted rather than simply whether the avatar had accepted the experience and (certainly) changing almost all existing scripts that use experience permissions to perform similar checks.

Certainly when I write scripts using experience permissions (and I have written plenty), when I want to teleport/attach things to/force sit someone I simply call llRequestExperiencePermissions(id) and then, in the experience_permissions event, go ahead and do whatever it is, since I know that when that event fires, I have all the permissions I need    That, as I understand it, is the recommended way to do it, and I'm not at all sure that there would be any point to checking llGetPermissions(), since script and experience permissions are two completely different things.

LL are rightly unwilling to break existing content without a very pressing reason, and I can't see them wanting to break almost all existing experiences to accommodate this particular request.     There would be a lot of very unhappy landowners and scripters if they were to.

 

Link to comment
Share on other sites

@Kyrah Abattoir Previously you stated that "Permissions are a very simple contract that you can break at any time and at no cost."  If a contract comes without terms and conditions that makes it possible to understand the nature of the agreement then the contract is not an honest contract.

Besides I am comparing is what used to be before Experiences versus what we are heading towards.  I don't even really care about "Experiences" where every inch of being there relies on having those permissions - like the games described previously.  What I am concerned about are "Experiences" that are largely just exploring a region anyway and yet have may have a few optional things to interact with here or there and granting permissions up front is overreaching.  For these regions no permissions should be necessary.  However because of the perceived need to make the fully immersive games type "Experiences" work, more and more of the viewer control is becoming accessible from "Experiences" and therefore will be requested more by the types of regions I do care about.  They will and already are doing this because they can and because "Experiences" are cool, not because they need to.

@Innula Zenovka I agree with all the technical reasons you give for why it will not change.  I am not even making any kind of request despite appearances.  I am lamenting the path we are on that will lead to everything becoming an "Experience" which includes all viewer control because people overreach and the inevitable calls for removing even the ability to agree or disagree because "everything needs an Experience anyway and this permissions request just gets in the way".

The all or nothing agree/disagree approach to permissions is what Android started with and yet Google moved Android away from that for exactly the same reasons I raise, complaints of overreach and not enough information to be able to make an informed decision about "the contract" once asked.  Apple iOS always had the granular approach and stayed with it.  I think it is pretty clear that an all or nothing approach is least desirable except by those hoping to exploit it or think it is too bothersome asking for permission in the first place.  Does it make the Experience less seamless?  Sure does but the alternative is not informed consent.

Just so I am clear again, I am not asking for anything nor am I expecting what is done to be undone as neither one here has ever produced anything but arguments as far as I can tell.  It is a projection of where we are headed and an appropriate lament about it.

Link to comment
Share on other sites

On 12/31/2018 at 7:56 PM, Gabriele Graves said:

Those of us with viewers such as FS can already revoke sitting and animation permissions - good enough for me.

I don't think that's the case.  I'm open to correction here, since I'm not familiar with the inner workings of the Firestorm viewer, but I'm pretty sure that the most Firestorm can do is stop a particular animation from playing.   I don't see how it can affect the animation permissions held by a script that belongs to someone else, since that would involve the viewer being able to tinker with data held on the server about permissions held by someone else's objects.

Link to comment
Share on other sites

18 minutes ago, Innula Zenovka said:

I don't think that's the case.  I'm open to correction here, since I'm not familiar with the inner workings of the Firestorm viewer, but I'm pretty sure that the most Firestorm can do is stop a particular animation from playing.   I don't see how it can affect the animation permissions held by a script that belongs to someone else, since that would involve the viewer being able to tinker with data held on the server about permissions held by someone else's objects.

It's under Avatar->Avatar Health and looks like this:

Menu.jpg.d2b31af69a5df028d2fa0563548d0a44.jpg

Sure seems to do what it says most of the time.  Like I said, good enough for me.

 

Link to comment
Share on other sites

1 minute ago, Gabriele Graves said:

It's under Avatar->Avatar Health and looks like this:

Menu.jpg.d2b31af69a5df028d2fa0563548d0a44.jpg

Sure seems to do what it says most of the time.  Like I said, good enough for me.

 

It may be that it ignores instructions from a particular object's UUID to animate the avatar but I don't see how it can actually revoke permissions.  The only ways to cancel script (as opposed to experience) permissions is to over-write them or to reset the script. 

Link to comment
Share on other sites

1 minute ago, Innula Zenovka said:

It may be that it ignores instructions from a particular object's UUID to animate the avatar but I don't see how it can actually revoke permissions.  The only ways to cancel script (as opposed to experience) permissions is to over-write them or to reset the script. 

I have no idea of the internals either but presumably as all animation is viewer side, the viewer can just refuse to animate when requested by the script I would think.  So maybe it isn't a true revoke from a script point of view but that would hardly matter as long as it is effective.

Link to comment
Share on other sites

  • 2 months later...

I'm getting an odd result using llGetRegionMoonRotation, in that it's returning a result that when Rot2Eulered and RAD_TO_DEGed has a y component of zero all the time. The equivalent llGetMoonRotation returns a value, similarly treated, whose y component changes over time.

default
{
    state_entry ()
    {
        llSetTimerEvent (1.0);
    }

    timer ()
    {
        string text = 
            "Moon rotation " + (string) (llRot2Euler (llGetMoonRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionMoonRotation ()) * RAD_TO_DEG) + 
            "\nSun rotation " + (string) (llRot2Euler (llGetSunRotation ()) * RAD_TO_DEG) + " " + (string) (llRot2Euler (llGetRegionSunRotation ()) * RAD_TO_DEG)
        ;
        llSetText (text, <1.0, 1.0, 1.0>, 1.0);
//llOwnerSay (text);
    }
}

 

Link to comment
Share on other sites

  • Lindens

Does the moon in the region you are testing this in move?  

If you give me a SLURL to the region I can go take a look.

Also one way to sanity check what you're seeing would be to also call llGetMoonDirection and llGetRegionMoonDirection and compare the results.

  • Like 1
Link to comment
Share on other sites

46 minutes ago, Rider Linden said:

Does the moon in the region you are testing this in move?  

If you give me a SLURL to the region I can go take a look.

Also one way to sanity check what you're seeing would be to also call llGetMoonDirection and llGetRegionMoonDirection and compare the results.

Yup, the moon is moving just fine in http://maps.secondlife.com/secondlife/Hane/203/125/58.

And yup, that script in my post is comparing the two. It's an extract from a script I was using to try to get my head around how the various EEP functions work, and it compares both the parcel and region rotations for both the sun and the moon. And it gives the same results both in my home parcel (which has had absolutely no EEP tinkering performed on it: I haven't even downloaded the EEP viewer) and in the adjacent Linden Home public land, and on other LL owned public mainland.

Link to comment
Share on other sites

  • Lindens

Interesting.  I'm on the walkway outside the parcel and I see what you mean.  There is a slight variance between the Region's moon rotation and the parcel's moon rotation.  Even when the two should be absolutely in sync.  I will open a JIRA for that... 

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

You are about to reply to a thread that has been inactive for 1855 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...