Object-Object Touching

LSL could really use a way for one object to touch other objects and trigger Touch, Touch_Start, and Touch_End states. This would be for one person's objects to touch another person's objects. This would allow for the creation of 'bot' scripts to interact with other people's objects as if the bot was a user.

This could certainly be abused, as can ANY new feature/function, but I think it would be a minimal risk feature.

Feedback?

 _.____..._
|          |
| APPROVED |
:_______.._|

Notice: Stamp of approval not endorsed by Linden Labs. Some restrictions may apply. Void where prohibited. 'P' and 'V' have been linked with certain forms cancer in independent laboratory testing. Please consult with your physician before usage.

Sounds cool. Haven't considered abuse/security yet. But one thing that occurs to me is that sometimes when you touch things, they offer to give you stuff, or animate your av, or whatever. Scripts would have to be able to make "decisions" somehow, perhaps -- would they just be delegated to the owner? Hmm...

I would suggest an llGetText() as well, so (for instance) bots could rove around gathering info for you. Suppose I make a bot and say "go find me a _monkey_ that's for _sale_". The bot wanders around, looking at vendors, and reading them to see if there's a "monkey" and it's for "sale". Then it marks the location. Or it sends me an IM or something, and I can remotely tell it, "okay, buy it". Neato.

Okay, so I don't use it in any of my code - but what about the "collision" event-call in LSL?

This should detect when an avatar or object collides with this one.... Is that not what you need?

Take care,

--Noel "HB" Wade
(Tread Whiplash)

**Gene Poole: It was tough, but this message has none of those capital letters; its carcinogen-free!

i think he wants his objects to be able to trigger touch events in objects that have them. collision would work fine if the other object was set up to handle collisions but if it's only expecting people to "touch" it you're out of luck.

Correct!

There is an object, owned, developed, and rezzed by someone other than myself. It is a game machine. Specifically, it's a blackjack table.

I want to create a bot-script to play blackjack on the table. The table is interfaced via money() and one of the touch()/touch_start()/touch_end() states.

So in order to create the bot-object, LSL would need to support one object triggering other states. Also, I got to thinking about it, it would need to also be possible for one object to pay another.

Hrm.

Only if the receiving object has to set a status flag to enable it, and it has to be turned off by default. This way, scripts that are intended to interact with avatars only won't be vulnerable to behavior that wasn't expected at the time they were developed.

"There is of course one slight flaw with your plan, Baldrick."

If correctly designed, the blackjack table is designed to slightly favour the house in the long run, so attempting to game it with a bot is probably pointless (note, probably). Not that you're planning to do that, of course.

Actually thats incorrect. Blackjack is the only Casino game where the player can edge an advantage over the house, both by playing blackjack properly(there is a mathmatic right and wrong thing to do in any delt hand) and through counting cards.

Well, I've not seen the scripts, but its likely assumed that each new round is a new 'deck' for simplicity.

And since these tables are almost always one person against the table, the average number of cards in play is seven. In those cases the odds are still relatively in favor with the 'house,' and there are not enough cards in play to effectively 'count' them.

Of course, a *really* insane scriptor could just assume each card draw have the entire 'deck' to play with. That would average out to be about seven decks in play for a one-on-one round. Not sure I'd play a table like that...

Now back to the actual thread:

A remote touch event from a script makes me leery. Though it could be useful in some respects, things like Money Trees will end up going away again (at least mine would) from possible abuse.

There are one or two blackjack tables that work just like a casino. You have I think in this case a 5 deck shoe that gets reshuffled by 4/5ths through the deck.

But yes, great feature, please add it.

Having read everyone's replies, I think now I can more aptly define the feature request and answer potential security issues. I also have continued to research my issue and found that llGiveMoney() already answers my need for paying objects.

Objects should be able to trigger touch states in other objects, including touch(), touch_start(), and touch_end(). Objects could be set to not allow this, but the default permission would be to allow object-object interaction. The reason for the default be to Allow is that this does not open any major loopholes (no more than already exist for a user triggering touch states), and the possible benefit outweighs the security risk. However, users who don't want their objects interfaced by another object could disable the permission with a single command in their scripts.

These following script LSL commands could best support this feature:

llTouchObj(key object);
// Sends 'object' a touch.

llTouchObjLink(key object, int linknum);
// Sends 'object' a touch event on linked prim 'linknum' in the object's link list.


Further, a new permission would be needed which could be accessed like any other permission:
PERMISSION_OBJ_TOUCH

By default, this would be TRUE but could be set to FALSE.


Anyone got further feedback? I would love to get a Linden to give this idea a reply.

just to be the pee in your wheaties........ all this sounds like one thing: GRIEFBOTS!

could be anyways.

Finally people will be able to 'bump prims'

To make sure existing prims are 'grandfathered' in correctly, your new permission should default to FALSE and you'll need to turn this functionally on with a script call. Both the objects interacting should have the flag turned on.

Again, I am not sure I'd want something like this in-world. Though you could do some pretty neat things with it (like creating a properly working robot arm for a Space shuttle or other tele-robotic functions), I can imagine some bad scenarios with this. And as a UNIX SysAdmin, I've seen some pretty bad stuff in my time...

Alan, you make a good point with the grandfathering in of other prims. It would be possible though to set currently existing objects to FALSE on that permission but still deploy the new default for new objects to be TRUE.

