So, what happens when the object touches the orange frame? It resets its position at the startx, starty coordinates?

Nevertheless, what you really need is a "Pick" action, as opposed to the "Drop" that the Drag&Drop behavior already has. That way you would drop the object every time it overlaps and pick it up again automatically if the mouse were still pressed.

To be honest, I can't think of something useful. The closest I got is without using the Drag&Drop behavior, with a simple "set position to" mouse.X, mouse.Y action (you can lerp it for smoother movement) and a boolean that becomes false when the object overlaps with the container and stops the "set position" action. The problem is that when it stops the overlapping and we re-enable the "set position", the result is a jagged movement as the object collides and re-collides constantly with the container. Also, if you sweep the object fast enough, you can even pass thru the container, since the 60fps aren't enough to check for the collisions.

Sorry that I couldn't be of more help.

Xerullian That's brilliant

Damn, it's harder than I thought. I am sure that there is an optimal way, perhaps with loops and/or arrays, but that's beyond my scope of knowledge!

Here is a semi-working example, the problem is that when you come back to the main menu, the locking/unlocking resets. That's because the booleans doesn't keep their state after you leave the menu layout. You have to find a way to store each level's condition within a global variable (or an array, dictionary, whatever stores data). I am too confused to think about it right now. Try to improve upon this, if it helps you, and meanwhile perhaps someone else will think something more appropriate!

I am sorry, I don't understand what you mean by "the object returns to the original place when I drop it". I thought that you want upon collision for the drag&drop behavior to stop acting. The "while" events in my example ensure that there is no overlapping between the sprites, I guess that since you use the Physics Behavior that wouldn't even be necessary because the detection is very tight by it's own with physics.

Can you share a capx file to clarify your needs?

Is this what you want?

Please have in mind that since you want the inventory on-top of (the scrolling) player, the UI layer should also have to scroll, therefore it's parallax values can't be different from the Game layer values. I suggest moving the "inventory" object into a different layer and keep the UI with 0,0 parallax for static things like health bars, score and that kind of stuff

Wow, math! Thanks

Great!:)

Within the Image Editor, zoom and check closely your image on the edges. I think that you'll discover transparent or semitransparent pixels, and those are the culprits in your case.

Please check my example on this topic. https://www.scirra.com/forum/viewtopic.php?f=147&t=103985

I believe that the same rule can apply to your needs.

Create an instance Boolean Variable (Lock) and check if the level is locked or not in order to be able to click it.

Thanks mrnannings