Can we please have an option to completely LOCK the object without being able to click or interact with it anymore ?
Currently the Lock option only stop the object from moving but I can still press on it, it gets really annoying when you have a big background for a game and want to interact with objects at the front (z order) but you cant, because the background is in the face, so wherever I press I always select the background.
a new option to Lock & Not interact
would be VERY VERY helpful 
Just as a general heads up, the current lock behavior was implemented because the old method behaved as you are asking and there were a lot of user complaints/requests to change it to the current state
I could see potential for another option/toggle to allow for the older method, but I dont know that the current behavior itself changing again.
Exactly, that’s why I asked to add another option, not to replace the current lock behavior:
• Objects you want to keep interact with them but not with their positions (Check Lock option)
• Objects you don’t want to interact with them at all (Check lock & no interact option) (the option can be turned off from the instance list)
The way I see it, we would:
Add a new checkbox below the current lock checkbox. The new checkbox would say something like “Make it unselectable (you can change it in the instance list)”:
This new checkbox should be activable only if the object is locked (because does it make sense to have it unselectable if it isn’t locked?)
Change the lock icon in the instance list so that it has 3 states : “Unlocked”, “Locked” and “Locked and unselectable”.
It would be very helpful!!! 
After version 5.0.122 they changed the way objects were locked like Silver-Streak said. I tried to explain the difficulties of this change in this topic: About the dificulties with "new" Lock position/angle in the editor
@alexandresi , wow, I liked!!! 
That’s Perfect
hope to see it soon in GDevelop <3
Yes, this makes sense to me. I also agree that you should never be able to be unselectable if not locked.
For the icon, I would probably just do an unlocked/locked as it is now for those states, then a crossed out circle for unselectable?
It will be available in the next release:
Thanks for the suggestions!
Hello y’all!
I am bringing this conversation back because I am working on some little changes on the instance panel, and I have some questions to better understand your use of today’s “Lock position/angle in the editor” and “prevent selection in the editor”.
Could you give me your real-life examples about the cases in a project in which you would:
I am thinking on a new way to do these cases, but I’d like to make sure that I know as many circumstances as possible to see if the new idea still stands.
Thank you for your help!
Personally, I use prevent selection in the editor mainly for backgrounds. If I try to select a lot of stuff, I won’t select the background because it’s the biggest thing in my editor, so when I try to select all, I end up with this big rectangle that moves with the rest of the stuff or it just cover the rest of the stuff. When I want to select it, I just go to the object panel and select it when I need it. Most of the time, I use prevent selection for things like backgrounds or levels things like platforms, walls etc…, where if I’ve only moved them a few times to set them better, I won’t need to select them anymore. While for locking position/angle, I probably never used it, so I can’t say much about it.
Use “Lock possition/angle in the editor” without selecting “Prevent selection in the editor”?
Objects that I moved to a good position in the scene, but I know that I might need to move them again later in the scene (buttons, collision, light objects…etc).
Use both: “Lock possition/angle in the editor” and “Prevent selection in the editor”?
Background object, Tilemap objects…etc. objects that I know that this is the best position for it, and it should never change whatever happen later.
In the latter case: how do you unlock an instance on the scene that cannot be selected?
Instance list → search for the object → uncheck the Lock position (it automatically un check the “prevent selection” as well).
In the same way that @VegeTato described because it prevents me from moving it by accident.
Backgrounds, controls and some things that might be on top of other instances in the scene, like large sprites for effects or structures that are made up of multiple sprites.
Using the “Instances List panel”.
Thank you all for your answers!
To clarify (so I can understand how you work with the tool): I read that you and @VegeTato use the “Lock position/angle in the editor” to lock the position of an instance that has been placed on the scene, and that you don’t want to move anymore.
My next question is: in the case that you describe… why allowing the instance to still be selected in the scene if you’re not going to move it anymore?
I ask because: if something has been positioned to your convenience and you’re done figuring the position of that instance for the time being, why not blocking the instance’s position and edition (how the option used to work in the past), and then unlock that instance if you need to edit it again?
Is it:
Already answered:
Objects that I moved to a good position in the scene, but I know that I might need to move them again later in the scene (buttons, collision, light objects…etc).
Another reasons would be:
1- I know that I am going to edit this object properties/behavior/variables…etc later on, so double-clicking on it from the scene is fast (I know I can double-click on the object from the objects list as well), but I find my self most of the time, double-clicking on the instance in the scene.
2- Going to instances list → searching for the object → press the lock icon, is a longer process, i try to avoid it.
@Luni, before I answer your questions directly, I’d like to explain what I understand of why we have two buttons.
From version 5.0.121 onwards, Gdevelop had only a single button that completely locked the instance in the scene. It was only possible to select it through the “Instances List panel” or by making a selection around that instance (which was probably a “bug” and at the time I opened a thread on Bug Reports). Print from version 5.0.121:
But in this way many novice users had difficulties, because after locking the instances they didn’t know that it was necessary to open the Instances List panel and select them there so that they could unlock them. I remember seeing a lot of posts with this kind of question here on the forum.
Then, in Gdevelop version 5.0.122 they changed how the “lock angle/position in the editor” works with the justification that it would be easier to unlock them:
This help to newbies created new difficulties that I tried to explain in my post that I have already quoted here: About the dificulties with "new" Lock position/angle in the editor - #4 by Gruk
And @VegeTato created this post that we’re in right now.
The solution then could not be to return to the original form of the lock position, as the newbies would have problems again. And that’s why we got a new button according to @alexandresi answer. This new button makes it clear that the instance will be blocked from being selected in the editor. So, that’s what I understand why we have two buttons. If you’re thinking about a change to a simplified form, I think you should take into account the difficulty that newbies have, as they usually don’t know that the Instance List is the place to unlock.
Now, answering why I use both options:
That’s not true. @VegeTato says:
And I like to lock some so I don’t accidentally move them and I don’t even notice.
For this question I agree again with @VegeTato: it’s much more convenient to unlock, but I think it’s good too that we can change some values and don’t need to unlock.
Alright!
Thank you for the time that you took to answer and to explain.
These is the list of important things that we have to preserve (regarding the scope of "locking/unlocking instances) if any improvements get done:
The new exploration respects all these points. 
Thank you for your guidance on helping me define what is valuable and has to remain unchanged! 
@Luni
since the new Properties UI is here, there is a tiny thing i miss in the old one:
I wish the new Properties UI, kept the (custom size) checkbox. Changing the sprite size from the properties used to auto check that box, so the user know that this is not the original size, but now, you can’t tell if this is the original size or not, you need to click on the Arrow button (beside the number) to reset the sprite size back to normal, just to make sure this is the default size and not customized.
or add a new icon to tell if this is custom size or not (edited).
Noted.
During this 1st implementation we wonder if only showing the refresh button when the value was overwritten was a “must have” for this first version.
I’ve noted your comment on the internal tickets for future implementation changes.
