Be able to decide which scripts and attachments work on one's land

Introduction

- We should be able to decide which scripts and attachments work on one's land.

- Anything remotely gamelike is hindered currently because it must be based on an honour-system to work: there are just too many ways to exploit.

- We could try locking down each individual exploit one by one but that would take a really long time and never be complete, and take a lot of SL dev time.

- Instead, the easiest thing could be to be able to decide exactly which scripts and attachments are allowed to run on one's land, to be able to prevent players rezing and editing on one's land, and to be able to block Debug mode.

This is really important because otherwise it is really hard/impossible to create persistent worlds within SL which is one of THE BIG THINGS that SL is potentially really awesome for!

Implementation

- Any player can create a Tag. A Tag is a new inventory type that is unique, and can never be recreated if it is deleted.

- A Tag can be Assigned to any object script, notecard or landmark.

- The Tag stays Assigned to the object until it is modified. Copying the object will Assign the Tag automatically to both the copy and the original. Giving the object or script will not remove the Tag. The only thing that removes the Tag is modifying the object or script, and this will automatically strip all Assigned Tags.

- You can Assign multiple Tags to a script/object/notecard.

And the key to the whole thing:

- You can authorize specific Tagged objects or scripts on one's land and automatically disable all others.

This is a simple and robust system to prevent exploitation in persistent gaming.

Discussion of Current Exploits

Here are some current exploits possible, with a discussion of how Tagging could be used to prevent them.

MoveToTarget

Imagine you create a dungeon with a hard-to-get-to area. Maybe a shelf a little elevated that you cant jump to. You disabled fly, so you cant fly. You gave people an attachment so they die if they sit down, so they cant just sit on the target prim (4 hours of work to write anti-exploit code for that...).

But someone comes in, puts on their movetarget attachment and types "MOVERELATIVE-=-<10,10,50>" and Poof! a MoveToTarget in the attachment moves him up to the inaccessible shelf.

Tagging prevents this since the script within the attachment wont run, since it hasnt been Tagged.

Rendering | Hide Selected

This is a powerful feature from the Debug menu to hide selected prims.

What this means is that if you hide an object behind a wall or other object, then actually people can find it pretty easily.

The solution is to disable Debug mode on this bit of land, which will automatically activate all renderings and disactvate the Hide Selected option.

PushObject

Nasty monster fires a physical bullet at you, but you're not worried because you have your BulletDeflector attachment (TM) which contains a script that detects incoming bullets and pushobjects them away.

Solution: the BulletDeflector script wont run because it doesnt have a valid Tag for your land.

Sensors

Jonathon comes into your land, and decides to take a proactive approach to finding the tresure by using his Sensor attachment.

Solution: the Sensor script wont run because it doesnt have a valid Tag for your land.

Conclusion

Tagging objects and having options on one's land to disable Debug mode and objects/scripts that arent wearing the appropriate Tag could be powerful facilities to prevent exploitation in persistent SL games.

With the thread of exploitation substantially reduced, MMORPG developers will be able to use SL to create whole imaginary worlds and universes in which to battle dragons and rescue beautiful maidens.

Script Tagging could open doors for the future of SL.

Just bumping this because, imho, this is the single most important feature for the future of gaming within SL.

Azelda

Keys. They're called KEYS. They already exist.

What we need is simply more control over what can and can't exist on our lands. By name, by owner, whatever. This has been asked for for a dozen or more times.