[5e Shaped] Can I Hide enemy name from a player with "show Target names" selected but show enemy names to the GM on Initiative tracker?

     The subject line pretty well sums it up. I have one player who always wants to know their character to know what enemies, every thing about them, and all their stats. The group consensus is that would 1 void the favored enemy ability of rangers and to doesn't allow the GM to have suspense in enemies like a  Gass Spore looking like a Beholder until the players realize other wise. One player targets it and no matter what they know exactly what they are fighting. The rest of the group is in agreement that showing AC if fine because it lets player know their chance to hit or damage an enemy that their character might perceive in actual combat. I show a health bar because again you can have some idea how damaged an enemy is by its wounds, changes in its movement, stance, etc. and at the same time the health bar is not an exact number, its an enigmatic range only giving them a vague idea. That's perfect.      To know more than that, we as a group decided on a DC10+CR intelligence based check. Applicable skills (Arcana, History, Nature, and Religion) can replace vs the same DC if proficient. Testing with an inapplicable skill means the check is at disadvantage like using Religion for a Beast, Nature for a standard Hominoid, Arcana for Demon, or History for Construct. Your still making a Intelligence check and might with high proficiency/expertise actually out way the disadvantage but their is also usually some overlap from studies that cross paths, example the study of history might have lead into a minor study in specific construct for better understanding the context of a story, Arcana might have studied a specific demon while working on protection spell like "Protection from Evil and good". This also means higher caps for using skills because rolling two 20s on a disadvantage check will still get you a higher roll than you ever could have gotten with just an intelligence check.      That said, to make these things significant, in agreement with what the group as whole decided, I would like to make sure I can lock this down, so our IF our one descending voice were to select "show Target names" on their character, It wouldn't impact the group by them calling out the monster they are fighting and specific details about its abilities. That happened and was how this conversation came about, but the player didn't have the setting, I was displaying attackers in emotes. That has been fixed. The issue discussed and voted on, but I think their is still a possibility of re-occurrence, so I am trying to resolve it before it happens. It might not, but better to have a solution and not need it than need it and not have one. Avoiding in session arguments at the table seems like a good route and if the player REALLY can't let it go, I can say "for the session its programmed as it is", if we can talk about it after the session and compromise on something that ether makes us both happy or both slightly annoyed but not unbearably so then we will try that and see if it works.

You want an entry in the Tracker that's visible to the GM but not visible to the players? Put a token on the map on the GM layer, give it the name you want, and add it to the Tracker. Voila! I do this all the time, with the tokens hidden by Fog of War.

Not exactly what I was hoping for. I get putting "fake tokens" as peaces but then I can't user the tracker to Identify them for movement since the initiative tracker and its token with macros, will not be the one I move for the players to see.(I can already have entries on the tracker not list names to the players, It's a token option weather I share them or not. I hide token names and players don't have the rights to change them. The issue is player can make a changer to their character so that all attacks display their targets name and AC... so they can create macro.... with a "/w me" and about any action and see it immediately if I use the same token at all.) So are you saying there is no way set an NPC to override the character option "show target names" and hide the name anyway? I have to choose between having a token named on the tracker for me to see and letting the player see on attack, or Having the tracker blank on the tracker to be blank to the player?

You can rename a token to something like "Strange Creature" or "Cloaked Figure" and it will appear that way in the Turn Tracker. As GM you would have to remember what the real name is, but you could have that be the character name (instead of the token name) or have it in the GM Notes.

As with so much in life it is all a matter of control... on the left we have the DM view, all seeing, all knowing. On the right a variety of Player views; the Goblin is 'in journal' and 'edit/control' enabled, the Yeti just 'in journal' and the Panther is neither, don't want them to see the token's name? Don't give them edit access :) Sadly, there is nothing you can do about players calling the stats directly from the monster sheet bar changing ALL of the attribute names in a custom version of the sheet (not advised...), if it gets to that point I'd sooner get new players ;)

I'd recommend changing the token name. I do this in general anyway, because "Abominable Yeti 1", "Abominable Yeti 2", "Abominable Yeti 3" and "Abominable Yeti 4" just clutter up the landscape. I usually name them "AY1",  "AY2", "AY3", and  "AY4". After your players get used to this, they won't question that "M1" might be Monster 1, Gas Spore 1 or Beholder 1.

