llSetForce() and collisions

ok - it's me again

I tried to build a little breakout-game but I miserably failed at the beginning.
(I know that there are probably tons of them inworld already, but I wanted to try it anyway).

I made a frame of 4 walls, named them «top/bottom/left/right».

In the «ball» I made a «collision_start»-event, triggering when it hits one of the walls, giving the ball a new direction.

I use llSetForce() to make the ball go up (starting at the bottom of the frame).

Problem is, as soon as the ball hits the top of the frame, it begins to «roll» on it, messing up the local coordinates of the ball. So when collision_start finally fires and the direction is reversed, the ball goes in total arbitrary directions.

I tried to use llSetTorque(ZERO_VECTOR) and llSetLocalRot(ZERO_ROTATION) and llSetRot(ZERO_ROTATION), but nothing helped - the ball «rolls» as soon as it hits one of the frame's walls.

As I'd rather have a steady movement without anyway, I tried it with llSetPos() as well, using a ball that's not physic - but this ends up in a rather awkward movement, so I guess I have to go with a physic-obect...

Any suggestions?

[EDIT]

Seems like collisions in a link-set don't work the way I expected. The value I get from llDetectedName(0) in the collision_start-event was always «bottom»...?

Look at the options under llSetStatus -- I believe there are some parameters you can use to make the ball unable to 'roll' so it can't rotate around and mess up its local rotations.

Re. the collision detected name, it sounds like your frame is a linked object and the bottom panel is the root prim, hence when the ball collides with *any* side, it's detecting the name of the object and not the individual prim. You could either detect the position and calculate where you're going from there, or perhaps have the frame rez invisible 'bumpers' which would be separate oneprim objects that the ball could detect as individual sides.

-Atashi