Object-Object Touching

This is especially useful when coding for complex simulations E.g. autonomous crowd behaviors, advanced flocking behaviors, simulation of contagious diseases etc.. etc...

You are right, I followed the link from the prop #6. I suggest that the person who added it there removes it, it was a bit confusing

By the way, since no one's laid it out clearly, I'll state concisely why the default for this would need to be set to ignore object-object touches. I've scripted several things that expect that only players can touch the object, which allows me to simplify my code if I want to only allow certain players to touch the object. Rather than store the keys of the players I want to grant access (which is a pain), I just check the llDetectedName() against the name of the player in question. After all, two players can't possibly have the same name. If objects are suddenly allowed to touch my objects, then players can create an object named, say, "Lex Neva", and suddenly they will be able to touch my object by proxy and do something I didn't want them to be able to do.

Any LSL scripter who builds a blackjack machine that doesn't reshuffle the cards after every hand would be foolish. And if the deck is shuffled after every hand, then card counting is moot.

Card counting only works when one can be assured that the deck is AKQJT heavy (thus increasing the probability of a blackjack which pays 3:2). If every hand starts with a freshly shuffled deck, this goes away.

- Ace

Hm. That raised some interesting possibilities in my mind.

One of the proposals I'm interested in would allow for NPCs, or scriptable avatar prims. Probably they should ultimately be able to touch things, depending on how realistic we want to be able to make them. This suggests they should have to register unique avatar names just like players.

Of course, there are those who don't want to see NPC or "robot" avs, ever, and this concern would be moot for them. But if we ever do see them, I think this may be a necessary consideration.

neko

Perhaps so. Maybe I'll check for type AGENT from now on for forward-compatibility.

Why wouldn't listen events be sufficient for object-object communication? While I understand Max's key ID option, a listen event (and chat) can still currently be used to communicate with objects outside of a linked set.

Eep Quirk, it breaks down when you have multiple objects trying to talk to each other at the same time over the same channel.

I have a utility that creates prims that interact with each other. In some cases, they form coordinated groups of 25 or more prims. One prim is a master prim, and it processes all of the communications. The issue that occurs is when it has to talk to a single prim in the group. All prims hear the message and they need to waste Sim cycles figuring out that the message isn't for them. If you've ever dealt with an old LAN and had to deal with hubs versus switches you'll understand why things bog down. If I remember correctly, if a system uses a "shout across the room" method of communication instead of a direct 1:1 link, the cost in processing cycles can be as bad as N ^ 2 + 1, where N is the number of units talking in the system.

I'd love a way to have two prims send messages to each other without needing to be linked - I'd take advantage of it and stop lagging down Sims with N^2+1 communication storms. ^_^;;

Yes all this talk about Touching is a distraction. Basically what is required is:

llSendMessage(key object,string message);

message(key object,string message) {
}


Job done. No security problems. No risks. Complete flexibility. Should be very easy to implement. It certainly would make possible much more interesting scripting.

This is no different from what you can do with email. Accept that it would be faster and more efficient, and not suffer from a 10 second pause.

Never mind all that fancy schmancy stuff about graphics, what we need is better functionality in scripting so we can actually create more interactive experiences. How hard could the above actually be? It has been hanging around as a request for over a year it seems....

FanofNick is right on! This is exactly what is needed!!!

Right on, brother - this is the way to do it! Forget all this touch nonsense

Ahem. I have no idea if this has been pointed out, but from a card counter I know, it is not possible to win over the house in the long term. Figure a 98% paybackrate (that is, for every $100 you spend, you get $98 back) if you have perfect card counting. And counting cards still has the possibility of making the wrong choice. If you need a 9 or lower to win and you KNOW there's one 10/Jack/Queen/King left and you choose to hit, there is still a chance that the 10 comes out.

Good idea with one flaw. We need the same argumentlist as link_message so that other fields can be used for optimized handling. With an integer or key value extra you can speed up a LOT of processing with faster parsing.

sim_message( key sender, integer val, string txt, key uuid )
llMessageSim( key target, integer val, string txt, key uuid )

grd_message( key sender, integer val, string txt, key uuid )
llMessageGrd( key sender, integer val, string txt, key uuid )

seperating sim only messages from ones potentially sent across the grid would also allow the script writers to decide how effecient they want their scripts to be. The event itself could be grouped into a single recieving event but if done we NEED a new function:

bool llSameSim( key target );

that will tell if a given key (avatar OR object) is in same sim. Honestly this needs implimented anyways for other reasons.

Thats flat out wrong. The whole point of counting a multi deck BJ stack is in judging the ratio of high cards to low cards. Most popular systems are variants of a point tracking where you merely know how many of each category remains in relation to the other. This way as the size of the deck dwindle down if your count value is unbalanced (one type significantly outnumbers other) you know to raise bets because your odds of getting 20 increase if high cards remain and your odds of maxing out 5 low cards increase if low.

Card counting requires you to bet really low ammounts when your odds are truely even and only increase your bets as the chance to get an extreme increase thus when you lose PREDICTABLY you lose small without alerting the dealer, and when you win PREDICTABLY your higher bets bring in enough to cover losses.

So regardless of what your CHANCE is, by betting on a higher accuracy ODDS with counting you increase your winnings consistantly.

Can we stay on topic here? We REALLY need Object to Object Communication.

Just go vote for it right now and be quiet about Blackjack

I'll take a couple votes off my own proposals if someone provides a link to one with obj-obj communication. But NOT for obj-obj touching. We have collision events for that.