[Script] Automatic Temp HP Management

The problem is this line: obj.set({HPVALUE : hp.target, THPVALUE : thptarget}); In Javascript, it doesn't translate the "HPVALUE" variable into "bar1_value" before issuing the set command when you write it that way. So you're literally trying to write to the "HPVALUE" property on the object, which doesn't exist. Instead, do: var newattrs = {}; newattrs[HPVALUE] = hp.target; newattrs[THPVALUE] = thptarget; obj.set(newattrs); And it should work.

Alex L. said: HoneyBadger said: I don't want to use a bar for temp hp. In that case you would need to find the attrib obj you want to use, using its name and the id of the character. You could get the attrib linked to the hp bar then use that to get the id of the character. @Riley: It would be a lot easyer if you exposed the id of the character link to the token. Oh, whoops. Oversight. I'll add that in the next update. Kevin K. said: So it's still not behaving as expected.  I have a token with 6 in Bar3 and 34 in Bar1.   When I do -5 on Bar1, my log of the target object says:  {"bar3_value":1,"bar1_value":34}, which is what I use in obj.set(). That's as expected.  However, the map still shows Bar1 is 29 and Bar3 is 6.   For an extra dose of weird: if I then do a -1 to Bar1, the log reports {"bar3_value":0,"bar1_value":29}, even though the map shows Bar3 is 6 and Bar1 is 28. So the object is updating, but the map is not, and when the next change happens, the map and object are out of sync with one another. Alex L. said: If you edit the bar it edits the linked atrib as far as i know. Ah, this may not be the case in the API. I think the way I'm doing it in Roll20 is when I display that values in the bar, if the bar is linked to an attribute, I'm actually ignoring the bar value and just show the current value of the attribute. So currently the correct way to do it in the API would be to check and see if a Bar is linked to an Attribute, and if it is you need to modify the Attribute's value, not the bar's value.

Your code is incorrect at: setBar(obj, HPBAR, target.hp); setBar(obj, THPBAR, target.thp); You probably meant setBar(obj, HPBAR, target[HPVALUE]);

I'm not totally sure I follow. If you could break it down into a more simple example/test case that causes the race condition without the extra stuff that would be helpful.

Okay, but what I'm wondering is, where exactly is the race condition? I assume it's someplace in all the calculations you're doing for the temp HP stuff? What I need is like "if you respond to a change event for a bar1_value by setting the bar1_value, then it doesn't work"...which I think is what you're saying? The reason why I'm also confused is because whether you do a straight "set value to 50" or type "-5" should be immaterial to the API. All of that is handled client-side before any save() event is sent to the server. So there shouldn't be any difference there. The token that you're doing this test on, are any of the bars linked to Character attributes?

Also looking at my code it seems that I was wrong about the attribute and the bar1_value being explicitly linked. Rather it seems I was just setting them both manually. So I'm going to have to re-think how I'm handling this throughout Roll20 and then I'll update the API docs accordingly.

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.