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.
