Collider and latest CGE?

I updated cge from git to get the outlined triangles, which are great. But to build I found that anywhere I had a TCastleScene subclass and a var Collider : TCastleMeshCollider I had to rename my variable. No big deal, but I wonder what changed for Colliders? Is it still correct to initialize the collider you want and add it to the behaviors?

     MyCollider := TCastleMeshCollider.Create(Self);
     MyCollider.Mesh := result;
     MyCollider.Restitution := 0.3;
     result.AddBehavior(MyCollider);

That’s because we have introduced a property called Collider on TCastleTransform, see Castle Game Engine: CastleTransform: Class TCastleTransform . It’s a simple shortcut for reading FindBehavior(TCastleCollider) as TCastleCollider.

The FPC ObjFpc has a rule that prohibits from declaring a local variable whose name would conflict with class property. I have extended my document " Some differences betwen FPC ObjFpc mode and Delphi (and FPC Delphi mode)" to mention this, Some differences betwen FPC ObjFpc mode and Delphi (and FPC Delphi mode) · michaliskambi/modern-pascal-introduction Wiki · GitHub .

This forces you to rename the variable indeed to something else (like we did in CGE examples too – Fix physics_asteroids to not have Collider · castle-engine/castle-engine@bbe7e95 · GitHub , Fix compilation of platformer after TCastleTransform.Collider introduced · castle-engine/castle-engine@0c772d4 · GitHub ). On the other hand, it makes your code a bit more future-proof: if you were allowed to have a local variable with name Collider, and removed that local variable during some refactor, then some lines accessing it (like Collider.Restitution := 0.3;) could still work but access now TCastleTransform.Collider by accident.

In short: Indeed you have to rename your local variables now from Collider to something else.

1 Like