- I have token names permissions off. (So players don't see token names in the tracker) - In order to rename every token I need to pull them out and rename them manually which is a problem for any sort of on the fly adjustments because 1.I would have to create NPC then edit each one deleting or changing the names one by one. (could delete the display names on all NPC templates in advanced but #2. 2.If makes it difficult to track NPCs when I don't have them memorized, without the names to remind me what I am looking at. If I have all the units the same its not a problem, but if I mange an off the cuff encounter with a  melee, a casters, archer, and a rogue its not like I have every token image memorized. It will be just 4 different likely human faces and will have to open journals when I forget what it. (Though I made a stats macro that will display the  the character info with character name instead of the display token name) - "Getting new players" is not an answer. I am playing with my friends, we have fun, I just a have disagreement with one player, its not like it makes him unbearable to play with, or that he in anyway is disposable to the game for me or the other players. This is not an adventures league game where you play with random strangers you don't care about. This is a group of friends that have played pen and paper for 5 years going digital because situations will not let us get together on one room any more. This particular issue, is basically like having a player who peeks over the GM wall in a pen and paper game. If you make them sit on the other side of another player as a rule then you never have problems with them again . If you leave them next to the GM screen, you like them, they are your friend, and you want to play with them, but they can't help that they will peek once in a while. - Based on these replies everyone is avoiding saying " No, this sheet is not capable of setting NPC anonymity " their are some partial work a rounds but players will always be able to call NPC stats at will once they know how. They can just make a simple macro to call stats. So I am curious how many of you have played a game with no GM screen at all? That is basically the issue here. I can trust my players not to look and to actively avoid looking 99% of the time... but that 1% will always be at critical moments when its important they don't know but their desire become higher than their restraint. Which is why I have one player (a friend) who has basically said he isn't going to fight it and he really doesn't want to. If he can see it, he wants to know what it is. I get that. Its why we have GM screens. In a digital form like roll30 peeking over the screen is done without anyone being able to what the player and say "hay stay on your side of the screen". I think most GMs have had to do that at least a few times in pen and paper games. A lack of some control stop "peeking" is a bit of surprise to me. All that is needed, just like pen and paper gm screen is to add a layer of effort that will deter them to make it a little harder to peek, to raise up in their seat to get a better view, sort of speak. A option on NPCs that turns on "anonymity to players" to hide the name should be enough of a wall. Since players don't generally have permissions to NPCs they can't change it. They could still call stats and traits one at a time but all they really want is a name so they crack open an monster manual "just looking for something" and know everything about their target. Which is way easier in a tab on a computer window. - Can I live without this feature? Yes, however I play pen and paper with a GM screen for reason. That reason still exists on roll20. The players haven't changed. It's almost a grantee someone will look when the mystery gets high is because that's when their curiosity will get the better of them. It's also when it sucks the most if they succeed. If the [5e Shaped] developers see this and can understand what I am saying here. Since no one can tell me anything but a work around, I am thinking this feature does not exist. If you would consider putting it on your list.... that would be awesome. (there is a HIDE INFO block, but it appears to be for the character its on not for "attackers". It would be a greet place for "Hide token name from Attackers" and "Hide AC from Attackers" ... Or perhaps an easier solution, would be to allow the GM to lock "Targets Name on Attacks and Saves"  and "Target's AC on Attacks", so I could disable them and the player couldn't turn them on even with edit writes.

Here is a solution that may work for you. It does require set up, but should give you total anonymity. Use dummy tokens on the play table. Set aside an area of every map that is covered by plain fog of war. Place your real tokens there. Give them the same names as their counterparts on the visible area. Let the players interact with the dummy tokens, while you use the real ones that are hidden from view. There is nothing for the player to backtrack because they only see a token that is not linked to a character sheet. The quickest way to create such tokens would be: 1) drag the real token to the FoW area and copy it. 2) paste the duplicate in the visible area 3) Open the duplicate token and unlink it from the sheet. Do any renaming you might care to do. This way the dummy token and the real token share image and possibly name, making them easier to coordinate. This was adapted from this Stupid Trick , but might be usable for your purposes. I know it's more set-up, but you have a player that is causing more than the normal amount of prepwork.

So this would work, but like you said its a lot of setup. I can't do that for on the fly random encounters. If I have a more important Boss fight which is a lot more planed out. Then yes, I can do this. An option to disable the character Option so display names would be a lot easier, permanent, and would cover all NPCs. This is however and option if the sheet developers are not willing to add a GM lock on showing target names (and possibly AC, for other players. I just need the names blocked).

(0.0) some awesome tips on that thread, I have been skimming for 2 mins and I already found I few I like. Bookmarked that one. Thank you for the link!

