Locked should mean locked


If an item is locked
no one shoudl be able to do anything to it
not grab it
not re texture it
not anything to it
apart from unlock it
if they have the rights


Wow did they break locked?


Let me guess… you applied a material entity over a locked entity and it works since it only affect the rendering at the interface level ?

if it’s that, welcome griefer :wink:
If it’s that, maybe only locked material entity should be able to affect a locked entity…
IF this is the case.


locked entities are grabable
i still cant turn grabbable off on masse
so i cant have anyone in my domains cos its 2 easy to wreck the place
im assuming the same goes for everones stuff pre grabgate
i dunno about the materials thing but i woudlnt want people idly retexturing all my models with peens
just cos they had build rights
i want locked to mean things need to be unlocked to edit
ya know


Last I checked you cant affect positions or rotations of locked objects via scripts, all grabbable does is allows the grab script to interacting with the entity.

Also Didn’t I fix that script already? It should turn of all grabbable tags by toggling locked state off before turning off grabbable then locking things again. I didn’t really look into is much than just estimate thats how it works, but if It doesnt, I can do a more deeper check into it.

Now Materials effecting the object I can understand from a logical oversight: You can after all parent something to an object that is locked, because technically you are not changing the locked object as there is no actual hiearchy: all it is a client side connection. They should look into that.


its not getting everything
just at crompton moor the other day - everythings locked somone accidentally grabbed the floor
theres like 500 models there
i like that i can select everything and lock and unlock everything
i just thought i was safe as that


Ah I just noticed I have made a classic typo in the script. I was changing the value grabbable_key instead of grabbableKey

var entities = Entities.findEntities(Vec3.ZERO, 1000000);
for (var entityIndex in entities) {
    var entity = Entities.getEntityProperties(entities[entityIndex]);
    Entities.editEntity(entity.id, {"locked":false});
    if (entity.userData) {
        var userData = JSON.parse(entity.userData);

        if(userData.grabbableKey && userData.grabbableKey.grabbable){
            console.log("Found a Grabbable Object", entity.locked);
        userData["grabbableKey"] = { "grabbable": false };
        Entities.editEntity(entity.id, { "userData": JSON.stringify(userData) });
    } else {
        Entities.editEntity(entity.id, { "userData": JSON.stringify({ "grabbableKey": { "grabbable": false } }) });
    Entities.editEntity(entity.id, {"locked":entity.locked});

Now I actually double checked it and tested it inworld


This design for Material entities look a bit weird to me.
We have here something designed to affect the aspect of a specific entity… the only interest to have this outside of the entity it-self would have been to be able to reuse it for many entities. But it’s not even the case, it’s a 1:1 relationship.


The reuse comes from the actual json file that is used to set it.
The reason why they did it this way is that they can use the same method for avatars. Althought they need to control it so that material entities should not be parentable to sessions that are not your own, becuase I exploited the hella out of that in the Monday meeting


Makes good sense. :wink:


Is this still an issue, or did Menithal typo fix do the trick? Can’t seem to touch anything in Crompton.

I also can’t reproduce this on locked entities. If anyone can reproduce this, can they do a screengrab and send that so I can explore further/send to the appropriate team?


Menithal fixed it in that they arent grabbable anymore, were a few more tweaks required
but, i dont think a locked item should be grabable.in that a locked door shoudlnt be openeable .


i dont think a locked item should be grabable.in that a locked door shoudlnt be openeable .

Can anyone else confirm this or can you provide a screen grab? I can’t seem to reproduce this when I made an entity and turn it to grabbable then lock it. I can’t pick it up or move it out outside of the create menu.
Curious if that is different for you or if that only applies to certain cases then.


One of the floors in my domain was flipped by a person with hand controllers, i checked it , it was locked, everything was locked, because when i didnt lock everything people found ways to delete all unlocked items
so im hot on locking everything
maybe its certain cases ie the part of the domain that was messed up was created 3 years ago so im guessing grabable wasnt a thing back then.
@Menithal what did you have to add to the script to make it get all the objects, it was only finding half the first time around?


There is a use case that often gets me… entities placed in desktop… say for example walls of a house and locked.

Later come in in HMD and realize its not aligned, unlock it… then good luck not grabbing it before getting into edit mode… result wall is now totally mis aligned (if not accidentally warped halfway across the domain)…

When we lock it can it not just remove the grabbable also? cant see a case where should be grabbed after locked…


We were moving around the domain to get all the objects though. the Entities.findEntities thing was only returning us those that the domain gave us it wasnt giving us -all- the entities in thedomain


One of the things I noticed is that if the userdata girl is empty the object becomes grabbable according to the editor. If the grab scrip does the same this can cause issues with legacy builds.

This should not be the case and instead if the user data set is not set the grab script should behave as it wasnt grab able.


@miladn There is still the issue where everything you create comes in grabbable because the menu setting “Create entities as grabbable” resets itself to true at every relog. No matter how many times you change it.