ZGameEditor forum

The behaviour of DefineCollision-> Action-> Stop is documented in the wrong way! infact, from the wiki: "If set to "Collision" then Model.OnCollision is called on both the models involved in the collision. If set to "Stop" then the model is moved out of intersection with the other model and movement stops. "
while in source code we do read:
(
caCollision, //Actor.collision is called
caStopMovement //Position is adjusted out of collision, and collision is called
)

And trying it in a new project confirmed that models ARE moved out from the collision AND OnCollision is called. This is a BAD thing because in my ZBlocks project I spent something like 2 or 3 hours trying achieving this using DefineCollision-> Action-> Collision and ZExpressions!...

Hi Francesco,

What exactly is the problem here? The fact that the documentation does not clearly state that OnStop still triggers OnCollision Events in Models as well? I guess it could be clarified in the Wiki that all Collision Actions will always trigger OnCollision at the least.

By the way, the best method to handle collisions in a project like ZBlocks is not to use any build in Collision components at all. Since there's only one moving Model that interacts with the rest, let the Models that should be hit check whether they have been hit or not using a ZExpression, and handle the correct bouncing behavior from there. In any other engine you'd probably want to go the other way around, but as there's no possibility for communication between clones still, this is probably the best solution for now.

K

Kjell wrote:Hi Francesco,

What exactly is the problem here? The fact that the documentation does not clearly state that OnStop still triggers OnCollision Events in Models as well?

Yes it is so I will modify the wiki now (even if Ville was not yet informed )

Kjell wrote:Since there's only one moving Model that interacts with the rest, let the Models that should be hit check whether they have been hit or not using a ZExpression, and handle the correct bouncing behavior from there.

Actually I don't see any difference, mainly because I just use the OnCollision event on the block, handling the bouncing from there; so it is almost the same thing using ZExpressions inside a OnCollision or inside a OnUpdate component.
Better, the OnCollision component checks collision using compiled code, so it *should* also be faster.
The advantage using the "Stop" action is that the LastPosition of the ball is saved in an internal variable so everything is moved out of the collision properly in an automated way. I can make this in ZExpressions, of course. But now the discussion can be shifted to: "what kind of behaviour should be added to the "action" property?"

I propose: Collision, Stop (the actual one but renamed something like Stop&Collision), Stop&NoCollision, Collision&MoveOut. Plus, something like "undefine collision" should also be present IMHO. Something similar is already present in Collision.pas, line 164. but this function is never used.

Hi Francesco,

I've mentioned this before, and I'll mention it again Step based collision isn't a good method for physics type solutions. It's only good for gathering information.

Depending on how far the ball has traveled into the block, it will give a different result when using the Stop Action. It is important to realize that the move outside of collision method ( currently ) uses the normals of the collided Model to calculate the resulting position, not the impact angle. I've attached a exe which spawns a Ball into the scene when pressed Spacebar shooting it at high velocity at the paddle. On my PC the ball ends up at slightly different places after each collision, plus sometimes even flies through the target all together. The attached illustration shows what goes wrong. Two exact same sitations give different results depending on what step the collision is detected ( Red lines are the result you could get using step based collision = wrong, and Yellow is the added incorrectness in ZGE ).

I'll stop complaining now

K

yep! But Zblocks was never meant to be "exact for what regards physics" but only "funny with a decent behaviour of the ball"

Plus, the ball has a higher limit in speed, so at a decent framerate (>50) the game is flawless because of me spending lots of time studying correct ZExpressions