edj
June 8, 2024, 2:38pm
1
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