Quite apart from sheet settings, there is nothing that stops a determined player from targeting any token and pinging its attributes. It's built into the system (for very good purpose). So yeah, it's a pain, but hopefully the copy-paste-remove sheet link can be gotten down to muscle memory after some practice. Yeah, it's a pain, but you are dealing with a difficult player who is kind of forcing your hand to go to extra lengths. Daniel F. said: So this would work, but like you said its a lot of setup. I can't do that for on the fly random encounters. If I have a more important Boss fight which is a lot more planed out. Then yes, I can do this. An option to disable the character Option so display names would be a lot easier, permanent, and would cover all NPCs. This is however and option if the sheet developers are not willing to add a GM lock on showing target names (and possibly AC, for other players. I just need the names blocked).

Daniel F. said: (0.0) some awesome tips on that thread, I have been skimming for 2 mins and I already found I few I like. Bookmarked that one. Thank you for the link! Thanks. I'm really pleased with the community innovation and participation in that thread.

So I was playing around with your work around and came up with slight alteration. If I make a "?" unknown token then put the real character on board at the GM layer, I can "shadow" the unknown tokens to track which is which. Again its a bit of work and a lot of switching between GM overlay and object management. But it means I can actually use the token for the enemy around the board and macros, just in GM overlay mode, hover over the initiative tracker and quickly see who is next, and the token they see will not report anything back to players. Not a "fix" but with only a slight adjustment to your stated idea its 90% there. I also, realize I can run invisible tokens from the GM overlay and the pretty much work. You just need to attack their own token for rolls and ignore target information. I still feel like, a GM lock on "Targets Name on Attacks and Saves"  and "Target's AC on Attacks" should be an easy fix for developers, since the option was off by default anyway. I just need to be able to turn them off and hide them so adding a "GM view only" would work. Alternately, they could just make the Character sheet options button only visible to GM since of the time once you set it up you shouldn't need to touch it again.

Hey Daniel, There are two API script features that might help you out if you choose to go Pro: The Bump script automatically manages "shadowed" tokens like you're talking about without you having to set it up manually. Currently it is used to hide tokens from the players completely while still enabling them to be moved around on the tokens layer, but it could easily be adapted to do what you need it to, I imagine The shaped companion script has an option to automatically label new tokens with a default "override name" like "Unknown monster". In combination with TokenNameNumber, this will give you automatic numbering to distinguish new tokens dropped on the table top. So new monsters would automatically be labelled things like "Monster 2", "Monster 5" when dropped on the tabletop. Obviously this does mean that you end up with generic names in the turn tracker, however. Personally I don't find this an issue as a DM; the images  make it clear to me what the creatures are and I've never found myself forgetting which creatures I've actually put into an encounter. If that's a problem for you then you'll need to go down the "shadowed tokens" route - and realistically the only way of making that easy to use is going to be API scripting with something like Bump. "GM Locking" of fields on the character sheet is not really possible. The character sheet code has no idea whether it is running on a GM's PC or not because this information is not exposed by the underlying application. The best that could probably be achieved is an API script that watches for changes to a particular option checkbox and undoes them if they are made on a PC sheet. Note that the API can't tell who made specific changes, so this restriction would apply to GMs as well - so you'd have to have a separate GM-only API command to turn off the restriction. It'd be horribly clunky and in the end as numerous people have pointed out, it still doesn't stop bad players from bypassing all of this by referencing attributes directly if they really want to. Roll20 is not designed to enforce rules on players, and attempting to make it do so is a big waste of time. TBH, by far the simplest way of achieving your goal is to agree with your players that the "show target's name" field should be switched off for PCs. If you can't trust all your players to honour this then you have a serious group dynamics problem that you need to fix before you worry about tweaking things with Roll20 character sheets.