Like so many other things in a feature-roll out, perhaps a tiered roll-out might be best:

1st Tier: All existing objects set FALSE. New objects still set FALSE. Functions and permissions deployed. Allow users to set the new permission and test it. REASON -- Let people know of the new functionality and coming changes. Give people time to play with the functions and try to find bugs, while protecting previous/grandfathered script & object work. TIMELINE -- 2 months.

2nd Tier: All existing objects left alone. New objects now set TRUE. Functions improved or clarified. Any bugs solved or addressed addequately. REASON -- If no security bugs have been found, open it up so that users can do bigger and better things. TIMELINE -- perpetuity OR until unresolvable security issues are discovered.

I disagree with the tiered rollout, and default to allow stance. It seems to me, that if you really are interested in interaction with objects that are meant to have such interaction, the creator should explicitly grant those rights. It seems to me that by defaulting to allow it, or staging the rollout, that you hope to benefit from creators not making the appropriate updates, and objects eventually allowing access. Not to mention the staggered rollout changes the behavior which tends to cause problems across the board. I think it's best that if this functionality is added that it defaults to off, and requires explicit setting to enable.

Also, it would be better slotted as a status flag rather than a permission flag. Permissions are not settable in a TRUE/FALSE manner. The script requests the permissions from a user. I would think that an addition to llSetStatus() would be more suited to something of this nature. For instance:

llSetStatus(STATUS_OBJECT_TOUCH, TRUE);

This would be required to enable object to object interaction.

Yet another point, llGiveMoney will not allow object to object payment. I just tested it in world, and the money does not leave my account when an object I created attempts to pay another object by key.

As far as gaming blackjack tables, good luck with the card counting.

Just some thoughts,
McW

Agreed. I've been talking with folk here on the forums and in world and the general consensus is that the roll out should be non-tiered and that the default should be to not-allow.

As for your suggestion this be done as a status, I like the idea. It would allow the script to dynamically set its access. A person wanting to use it as a one-time permission could easily use the llSetStatus call once and then just not mess with it again.

I also tested the obj-to-obj payment myself just to confirm your findings and I got the same results.

SOOOO...

As the suggestion stands:

----------MODIFY FUNCTION----------
llGiveMoney(key destination, integer amount)
Adjust functionality to permit object-to-object payment.

---------MODIFY EVENT----------
money(key giver, integer amount)
Adjust functionality to permit object-to-object payment.

----------ADD STATUS-----------
STATUS_TOUCH_OKAY
Determines if this object allows Obj-Obj touching. Defaults to FALSE (not allowed)

----------ADD FUNCTION----------
integer llTouchObj(key target)
Triggers a touch event on the root of 'target'
REQUIRES: Object 'target' status be STATUS_TOUCH_OKAY
RETURNS: TRUE if object 'target' accepted the touch (was STATUS_TOUCH_OKAY)
FALSE if object 'target' rejected the touch (was not STATUS_TOUCH_OKAY)

integer llTouchObjPrim(key target, integer linknum)
Triggers a touch on linked prim id 'linknum' on object 'target'.
REQUIRES: Object 'target' status be STATUS_TOUCH_OKAY
RETURNS: TRUE if object 'target' accepted the touch (was STATUS_TOUCH_OKAY)
FALSE if object 'target' rejected the touch (was not STATUS_TOUCH_OKAY)



Anyone got any suggestions before I finallize this and ask for a Linden's review?

Your suggestion still does not account for touching an object for a specific amount of time. The touch() event is triggered when a user clicks and holds on an object. To account for this, I think these functions should be added:

integer llStartTouch(key target);
Makes object click and hold its "virtual mouse arrow" on the target, triggeting touch_start and touch, depending on the the amount of time that has passed between a call to this function and a call to llEndTouch

integer llEndTouch(key target);
Makes object release its "virtual mouse arrow" from the target, triggering touch_end.

integer llMoveTouch(key target, vector newGrab);
When the object is holding down its "virtual mouse arrow", it can drag its "virtual mouse" across the object and give differing values to the object's llDetectedGrab function. The value passed to the target's llDetectedGrab is equal to the value in newGrab.

If the object is currently not holding down its "virtual mouse arrow" on the target (with llStartTouch), it returns FALSE.

I agree with your other suggestions though
==Chris

Hey!! This is a PG forum!! Keep it clean your perv!

LOL

It is?



Ah well it would be fun with a project i'm working on.

I don't know how you guys ended up in this discussion, but I think this is the discussion about Prop #6 "Object to Object communication"

The original proposal is about direct communication between objects. Today this can be achived with linked objects, but the backside is that linked object are threated as "One" object and can't move independet of each other.

So If I have understod the proposal: It should be possible to send a message directly to a KeyID (as for linked objects with link numbers), without having them linked together.

I'm 100% behind this because it will speed up object communication a lot.

// Max Pole

Nope, this is the thread about Ahroun Maelstrom's suggestion for object to object touching... that he started three months ago, before we had a voting system at all.

The world needs shagbots

Object-Object Touching... sounds kinky

Unfortunately, Max has cause for confusion on this one. It seems that someone retroactively added this forum as the discussion forum for prop #6. Maybe Ahroun or Catherine or somebody with a stake in this thread could let the Lindens know. (I've posted to them a little too often myself lately.)

neko