In purely mathematical sense there's no issue with your code. In the real world though, there is an issue: accruing decimal rounding over time. For your code to work, GM would need to have infinite decimal accuracy. It doesn't, and each step your x and y get a liiiitle bit more out of sync from perfect circular orbit.

What you need to do, is to define the starting point of the orbiting object, and give it a starting angle. Easiest is to place it directly to the right of the center point and have an angle of zero. Then, in step event, you increase the angle by little bit, and always calculate new position from the original starting point coordinates with trig. Now because your starting coordinates will never change, your orbiting object cannot migrate due to decimal rounding accruing into its position. (I ran into this same problem long ago, trying to rotate vector cubes on Amiga.)

If your object has to run the orbit a potentially infinite amount of time, substract 360 from orbital angle each time it crosses that value, or before long you run into the hard integer limit GM variables have.

EDIT - looking at my projects, thanks to lengthdirs, there's even a simpler method to do this:

Code:

```
CREATE:
Orbit = 200; // Orbit distance
Angle = 0; // Current orbital angle
Speed = 1; // Orbital speed
Center_X = room_width / 2; // x of orbital center
Center_Y = room_height / 2; // y of orbital center
STEP:
// Orbital motion
Angle += Speed;
if(Angle >= 360) Angle -= 360;
// Update position
x = lengthdir_x(Orbit, Angle) + Center_X;
y = lengthdir_y(Orbit, Angle) + Center_Y;
```