@NNterprises the distance formula seems promising but like you said would need a lot of tweaking to get it running. It'll be difficult to adapt that to constrain the actor, and it'll probably be just

(Quote)

(Quote)

(Quote)

Easy way would be to keep track of what room you're in with an integer game attribute, and use that attribute to determine the column in the rule that destroys the gem if it's collected.

(Quote)

If attribute CamreaFollowing is true:

Every 0 seconds is slower than the constrain loop but is running less.

So doing some math you can create a self attribute called speed and make them move at those speeds until collision with the horizon line.

Create an integer attribute called RANDOM

Need suggestion to not need the constrain (trying to get the game not lag)

Make an attribute called DISTANCE then use the distance formula where x1= mouse. position.x, and y1 = mouse.position.y.

In your gem actor , create a self integer attribute call it self.Row ( give each gem a self.row number)

Like the title says, we need to keep an actor constrained so that it maintains a constant distance from another actor but can still move around it on a circular rail while still responding to collisio

If attribute is true:

That looks very promising. Thanks to @NNterprises for the input, but I didn't mention that I believe the Interpolate behavior does not work well with collisions, something I didn't point out earlier

@Icebox Just a followup on this, Will I need to make a game attribute for everyone of my Gems in order for it not to reappear when switching scenes?

(Quote)

I would make a real attribute called HeroY.

There are a couple of issues with custom collisions whilst not being bugs (more a counterintuitive way of working) might cause confusion for users.