Lucian said: Hey Daniel, There are two API script features that might help you out if you choose to go Pro: The Bump script automatically manages "shadowed" tokens like you're talking about without you having to set it up manually. Currently it is used to hide tokens from the players completely while still enabling them to be moved around on the tokens layer, but it could easily be adapted to do what you need it to, I imagine The shaped companion script has an option to automatically label new tokens with a default "override name" like "Unknown monster". In combination with TokenNameNumber, this will give you automatic numbering to distinguish new tokens dropped on the table top. So new monsters would automatically be labelled things like "Monster 2", "Monster 5" when dropped on the tabletop. Obviously this does mean that you end up with generic names in the turn tracker, however. Personally I don't find this an issue as a DM; the images  make it clear to me what the creatures are and I've never found myself forgetting which creatures I've actually put into an encounter. If that's a problem for you then you'll need to go down the "shadowed tokens" route - and realistically the only way of making that easy to use is going to be API scripting with something like Bump. "GM Locking" of fields on the character sheet is not really possible. The character sheet code has no idea whether it is running on a GM's PC or not because this information is not exposed by the underlying application. The best that could probably be achieved is an API script that watches for changes to a particular option checkbox and undoes them if they are made on a PC sheet. Note that the API can't tell who made specific changes, so this restriction would apply to GMs as well - so you'd have to have a separate GM-only API command to turn off the restriction. It'd be horribly clunky and in the end as numerous people have pointed out, it still doesn't stop bad players from bypassing all of this by referencing attributes directly if they really want to. Roll20 is not designed to enforce rules on players, and attempting to make it do so is a big waste of time. TBH, by far the simplest way of achieving your goal is to agree with your players that the "show target's name" field should be switched off for PCs. If you can't trust all your players to honour this then you have a serious group dynamics problem that you need to fix before you worry about tweaking things with Roll20 character sheets.     Thanks for the information. My second game on this system was supposed to be two days ago but it got bumped back two weeks. As a result, I have two more weeks to solve problems, build loot tables, write story content, and refine every thing. That said, loot tables are my next priority as I am working to make a system of loot that allows for random rolls like the DMG however rolling high just giving you higher tier gear options on your chart I am going to try and sort magic items so that higher roles lean to magic items more usable to the groups members (not necessarily the looting member) based on class and roles the group fills...so on a natural 20 your not going to give the group a "Rod of the Pact Keeper +3" when their is no warlock in the group who could use it, rolling low will one time use loot, and 1 lower level or cursed loot. Not sure how long that will take, but depending on when I get it done... I'am looking am looking at going pro and trying to get dynamic lighting, random NPC health, and it looks like now the Bump script "shadow token management". I can get flustered and confused when I am on the spot socially and even though these are my friends and its a game, I feel responsible for flow and if I get hurried I am prone to confusion. As a result of this my last game I spent a great deal of time re-organizing my notes into one-note, instead of organized in separate word documents because I believe "shuffling papers" being multiple word documents will be cleaner with tabs on a single document.     So your post it great except the last argument. I have seen this before many times but I think their is disconnect from reality in it when your telling to someone else instead of following it.   To clarify, I am a former marine and many of my friends are former marines and have been my friends for years. I would trust most of them with my life but only a few of them with my wallet, and less alone with my wife. That is to say I know them and except who they are. I WANT them specifically to be the people I play with. If you have kids, Its kind of the same. You don't through out the kids because they stole a cookie after you told them not to. They get in trouble, they feel bad, they say they will not do it again,... you put the cookie jar on the top shelf anyway.     Maybe I don't need lock down this feature, maybe its never going to be an issue, But just like my Dad did when I was little, I still think its best to have a high shelf ready. My dad didn't need it for 3 of his 4 boys because he know that many would listen. My Platoon Sargent knew he didn't need to hold all hands formations at 2300 when we were under a 0001-0500 curfew for 55 of the 56 marines. But both knew the same thing... Their is always one.     I am not going to get rid of good friends over "cheating" on a game. I want to play with my friends. I know I can't eliminate this issue all together, any more than my dad thought a high shelf would really stop 4 boys who really wanted it, my platoon Sargent thought the all hands formations would really stop someone from heading off base and breaking curfew, my Previous GMs thought the cardboard screen they put up would stop players from trying to steal a peek. However, setting the bar a little higher can a surprising good reminder that your doing something you shouldn't, make you pause and think about is it worth it?      All that in mind, I would point out that  "Target's name on Attacks and Saves" is targeting the token not the character sheet. The token already has permissions on it under Advanced --> Player Permission --> Name --> See ...that if unchecked doesn't let the player see the token name on the Initiative Tracker, while showing it to the GM. The intent of the feature is to allow the GM to hide/show the name to/from players. I can see that its this name that the players call with this option because if I blank it the players attacks see nothing, also If I rename it to "dog" they see "# to Hit Dog AC12, reach 5ft" ...so can't we already lock this field? All I need is for the same permission button to apply to the "Target's name on Attacks and Saves" on the character sheet.. .. That is as high as shelf as I care to put it on. Since this is pre-existing permission, could you just make the same check box relevant to the call you enable to look at the same input box? (Enter bad VBA coding example, Sorry its not at least Javascript . VBA is the only thing I a have worked with and this is just for thought analysis.) Sub FIND_NAME      Dim VarialblA As String: VariablA=" "      If Check_box_see_name = true, then           VeriableA = input_box_name           Else:Exit Sub      End if End Sub     I am not sure what other calls might be involved, but if their is variable set by the box that can be call for input and a check mark that says if a player can pull it than It seems like their should be a way to a least limit character sheets to verify the box is unchecked or display a blank value as the return default for that variable. This would mean that all characters, including the GMs, respect the check box but NPCs might not have too, based on that setting. I am sure its more complicated than that, but I would be confused if this is really all that hard to implement. I have been wrong before and will take your word for it, if you say it is. But since the option is already on the token it doesn't even seem like adding a feature but respecting and existing one. Am I wrong?  ...again, lol.

