[Scripts] How to deny user B from click access on object user A use?


Everytime i where thinking i solved it, the problem popped back.
It’s about my door. When user A is using it, everything works fine things seems safe.

Problem is that when a other user comes in and click the same door, things get screwed !. because the data is not in sync. userData seems to slow or also not in sync.
So the result is things start to happens that you not want.

Am running out of idea;s last trick i tried is start rotation, lock object (yes found a cheat to use object and still lock it) But the lock seems way to slow to arrive for the other user.

So i always yelled at LSL screw things. I found one in High Fidelity. Client side scripts and how do you keep some information in sync. So when you set doorLocked that the other script read that and stop doing things.

Until now, most solutions are a bit wacky / not working.
The only solution left is that could work is that you cannot closethe door manual. Other idea’s welcome.

Assigning userData to entity properties

I mentioned this a few weeks ago (still searching for the topic), but it may have been @b who mentioned that setting userdata is not idempotent nor synchronous. You have to wait until values settle.

  • That’s tricky. how do you wait… ? I where already trying soemthing like that.
  • How do you detect when it’s updated ?
  • And then you still have the problem that the user not know why it takes so long to open the door.

Only trick is possible compare the userData with something you have in variable.
But wrong time that i tried it and failed. Mabye i see the solution tomorrow… :open_mouth:

This need some thinking…


I found the discussion here:

At present there are no interfaces to let a script know when userdata is available and updates to it have settled. This bug needs to opened in GitHub.


here’s a pretty simple entity script that waits until it has user data to do stuff. agree that. a convenience method would be nice. however, it’s not just userdata – there’s no guaranteed delivery order for properties, so if the whole thing is bigger than an MTU, you may not have ‘color’ or ‘dimensions’ or something right away either. if you really need to read that data at preload, i’d recommend this kind of pattern. best!!

(function() {

var _this = this;

this.preload = function(entityId) {
    this.entityId = entityId;
    this.initTimeout = null;

this.initialize = function(entityId) {
    print('JBP should initialize' + entityId)
    var properties = Entities.getEntityProperties(entityId);
    if (properties.hasOwnProperty('userData') === false) {
        _this.initTimeout = Script.setTimeout(function() {
            print('JBP no user data yet, try again in one second')
        }, 1000)

    } else if (properties.userData === "") {
        _this.initTimeout = Script.setTimeout(function() {
            print('JBP user data is empty string, try again in one second')
        }, 1000)
    } else {
        //if you're not expecting an object you probably don't need this section
        print('JBP userdata before parse attempt' + properties.userData)
        _this.userData = null;
        try {
            _this.userData = JSON.parse(properties.userData);
        } catch (err) {
            print('JBP error parsing json');
            print('JBP properties are:' + properties.userData);

        //access it at _this.userData

this.unload = function() {

    if (this.initTimeout !== null) {



can we agree that this workable 50 lines of code is the most hideous design pattern in the known universe? I’d say this is a fine example for a high priority missing feature request - a simple means to wait for the availability of property values.


eh its not pretty but you can copy paste. would be a nice feature but i wouldn’t call this high priority – its doable in js so that stuff usually doesnt make it very high on the C++ dev list. you can make a library and store it globally if you want it to look cleaner.