Prevention against cheating on physics based games

With games like billiards, pool, bowling, pinball, etc. I'm trying to figure out the best method to prevent a player from manipulating the game play.

Best I can think of is to use short-range sensors checking for foreign objects (ones not owned by the game's owner) while game is in use. If foreign objects are detected the game automatically ends and refunds.

Is this a good way to handle such a check for / stopping people from futzing with physics required games? Your alternative methods, comments and ideas are appreciated.

Worse, anyone can "edit" a physics object, stopping it dead in its tracks.

Heh, yeah that's another fun issue. Though for what I'm working on I have that covered as the physical objects are always in motion. If the last checked position is the exact same as the current position someone's cheating.

Or it could also be that the physics engine just randomly decided that a thingee suddenly has zero energy which it has an annoying tendency to do...

Luckily I don't have that lack of dependability to deal as I'm just counting on gravity to do its thing with keeping up the motion, which it seems to do, least didn't fail once after a few thousand tests.

So beyond the joys of someone edit stopping a physical object. For handling the issue of an (ab)user rezzing some prims to block off areas of a game board, is using a very short distance sensor scan for foreign objects my best bet to protecting against such a hack?

Regarding foreign objects in the playing field, couldn't you use the collision event (check to be sure we're colliding with our target or anything else that is supposed to be part of the game)?

But then, say someone uses llVolumedetect and llPushObject, or a sensor and llPushObject... llPushObject looks like it has a falloff instead of a range limit, in other words you'll want to scan more than a short distance unfortunately, I think...

How about making the land no-build + very short autoreturn (if people decide to drop attachments etc)?

As for edit stopping a physical object, we had to deal with that for Castle Wars (go and play it in Arcadia 2 now) - which is a catapult game. The solution was for the catapult projectile to rez a copy of itself when it detects someone stopped it and continue the on the original trajectory - works reasonably well.

You could try placing a phantom, transparent prim over top of the board. That way, if they tried to right-click, it would force them to select it instead. The only way around it I see is if they started a drag box with an edit window already open. Also, if they tried to rez/create an object, it would get placed on the box (I think). Physical objects would fall through, though.

They could still mouse look and use touch drag.

See wiki in "Block touch somthing....

The only way to truly prevent cheeting is to use LSL to do the math and have the objects just move based on a chat channel command.

A pool cue would have to be a scripted camera, that then says it's position and angle and then some user said force number.

Reminds me of an old video game where you entered angle and pounds to shoot. Oh wait we have that too. "Tinas tiny cannon" now I'll have to get one.

llSetStatus(STATUS_BLOCK_GRAB, TRUE) would stop that from being possible at least.

Scorched Earth or clone of that type? Can even play it multiplayer online.

I think you meant to say llSetStatus(STATUS_BLOCK_GRAB, FALSE)

For bowling atleast you could expand on this and put a phantom, transparent prim over the pins and enable volume detection. By using a random number generator on rez (have it change the description and say the number), the box can detect if said ball is legit.

Try follow prims, and allow for re-rez. Seen that work well.

Maybe do a check so that the velocity vector doesn't change too suddenly (for the "edit" trick), and a collision check to ensure that the only objects hitting it are yours.

Some thoughts (by no means foolproof):

1) Random object name upon spawn, so people can't key sensors to attack a particular object name.
2) Set up very strict out-of-bounds checks -- if the ball goes out of the ring or table, delete it instantly and stop the game
3) Try to constrain the physics as much as possible, by placing game entirely inside another object
4) Skip physics and do the math yourself (very unlikely for some things) ie: Calculate where the ball will end up, use physics to "help it along" and then snap it to that final, pre-calculated position
5) Check for continous movement. If someone is using edit to stop an object, you'll know because it'll have the same exact position over the same two frames. (As long as a prim has enough velocity, it's position will twitter enough that it should be detectable.)