Hey Daniel, On the social dynamics: that's your call, I won't get involved in that. On the technical side: what you're missing is that custom character sheet code only has access to a very limited subset of the whole Roll20 platform's functionality. The custom character sheet code that users can write has no access to any of the token visibility settings and this is a limitation imposed by the Roll20 platform itself. If your pseudo-VBA was part of a character sheet, "Check_box_see_name" simply wouldn't be visible/available so you couldn't check its state. Just because you as a human user of the site can see a checkbox, it doesn't mean that every bit of code can get access to it - if that were the case websites would be incredibly vulnerable to all sorts of malicious scripting attacks. It would take a long time to explain the details of this, but I'm afraid you're just going to have to trust me that changing this would involve some pretty substantial modifications to how the core platform works, and it's exceptionally unlikely that Roll20 would schedule a big chunk of development time for a feature like this. You're welcome to open a suggestion on the suggestion forum about this if you really want to try and persuade them to implement this, but I think you'd almost certainly be wasting your time.

Lucian said: Hey Daniel, On the social dynamics: that's your call, I won't get involved in that. On the technical side: what you're missing is that custom character sheet code only has access to a very limited subset of the whole Roll20 platform's functionality. The custom character sheet code that users can write has no access to any of the token visibility settings and this is a limitation imposed by the Roll20 platform itself. If your pseudo-VBA was part of a character sheet, "Check_box_see_name" simply wouldn't be visible/available so you couldn't check its state. Just because you as a human user of the site can see a checkbox, it doesn't mean that every bit of code can get access to it - if that were the case websites would be incredibly vulnerable to all sorts of malicious scripting attacks. It would take a long time to explain the details of this, but I'm afraid you're just going to have to trust me that changing this would involve some pretty substantial modifications to how the core platform works, and it's exceptionally unlikely that Roll20 would schedule a big chunk of development time for a feature like this. You're welcome to open a suggestion on the suggestion forum about this if you really want to try and persuade them to implement this, but I think you'd almost certainly be wasting your time. Understood, and I believe you. I am just putting out ideas and approaches because I have hope (perhaps false hope, lol). One last question and I will submit to work arounds. Since the tracker is calling the token name with applied permissions and your calling the token name, is the initiative tracker something you have access to? This maybe a bit of an odd solution possibility, but if you can pull the name from the initiative tracker when it is available then, when I roll initiative (before players would typically attack) then the permissions would already be applied. Again, their is a chance you don't have access to the code/variable. Anyway, I also get this is something you don't seem keen on addressing anyway as I don't see anyone else chiming in requesting this feature and that is likely enough for you not to want to spend time perusing it.   At any rate, thank you for giving me some of your precious time and explaining the situation to me, as well as providing some possible options. I know I come across badly and I am told like the scorpion my nature makes things more difficult than they need to be, so I appreciate your patience and replies. Thanks again!! Stay Awesome!!

The character sheet code only has access to the attributes of a single character and that's it.  It can't read or write from any other part of the platform. API scripts have a lot more access and could in theory do more of the things you're looking for, but making character sheets trigger the API is somewhat fiddly and character sheet authors generally avoid doing it because it limits the usefulness of a sheet to non-pro users. API scripts cannot directly control the UI of a  character sheet, however, so there's no way of using a script to put the "show target's name" cookie jar on the high shelf. The best solution that I can think of - not ideal but perhaps enough for what you've asked for - is a simple API script that listens for changes to that checkbox and unticks it automatically if it is checked for a PC sheet. For extra "big brother is watching you" factor, you can also have it whisper to the GM when a player attempts this. It's not a high shelf so much as an ever-vigilant invisible cookie guardian that slams the lid back on the jar whenever anyone opens it. Obviously this requires a pro subscription. BTW, you mentioned that you are a co-GM. If you are thinking of getting Pro, bear in mind that the important thing is that the creator of the Roll20 game is a pro user - so if that's one of your co-GMs you may need to sort something out with them. It should be possible to copy the game but onto your account somehow but I confess I'm not an expert on this. If this situation does apply to you I recommend asking for advice before going ahead with getting your upgraded subscription.

