Okay, I've figured out what's going on here, bear with me. First off, currently if a bar is linked to an attribute, the attribute's value is what matters for what shows up in the bubble. So keep that in mind. What's happening is this: 1) You are modifying the value of the bubble. This is actually doing two things. First, it sets the value of the bar (bar1_value). 2) The real-time sync server and the API receive the first update for bar1_value. This is what triggers your current script, which *correctly* sets the bar1_value, but since the attribute value is what's being shown in the bubble, that doesn't matter. In addition, your script *attempts* to set the current property of the linked attribute. So at this point we send the set() event to the real-time server. HOWEVER, 3) ...back in Step 1), after the bar1_value is set client-side, the client then also (wanting to be a good, responsible client and keep them in sync) updates the current property of the linked attribute. The thing is, a lot of the time this second client-side event (which again is happening because you modified the bubble) is reaching the server/API *after* you've already tried to set the new current property from step 2). So if I were looking at this from the DB perspective, we see: bar1_value changed (from modifying bubble) bar1_value changed + current changed by API script current changed (from modifying bubble) Because, again, the attribute value is what's shown in the bubble, you're not seeing any change, although if you could see the whole picture you'd see that bar1_value is indeed getting set correctly. So basically the problem is you're modifying the current value of the attribute in response to bar1_value changing, not knowing that there's going to be a separate current change event coming your way like 2ms later. Which is why when you put in the timeout it works, because you're basically causing the script to modify the values after it hears both events from the client. The reason it's variable (sometimes a 1ms timeout works, sometimes it needs to be 10ms) is because that's your client's latency to the real-time server, but you would find (I think) that if you had someone with a really slow connection, they would need you to set a much longer timeout, as their second event would take longer to reach the server/the API. Another interesting thing about this is that the API server has almost no latency (something like 1ms) to the real-time server, whereas any client is going to have at least 30ms if not more. So the API server is able to hear the first event, and set both new values (bar1_value and current) to the real-time server before your client even has time to send the second event for the current attribute property. I'm still not totally sure how I want to handle fixing this, but I thought I would let you know what's going on. In the mean time, your timeout is fine, although as I said if you have any slower connected players they may have issues.