Use the 'For each (ordered)' to check through your objects in order of distance from the player. You can then use the expression 'loopindex' to direct each one to a layer.

Don't move the tilemap - scroll the viewpoint using 'System> Scroll to' events.

Personally, I would store this data in a Dictionary. A Dictionary is used to store and re-call data which you can identify with a 'key' - a unique identifier. In this case, I would make your 'key' be the Player's name (so long as another player hasn't already used that name of course!), and in the value I would store 'SaveStateJSON'. The value 'SaveStateJSON' is only available in events called by the condition 'On save complete', and represents the snapshot of the game that is created for a save fil.

You should then use Local Storage to hold the contents of the Dictionary, so that it can be recalled at a later date. Local Storage is worth getting your head around - but I would advise reading the complete manual entry on the subject before moving forward with it. A lot of questions about LocalStorage posted on here can be fixed by actually reading the manual - it is not entirely as straightforward as it seems!

https://www.scirra.com/manual/188/local-storage

I too am curious. HOWEVER: I looked at the capx - although it's all basic stuff it is also a horrendous and thinly-commented mess. I can't help but imagine whoever kept this project is very capable of making mistakes, and in code that messy they are easily hidden.

Thanks man!

No worries, hope it works out

A string-variable? That's new to me.

Objects can carry variables, which must be either number (float or integer), string (alphanumeric), or boolean (true/false) values according to a preset specified by the developer:

https://www.scirra.com/manual/73/instance-variables

It depends on what that you're doing with those objects with regards to what behaviours and so-on they're running. There is unfortunately no ideal workaround for this AFAIK. HOWEVER: check out the Chipmunk physics port by R0j0hound

It allows 'collision groups' which make this sort of thing easier to control. This, of course, assumes a lot: a) you're happy to install plugions, b) that you're using physics and c) that you don't need incredibly dynamic control of these 'selective collisions'.

Another option that works in some simple circumstances is to have two objects to represent each item, have one with the solid behaviour and the other can be used to collect collision data when solid is not being used. Again, not ideal in all situations.

Track the colour of the last-pressed switch by adding a variable to the player. A string-variable would work for this - we'll call it Player.LastButtonColour. You'll need another variable on the button to track what colour should have been pressed previous to it in the sequence - we'll call it Button.PreviousSequenceColour

When the player jumps on a button, check the Player.LastButtonColour against Button.PreviousSequenceColour. If they match, open the matching door, and set Player.LastButtonColour to represent the button's colour. If they don't match, re-lock all doors in the sequence.

Should do, yeah. Or 'wallclocktime' might help.

This indicates that you're not picking the correct instance of the bullet to manipulate when you set its angle. It sounds like there's a 'set angle' action on your bullets which doesn't have a corresponding condition directing it towards a specific bullet.

If you include the 'set angle' action in the same event as the creation of the bullet, it will apply to the created bullet. Otherwise, you'll need to specify which bullet you want the angle adjustment to affect.

If key [down] is down and key[fire] is pressed, create your bullet and set its angle to 90.

If key [up] is down and key [fire] is pressed, create your bullet and set its angle to 0.

As you can see, the above two events are similar, so you'll want to try and make them sub-events of the 'key fire is pressed' condition, for example.

Sure - if the Platform speed is not equal to 0, use a different animation