Lucian said: The character sheet code only has access to the attributes of a single character and that's it.  It can't read or write from any other part of the platform. API scripts have a lot more access and could in theory do more of the things you're looking for, but making character sheets trigger the API is somewhat fiddly and character sheet authors generally avoid doing it because it limits the usefulness of a sheet to non-pro users. API scripts cannot directly control the UI of a  character sheet, however, so there's no way of using a script to put the "show target's name" cookie jar on the high shelf. The best solution that I can think of - not ideal but perhaps enough for what you've asked for - is a simple API script that listens for changes to that checkbox and unticks it automatically if it is checked for a PC sheet. For extra "big brother is watching you" factor, you can also have it whisper to the GM when a player attempts this. It's not a high shelf so much as an ever-vigilant invisible cookie guardian that slams the lid back on the jar whenever anyone opens it. Obviously this requires a pro subscription. BTW, you mentioned that you are a co-GM. If you are thinking of getting Pro, bear in mind that the important thing is that the creator of the Roll20 game is a pro user - so if that's one of your co-GMs you may need to sort something out with them. It should be possible to copy the game but onto your account somehow but I confess I'm not an expert on this. If this situation does apply to you I recommend asking for advice before going ahead with getting your upgraded subscription. - @Lucian , before you read this (if you haven't) let me clarify…. Thank you, and while I am questioning your statements below, its not that I am questioning your right. I am just trying to understand why? Because your answer didn't make since to me with my knowledge of programing. It is intended to explain my confusion more than judge your answer.  If I can understand the root of why "I can't" do something it means I might understand not to ask other questions that would be limited for the same reason .      I am a little confused because your saying the character sheet " can't read or write from any other part of the platform" but it is pulling the name of the token from the token from either the box or a variable. If it wasn't I could make changes on the token an watch it effect the text output of a different character macro.... It is doing that 100%, so having access to another variable from the same token has to be possible, its just a matter of weather Roll20 tells what that variable's name is and the character sheet knows to reference it. If your saying definitively I the character sheet can't reference a variable change on the token to determine macro output...then how is it doing it now, when I change the name of the macro to "dog"? How is it puling AC from the character sheet attacked to that macro? Its already doing what your saying it can't.... So that's a really odd reason for it not to repeat that with a different variable on the same token. My guess is that the "name block" is a public variable and the sheet references. If the character sheet knows the name of the "see check box" and its a public variable, the sheet should be able to reference it the same way.       As far as the API script and co-GMs. We looked at promoting them one at a time for GMs, however, roll20 does not allow for me to hide my campaign notes, folders, and/or maps. So its not possible for us to share as intended. We are going to have to have 3 separate campaigns in order for use not to show everything we do so the other players/GMs. I put all my stuff in a folder, but for some reason, it auto expands all the folders every time the promoted GM accesses it so they end up having to look through my campaign notes just to close them and get them our of their way. The map goes to the last used by the GM/Co GM when you log in at that level, so any planning I do building a map and setting it up or vise versa it immediately showed to them when they log in to work on theirs. All of this is to say , my partners have decided its to much of a pain to try and co-gm under my campaign. Instead we have a google share drive where we share resources. We have an automated excel sheet for a bag of holding. We are actually tracking characters on MorePurpleMoreBetter character sheets on our local computers (updating a copy to the google drive between sessions for the reference of other GMs). They are also, grabbing my "how to" notes, one can not afford API/Pro and the other simply has no interest. So I need to make a functional version without those, then I will likely go API/Pro and if I can make it impressive enough to justify the extra work in implementing those features, I might get them to follow. I suspect, that lighting is too much work for them, and If I can't even make aura's less annoying (the opacity is too high and when they stack I can't see the map very well) then they question trying to put the effort in that to make other features work, since what should be a simple slider or hex settable is not their. Basically they are taking the stance that if its behind the "pay wall" they don't care about it because they can play D&D with a camera pointed at actual tables if we need to. I enjoy the automation, writing instructions, macros, and figuring out how things work...So I will likely try once I have some of my more essential stuff taken care of. I need loot tables and to work on my story hooks/paths before I worry about lighting and extra features like dynamic health because I can put a fog of war on everything, then reveal for light and a flat health with random damage will cause enough variation that players my not notice. I am still finding my feet in the campaign and I think that's the busiest part, once I get by basics covered I will move on to extra features. 

@Lucian In case you already saw my last post before I put that top paragraph and for other contributors. Thank you for bearing with me and your patience, I am very much the guy and I am trying to get a grasp of the limits and capabilities of the platform so I can focus on features and look for solutions to maximize game experience for my players. Thank you all for you patience and assistance. I have to really understand things before I can truly learn them. I know a lot of people who can just follow step by step rule and instructions but my mind doesn't function well with out understanding the "why". Fortunately, the "why" usually applies in a large array of places so when I get it, I get it and I can answer some of my own questions.  

