Aura/Tint HealthColor thinks every token is a PC and doesn't recognize NPCs as NPCs

I first tested a group of scripts in a new game to see if functionally they were compatible. Everything worked great and as expected. I then installed the same scripts into my existing game and they all appear to work except for one issue. The Aura/Tint HealthColor script treats all NPCs as PCs. I've double checked the character sheets for the tokens and they are all marked as NPC. I've even recreated one from scratch to ensure it wasn't some weird setting. But the HeathColor feature only works for the NPC tokens when I have the Script setting for PCs turned on. I've tried deleting the script, and re-adding it, nothing works. No errors in the console output either, just the fact that the feature only works for NPCs if I have the PC setting turned on. EDIT: I've gone and imported the script itself (v1.6) from dxwarlock's github and threw some logs into it. I'm pretty sure its due to the following line and the way I have character sheets for NPCs and Enemies setup. Line 39 of his code states; var type = (oCharacter === undefined || oCharacter.get("controlledby") === "") ? 'Monster' : 'Player'; I have the enemy and NPCs set to owned by "Dungeon Master" (which is me) and that logs an ID in the oCharacter ControlledBy property. Since the type statement is looking for undefined or empty string (meaning no controlledBy) that is the only way it will be marked as a Monster. This seems like a design flaw in the code and its not logged anywhere as a requirement from what I can find.

Health/Tint and many other scripts treat characters as owned by the GM if their ControlledBy is empty.  It used to be impossible to tell if a player was a GM, so there was no other way to do it. Even now it's still tricky to identify if a player is a GM, so this is the easiest way for script writers to handle it, and it's very common. Since there's no need to set yourself as controller if a character if youre the GM (since you have full access to all characters anyway), this matches how most people use the characters so its rare that it causes a problem. Is there a reason you need to have a controller set in your npcs and monsters?

GiGs said: Health/Tint and many other scripts treat characters as owned by the GM if their ControlledBy is empty.  It used to be impossible to tell if a player was a GM, so there was no other way to do it. Even now it's still tricky to identify if a player is a GM, so this is the easiest way for script writers to handle it, and it's very common. Since there's no need to set yourself as controller if a character if youre the GM (since you have full access to all characters anyway), this matches how most people use the characters so its rare that it causes a problem. Is there a reason you need to have a controller set in your npcs and monsters? I can think of at least one scenario where I want a player to be able to move an NPC who is following them but who doesn't qualify as a companion or player themself. The bigger issue I see here is that this sort of best practice information is not documented in the code that uses it, or anywhere I've found. It isn't intuitive to have the Dungeon Master choice in the dropdown if not selecting anything does the same thing. With that being said you could flip the question, is there ever a scenario you need to assign controlled by to the Dungeon Master if not selecting any does the same thing? Its redundant to include it as a choice. I only came upon this fact because I took the effort to track down the code repository, and have the capability to read and troubleshoot code. It wasn't in any other documentation I've stumbled across on this site or the variety of intro to expert youtube video's on Roll20 I've watched. I just wish this excellent script did something to make it obvious that not selecting a controlled by was a requirement. Just thinking quickly, I could see a possible easy fix (if possible) would be to provide a dropdown to select who is the Dungeon Master in the settings for the script (!aura). Then you'd change the above mentioned line of code to evaluate on three conditions, the third being if the controlled by ID matches the selected config setting for Dungeon Master. Only thing I don't know (cuz I've not looked into the API syntax) is if you can produce a player dropdown via the Roll20 API.

I only came upon this fact because I took the effort to track down the code repository, and have the capability to read and troubleshoot code.  I saw your subject title, and knew what the issue was, and was going to tell you but you had already figured it out. If you hadnt had the ability to read code, you'd have found out from the community. Just thinking quickly, I could see a possible easy fix (if possible) would be to provide a dropdown to select who is the Dungeon Master in the settings for the script (!aura).  This would be a fix for your game, but many games have multiple GMs, or rotating GMs, so it wouldnt work for those. And again, this would only fix this script. This method is used by many  scripts. The bigger issue I see here is that this sort of best practice information is not documented in the code that uses it, or anywhere I've found.  This is true. It's something script writers dont think about, because its the default practice - most people who run games dont set the controlledby of NPCs or Monsters, so it doesnt occur to people to give this documentation. Every now and then someone who does pops up on the forums pointing out some script or other isnt working, and discovers this fact. It could be added to the documentation of the scripts that do it - but every script has a different author (if its not Aaron, that is...), so its not an easy issue to get them all updated. It isn't intuitive to have the Dungeon Master choice in the dropdown if not selecting anything does the same thing.  This however is a different issue. Whoever the GM is, they are also a player, so their name needs to be in that dropdown.

This is true. It's something script writers dont think about, because its the default practice - most people who run games dont set the controlledby of NPCs or Monsters, so it doesnt occur to people to give this documentation. I'm just ranting at this point but it bothers me when processes that are supposed to be widely adopted are only discover-able by asking someone who's been around longer, especially when there are plenty of great points along a new roll20's GM path to learning the tool that it could be built-in but is not. I don't recall anywhere in the walkthrough tutorial that this was mentioned. I appreciate your willingness to talk me through it though. And with rotating GMs it makes a lot of sense to leave it blank. I had not considered that scenario. Would be a pain in the butt to have to reassign all those items. Thanks!

Matt said: I'm just ranting at this point but it bothers me when processes that are supposed to be widely adopted are only discover-able by asking someone who's been around longer, especially when there are plenty of great points along a new roll20's GM path to learning the tool that it could be built-in but is not. I don't recall anywhere in the walkthrough tutorial that this was mentioned. I understand your frustration. Something like this wouldn't be covered in the walkthrough, because that is created by roll20 devs and what we have here are justr thinks that members of the community have developed along the way. There was no group decision to use the controlledby field in this way, just individual script writers (who arent roll20 devs) trying to figure out how to do things, and hitting on this approach. And likely, different script writers coming up with the approach independently.  Then when people who didnt do it this way asked on the forums for help, those of us who had been around a while noticed that scripts often used this practice, and that was the most likely issue. This could be definitely added to the wiki (which is maintained by volunteers too, who add to it in their own time, so again its understandable why its not there), to help people in future. PS: Being frustrated by incomplete documentation is a standard rite of passage for scripters and sheet builders here, lol. Most of the documentation available is made by volunteers in the community who have had to learn everything by trial and error. So any gaps in documentation or understandable. That's not to diminish your frustration - it really sucks. But it is what it is.