Jump to content

Grid Scope Key Q and A's


Troy Linden
 Share

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

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

Recommended Posts

  • Lindens

Just for clarifications sake:

A regular Experience Key requires a region to have the ExpKey as a Trusted Experience?

For Land Scope keys they need to either be added to the Key (formerly Trusted) or Allowed experiences list. For Grid Scope they just can't be in the Blocked list.

 

And a Grid Scope Key does not?  It can work on Mainland?

Yes, they work on Mainland

Link to comment
Share on other sites

I was not aware that my Land Scope key would be upgraded to a Grid Scope key. I thought I would be issued a separate Grid Scope key. I have applications using my current key that I do not want to operate grid wide, only over land the users have the right to allow experiences over. Could I have my key reverted back to Land Scope and a separate Grid Scope key issued? I will take one with no KVP store size if necessary. Thanks in advance.

Link to comment
Share on other sites


NeoBokrug Elytis wrote:

And a Grid Scope Key does not?  It can work on Mainland?

Just in case of confusion: Land Scope keys also work on Mainland, enabled on a per-parcel basis (not per-region). For example, my teleporter ring works all around the Atoll -- but only on group land where I can enable it. (If it were a grid-wide key, of course, the experience could work anywhere.)

So, for those who are testing this now: Does the permission request look any different for Grid Scope Experiences compared to Land Scope? (I'm not sure it really matters; I'm just a bit concerned about whether folks will accept the scary-looking list of Experience permissions, grid scope or otherwise).

Link to comment
Share on other sites

The permissions dialog looks the same for both Land Scope and Grid Scope experiences.

I have received several concerns from users about the nature of the permissions dialog and how it lists all possible permissions an application can exercise even if only one is actually used.

I could only direct them to blog and wiki info on experiences and tell them it was out of my hands.

In a related note, I did file https://jira.secondlife.com/browse/BUG-8044 in hopes that behavior with llAgentInExperience() in Land Scope keys can be changed to that of Grid Scope keys so no false negative cases occur.

Link to comment
Share on other sites

  • 1 month later...
  • 4 months later...

Will grid scope experiences be the only way to access a KVP database from anywhere on the grid, or will that functionality be added to land scope keys as well?

I ask this because the KVP is my main interest in the experience tools; while I'm fine with the persistent permissions only working on my own land, access to my KVP from anywhere was something I expected to be able to do from any experience-compiled script.

Link to comment
Share on other sites

  • 2 weeks later...

If you mean "anywhere on the grid" whether allowed by the landowner or not, then yeah: land scope Experience scripts throw an XP_ERROR_NOT_PERMITTED_LAND when trying to use the associated KVP on parcels that don't explicitly permit that Experience. But it's important to note that you do not need to be in any way associated with the land on which your land scope Experience is enabled. It just can't run without the landowner's knowledge and permission.

(That said, I absolutely agree that there are a host of applications where KVP access only would be handy, and wouldn't seem to cost the landowner any trouble if limited to just those operations. Unless I'm missing some griefing vector, which I usually am.)

Link to comment
Share on other sites

  • 2 weeks later...


Qie Niangao wrote:

Unless I'm missing some griefing vector, which I usually am.

No, I don't think you're missing anything here. Restricting KVP read/writes to only land that allow the land-scope experience seems entirely arbarary, as there's absolutely nothing griefy you could do. The restrictions appear to be made for and justified by what you can do with persistent/automatic script permissions. Applying those same restrictions to the KVP functions appears to be a case of over-protection and that's very, VERY unfourtinate.

The clear work-around, if you want to keep everything in-world, is to make a HTTP proxy so you can communicate to a prim rezzed at a home location to do the read and writes for you, and send back the data. This is a real hassle, and I don't understand why it should be necessary. Being able to use a HTTP proxy to get your KVP data doesn't allow you to do anything "greify", it just creates lots of overhead and it's a real pity not to be able to use the functions directly in an attachment.

I have absolutely no need for grid-scope persistent permissions, but I very much want/need grid-scope KVP. It will be a shame if the only way to have KVP access gridwide is to have a grid-scope key, as that will be paying for major, powerful, greify-potential features I just don't need in order to be able to do what I actually want.

Link to comment
Share on other sites

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