It's a reasonable question, and you're right I did somewhat simplify things. Sadly, despite your best efforts to see why not, I'm still right :-P The only interaction that the character sheet has with the "outside world" is through "roll buttons". These are the bits of the sheet that you can click on to generate output in the chat window. When you click on these, the roll20 system takes the expression attached to the roll button and submits it to the chat parser. The chat parser is a piece of Roll20's internal code responsible for making things happen when type stuff into the chat window - like rolling dice and executing macros. When you tick or untick "show target's name" and "show target AC", the character sheet code updates some of these "roll expressions" to include the text "@{target|token_name}" or "@{target|AC}" in the appropriate place in the output template. The next time you click one of the attached roll buttons, these bits of text are passed to the chat parser, which knows how to expand them - including popping up the prompt to select a target, and then accessing the relevant token or character and extracting the requested value. All of this is handled by Roll20 internal code during the process of outputting the roll expression to the chat window; the sheet code never actually sees the results  of the expansion. Large software systems are generally built of smaller modules with limited, well-defined interfaces between them. Individual modules are designed so that they don't need to know about, and can't access, the internal data structures/code of the modules they interact with; they do their part of the job and then hand off the results to the next system without caring about how the next part happens. If you've only ever written small scripts it can seem strange that everything isn't globally accessible to everything else, but when your codebase has millions of lines of code and you're trying to track down a bug, or ensure that user-submitted code can't access things it shouldn't, or test a new piece of code to be sure it won't break any existing functionality, these "arbitrary" restrictions are the difference between order and chaos. To put it in terms that may be more familiar to you: strong modularisation is the software equivalent of the chain of command; sometimes it can feel like it just gets in the way, but when the sh*t hits the fan, having strict rules about who listens to who is absolutely essential.

Lucian said: It's a reasonable question, and you're right I did somewhat simplify things. Sadly, despite your best efforts to see why not, I'm still right :-P The only interaction that the character sheet has with the "outside world" is through "roll buttons". These are the bits of the sheet that you can click on to generate output in the chat window. When you click on these, the roll20 system takes the expression attached to the roll button and submits it to the chat parser. The chat parser is a piece of Roll20's internal code responsible for making things happen when type stuff into the chat window - like rolling dice and executing macros. When you tick or untick "show target's name" and "show target AC", the character sheet code updates some of these "roll expressions" to include the text "@{target|token_name}" or "@{target|AC}" in the appropriate place in the output template. The next time you click one of the attached roll buttons, these bits of text are passed to the chat parser, which knows how to expand them - including popping up the prompt to select a target, and then accessing the relevant token or character and extracting the requested value. All of this is handled by Roll20 internal code during the process of outputting the roll expression to the chat window; the sheet code never actually sees the results  of the expansion. Large software systems are generally built of smaller modules with limited, well-defined interfaces between them. Individual modules are designed so that they don't need to know about, and can't access, the internal data structures/code of the modules they interact with; they do their part of the job and then hand off the results to the next system without caring about how the next part happens. If you've only ever written small scripts it can seem strange that everything isn't globally accessible to everything else, but when your codebase has millions of lines of code and you're trying to track down a bug, or ensure that user-submitted code can't access things it shouldn't, or test a new piece of code to be sure it won't break any existing functionality, these "arbitrary" restrictions are the difference between order and chaos. To put it in terms that may be more familiar to you: strong modularisation is the software equivalent of the chain of command; sometimes it can feel like it just gets in the way, but when the sh*t hits the fan, having strict rules about who listens to who is absolutely essential.      Awesome explanation, Thank you!      My largest program was/is 5,370 lines and I actually had to separate some things just for organization but was using several variables globally because it was directly pulling information from "part 1". It was only about a quarter done when my wife said, "I know it its kind of working for your, but your obsessed. Pick me or Pick programing, one of us is leaving." ... Since programing has yet to cook for me and is not....quite... as sexy. My wife won out.      Let me rephrase, my kind of what you said to see if I am semi close to my understanding. Your sheet doesn't actually add the Target PC name to the macro output in chat. It just calls a reference your calling a "roll expression" in Roll20, that Roll20 pulls and puts into macro form based off of the combine of "roll expression" it excepts and  it interprets from the character sheet call. You can't a edit/stop the output of the "@{target|token_name}" because you don't have a "@{target|token_see_name}" global call for to verify it as a true or false state. If we pretend for a second that Roll moderators were willing to move the variable to the global call list and provide you with the call or "roll expression" it still might not be possible because you would need to be able to call the  "@{target|token_see_name}" then have the button script setup in a {{show_target_name=@{target|token_see_name}}} {{target_name=@{target|token_name}}} Which means they would need also add a "{{show_target_name=1}}" to the Roll20 chat parser to interpret it as well. Which is perhaps a lot to ask of them since it could mean a code adjustment. Even if they have both variables already (since they are tracking the stat in the initiative tracker) its more than just asking for the "@{target|token_see_name}" call and it assumes they handle "token_name" like "character_name". Without those two from the Roll20 staff your hands are tied. Is that about right?

