"Trigger once while true" and the on key release conditions are both triggers -- indicated by the green arrow -- and you can only have one trigger per event. This is also true of subevents to events with a trigger.

If the else solution fails, you could just reverse the order of events 1, 3, 5, and 7. As it is now, you start a cascade effect when you set manual to 1.

Unnatural20, on the contrary, the four directions should cover the entire perimeter of any object, regardless of shape. The result is an approximately one pixel thick border of sorts around the object in question. Similarly, using offsets of (0, 1), (0, -1), (1, 0), and (-1, 0) provides coverage just as thorough, though the shape would be ever so slightly different.

You'll likely run into picking issues here, but that doesn't appear to be the case at the moment. Notice that the objects not shown as touching another object are in the bottom right of their respective groups. This is because you're only checking for an overlap towards the bottom right, so objects in the bottom right find nothing. You'll need to check for overlap in a few more directions to cover all your bases. For example:

Your best bet would be to use "Is overlapping at offset" with a small offset, perhaps 1. This way you can have objects that aren't actual colliding or overlapping, but can determine their proximity and direction to one another.

This isn't the right place to use "Trigger once" -- distance traveled won't magically reset after your bullet goes 50 pixels, so the condition is true and remains true, thus trigger once runs exactly once, as designed.

What I'd recommend is to give your block an instance variable, called "spawnCount", perhaps. Then do something like this:

You're going to have to be more clear about what you want. Do you have any visual examples?

I went ahead and pulled together a tutorial explaining a more advanced version of this movement. No bounds on speed, support for unlimited objects, and objects following the path are guaranteed to go through the center of each waypoint.

Path Movement Tutorial

I'll leave the implementation in your game to you, but I highly recommend studying the CAPX provided in the tutorial. It utilizes some more advanced strategies, but everything is commented, and it will do you a world of good if you fully understand why it works.

Destroying all instances of an object won't unload the associated images. If it did, creating an instance of that object again would require reloading the image, which takes time.

In any case, you shouldn't have to worry unless you have an obscene number of unique images. If you have a sprite with 1MB of associated images and you create 100 instances of that sprite, you'll only need 1MB of memory for that sprite.

A sprite's angle value is automatically wrapped to keep it between 0 and 360. A way around this is to store and update a virtual angle in an instance variable, then set the actual angle to this value. I've modified your example to show this working.

You can't change layout size at runtime. If you need to change it dynamically, enable unbounded scrolling on your layout, then clamp your scroll values based on your virtual layout size through events. This should give you the exact same effect.

You're running the loop every frame, that's why it's endlessly generating sprites -- it's not the loop running endlessly. I'm guessing you want to create your objects when you start the game. In that case, add your loop as a subevent to an "On start of layout" event, which is an event under the system object.