Lots of good ideas here - thank you everyone! Let's see what we have...
Jim Tarber wrote:
...the prim may escape depending on the time between physics frames (normally 64 frames per second in IW). If it's on the inside in one frame and outside in the next (based on velocity), it will break free....
This helps. Effectively it appears that the sampling time for the collision detect needs to be extended so that it gets at least 2 frames worth of sampling as the balls hit the inside of the cylinder. I increased the diameter of the balls and this seems to be effective.
...have you tried a very thick invisible hollow cylinder around it to prevent escapes?
Yichard's answer highlights the problem here:
...That the cylinder is thick will probably not prevent the problem, since once the ball is entirely inside the "wall", it no longer "feels" it. You must think that the repelling force is exerted by the surface, not by the volume...
This is why I made the balls larger rather than going for the cylinder thickness. It did seem to me that I needed the initial collision with the inside wall for my effect. I'm not sure what would happen if a collision was missed there and then was detected at the outside surface.
...it seems to me, from the description, that only "some" [external] physical properties (but not all) are applied to the inner surface of a hollow object...
I'm using a hollowed cylinder, capped at both ends with disks which are just flattened cylinders. The resulting surfaces are just that fortunately, simple surfaces, so all normal expectations apply.
Quit Button wrote:
IIRC there was some code added to move physical objects if intrapenitration was detected, which had the side effect of causing such objects to be thrown across the sim instead of being gently moved away from each other.
That's not a very comfortable thought. Doesn't apply in this case though since I've kept the container non-physical so that I can use touch events on it to control stop/start. One possible glitch I may yet need to deal with is that apparently collisions can cause touch_starts to become a bit uncertain in their response. I'll experiment and see if that does in fact become an issue.
Many thanks for the other suggestions on how to handle potential escapees. The lotto illustration was to help with picturing what I'm doing but I'm actually dealing with less balls and they aren't individually numbered as lotto balls would be. The balls already carry a position sensing script which causes them to die if they do escape their container.