Minor point of clarification: Moderators do not do anything with Roll20 coding.  We're traffic cops, janitors, and general helpers.  You're wanting the Developers to do stuff ;)

Poor choice of words. You are correct and so I stand corrected. And of course my want does not constitute a need or desire on their part. If they see the thread, choose to add it and let us know...GREAT!!... but I rarely see Developer's taking the suggestion of one person. The repeated token aura opacity variability request threads might eventually get attention, but this is not something I am seeing repeated in the threads and who am I? I would guess even if its an "easy fix" from their side, they are not likely to even notice this and have bigger more important things to worry about even if they did..

For your suggestions, we offer the Suggestions & Ideas forum, which is based on voting from the whole community. Please review our Forum Voting wiki page for more information on how voting works, and our Posting to Suggestions & Ideas section of the Code of Conduct . Any further discussion on your suggestion should happen over there.

Lucian said: Hey Daniel, There are two API script features that might help you out if you choose to go Pro: The Bump script automatically manages "shadowed" tokens like you're talking about without you having to set it up manually. Currently it is used to hide tokens from the players completely while still enabling them to be moved around on the tokens layer, but it could easily be adapted to do what you need it to, I imagine The shaped companion script has an option to automatically label new tokens with a default "override name" like "Unknown monster". In combination with TokenNameNumber, this will give you automatic numbering to distinguish new tokens dropped on the table top. So new monsters would automatically be labelled things like "Monster 2", "Monster 5" when dropped on the tabletop. Obviously this does mean that you end up with generic names in the turn tracker, however. Personally I don't find this an issue as a DM; the images  make it clear to me what the creatures are and I've never found myself forgetting which creatures I've actually put into an encounter. If that's a problem for you then you'll need to go down the "shadowed tokens" route - and realistically the only way of making that easy to use is going to be API scripting with something like Bump. "GM Locking" of fields on the character sheet is not really possible. The character sheet code has no idea whether it is running on a GM's PC or not because this information is not exposed by the underlying application. The best that could probably be achieved is an API script that watches for changes to a particular option checkbox and undoes them if they are made on a PC sheet. Note that the API can't tell who made specific changes, so this restriction would apply to GMs as well - so you'd have to have a separate GM-only API command to turn off the restriction. It'd be horribly clunky and in the end as numerous people have pointed out, it still doesn't stop bad players from bypassing all of this by referencing attributes directly if they really want to. Roll20 is not designed to enforce rules on players, and attempting to make it do so is a big waste of time. TBH, by far the simplest way of achieving your goal is to agree with your players that the "show target's name" field should be switched off for PCs. If you can't trust all your players to honour this then you have a serious group dynamics problem that you need to fix before you worry about tweaking things with Roll20 character sheets. And if you can't trust them, make a CSA macro that always turns this option off before rolling initiative or anything.  CSA will let you uncheck that, and you can add all their names to a macro and turn them all off at the same time.  Keep it clickable somewhere like in a menu or on a macro bar and you're good.  Sad you can't trust ur players though, but it sounds like you got some "Fighting" or "Optimizing" players from pg 7 of the DMG.  I love my 'storytellers' and 'actors', much more fun for roleplay.

Wolf Thunderspirit said: And if you can't trust them, make a CSA macro that always turns this option off before rolling initiative or anything.  CSA will let you uncheck that, and you can add all their names to a macro and turn them all off at the same time.  Keep it clickable somewhere like in a menu or on a macro bar and you're good.  Sad you can't trust ur players though, but it sounds like you got some "Fighting" or "Optimizing" players from pg 7 of the DMG.  I love my 'storytellers' and 'actors', much more fun for roleplay. My players are a little of every thing. The one in question, basically know a lot bout monsters and has stats memorized. It's not about optimization but not having to pretend he doesn't know. The way to work around that is for him to actually not know. As a player it bothers him that he knows things his character doesn't but the best I can do about that is "then play a wizard with high intellect and the intellect based skills" which is not the condescending statement it might sound like because the player actually likes playing the high intelligence wizard. If the player is mixing it up, then part of that is not knowing.