How to keep players from querying NPC tokens?

Is there anyway to prevent players from being able to query basically any information from a token, or the attributes of the associated NPC? Using the following macro, I'm able from a "players" (not GM) account, get basically anything I want from a token. This is just a subset of the info available. I can query repeating info, any stat, etc. /w Players &{template:npcaction} {{rname=NPC Stats}} {{name=@{target|character_name}}} {{description=**Bar 1:** @{target|bar1} / @{target|target|bar1|max} **Bar 2:** @{target|bar2} **Bar 3:** @{target|bar3} ----------------------------------------- **NPC Name:** @{target|npc_name} **CR:** @{target|npc_challenge} **HP:** @{target|target|hp|max} **AC:** @{target|npc_ac} ----------------------------------------- **Senses:** @{target|npc_senses} **Immunities:** @{target|npc_immunities} **Resistances:** @{target|npc_resistances} **Vulnerabilities:** @{target|npc_vulnerabilities} }} Here's another example where I can see the actions an NPC has available /w Players &{template:npcaction} {{rname=@{target|target|repeating_npctrait_$0_name}}} {{name=@{target|character_name}}} {{description=@{target|target|repeating_npctrait_$0_desc} }}

There is not, it's the nature of the design of the data model. That said, I could likely create a version of Bump that would give only a visual representation on the Objects layer, and keep the real version on the GM layer.  That would likely require a small amount of extra effort for you if you have tokens with MarketPlace images, as the API can't create those automatically, but would otherwise work as expected.

How about the social solution: trust your players instead, and if you cannot trust your players, get new players.

That too!

Also, if you suspect people of "cheating" this way, imagine all the fun you could have when you change the stats underways and they are the only one that will notice. *evil grin*

I'm another chiming in for this to be handled at the social level. In my game, player attacks (weapons, spells, whatever) include the defense of whatever they're targeting and I would be rather irate to have that taken away from me ;)

The Aaron said: There is not, it's the nature of the design of the data model. That said, I could likely create a version of Bump that would give only a visual representation on the Objects layer, and keep the real version on the GM layer.  That would likely require a small amount of extra effort for you if you have tokens with MarketPlace images, as the API can't create those automatically, but would otherwise work as expected. You know, Aaron, that might be a great idea if taken a little further. Some things to consider for this script: The copy of the token on the GM layer is the 'official' token.  The PCs can't see it, but it's there. The copy of the token on the token player is just a graphical representation the PCs can see. Allow the players to send API commands to the tokens to modify things like hit points.  (With an option to 'intercept' those commands, requiring the GM to authorize the change.) Benefits The GM could stay on the GM layer, and not have to switch to the token layer to move and interact with tokens. Tokens on the Token layer could be set up to be selectable by players.  So they could actually target npc tokens for things like AE spells rather than the GM having to do everything. Combat automation could start becoming a real thing by clever scripters.

Combat automation could start becoming a real thing by clever scripters. I'll make the same warning I do every time I hear someone talking about automating combat:  Make sure you can handle when (not if) someone forgets a bonus or a penalty to the roll and you need to adjudicate on the fly.  It happens to all of us, even we GMs ;) Also, this would need to be a system-specific script because combat handles differently in subtle (or not so subtle) ways between Pathfinder, Pathfinder 2, Starfinder, D&D 4e, D&D 5e, and 13th Age -- just to name a few of the D&D type games and ignoring the vast landscape of non-D&D style games :)

I do think it could be done in a system agnostic manner, but it would be a massive undertaking...

I think it's be easier to code for one system and sell it as such. Aaron, you should see if an API script can be an Addon.  I'd bet a large sum of money that if automation was available for 5e, a large number of people would pay for it. Talk to Roll20, convince them to take a smaller percentage than they normally would.  Because people would be upgrading to Pro for it, so they'd make more money as well.  It's win-win for you and Roll20. The main reason most people go to Fantasy Grounds is automation.  I bet some of them would come back as well.

They cannot, sadly. 

That's unfortunate.  Roll20 could get a lot of money for automation.  And not even have to support it, since it'd be developed by a 3rd party.

In another post about automation, a Roll20 rep actually claimed they would NOT support automation, as this was supposed to be a tabletop replacement, not an MMO replacement piece of software. Anyway, get better players that don't feel the need to cheat.

Simplest solution I'd suggest is to have your monsters all listed nicely down the side of your screen, linked and ready to roll (haha). Then you copy them and unlink them (using tokenMod if you have a lot of them!) then copy and place until you are done. Hide your roster behind dynamic lighting or fog of war and use those for making your rolls. Any players who want to ruin their own fun would get a bunch of 'no attribute exists' errors clogging their chat and a sense of failure in life. My main vote goes in favour of the social solution though... cheaters gonna cheat, especially if you use official material and they have the books or the internet!

Thanks for the feedback. I see the idea for wanting to macro the attacks, and the reasoning for having it there. In fact the idea of automation is something another tool does well. I was just looking to see if I was missing an option to turn this off. Similar to how I can hide auras, and the bubbles over top of tokens from players.

Ziechael's solution is probably the simplest to implement. There's a very similar Stupid Trick .

That's just a lot of extra work, and not really worth the prep. I appreciate the help, I'll just be aware this is possible. Thankfully, most of my players aren't very computer savvy. I stumbled on this trying to make some query macros for myself, and thought, I wonder. This also however, messes with the ability to use transparent tokens to hide GM notes on the Object Layer, as anyone could just use a targeting macro to find out if there's anything hidden there.

Even if they were to target an invisible token, the GM notes cannot be pulled by a macro. That requires an API script. Since you are a Pro user, I would suggest keeping your notes there, rather than a bar/bubble, and pulling them with the GMNotes script. Full instructions here .

Is there a way to notify the DM if a player queries a token's attributes? Perhaps a clever macro hidden within the attribute?

I think there is an API that allows a GM to spy on whispers, but if you are having to go to extremes like that you may as well just find new players in my opinion ;)

Jeremy said: That's just a lot of extra work, and not really worth the prep. Agreed, but you could just do it for special opponents or "boss" fights; the enemies that have some tricks up their sleeves or surprises. If they query low-level/mook tokens to find their hit points, are they really finding out anything they don't already know?

My question is... Why would you give out the information to everyone on how to go about getting the data from a token, Instead of just saying if you highlight a token and input some code, it spits out that picture. You've pretty much taken the predicament you're in, and fk'd hundreds of other games...

Johnathan M. said: My question is... Why would you give out the information to everyone on how to go about getting the data from a token, Instead of just saying if you highlight a token and input some code, it spits out that picture. You've pretty much taken the predicament you're in, and fk'd hundreds of other games... Security from obscurity is no security at all. It's very possible that hundreds of people in those games knew about this trick already, and had macros to whisper the information to themselves, and just didnt tell the GM. In practice, most players aren't that bothered about things like this to go to this extent. And even if they are, for most games, monster stats at least are easily available, just by grabbing a copy of the rulebook or monster manual. This is an ancient gaming (non-)dilemma. Many GMs have foolishly anguished over the fact that players can just look at the GM or monster stats sections of their rulebooks, when the games run perfectly fine even when players know all the stats. The GMs think that players not knowing the monster stats makes the game more immersive, when the opposite is often true.  In roll20 there is a solution to this, if it really bothers you. For any information you dont want players to have access to, add it either to the GM Notes tab, or to new attributes you name yourself on the Attributes Tab. To be able to query an attribute, players need to know its name, and if its not on the character sheet tab, they cant discover the name. You can also have all macros whisper information to GM, and just report what happens, so players cant access the roll information either. Personally though, I think all of this is unnecessary. It's a roleplaying game. As GM, you aren't really trying to defeat your players using unfair, hidden information, I hope. Whether the game is fun or not doesnt depend on whether the players know the stats of the things they are fighting.

G G said: This is an ancient gaming (non-)dilemma. Many GMs have foolishly anguished over the fact that players can just look at the GM or monster stats sections of their rulebooks, when the games run perfectly fine even when players know all the stats. The GMs think that players not knowing the monster stats makes the game more immersive, when the opposite is often true.  My group of 5 has 4 rotating DMs. We count on each other for help. Only special NPCs really need a veil of secrecy, and our game is built on trust. This can't always be the case with pickup games or games with strangers. If some degree of uncertainty is needed, assure you players that what appears on a sheet isn't always the actual value, that you use a separate accounting system. Then either use a separate accounting system or not. If they're going to snoop, they don't deserve to trust the information they are getting.

Johnathan M. said: My question is... Why would you give out the information to everyone on how to go about getting the data from a token, Instead of just saying if you highlight a token and input some code, it spits out that picture. You've pretty much taken the predicament you're in, and fk'd hundreds of other games... I assumed they had a way to hide this stuff from the players. The fact that they don't honestly surprised me. Falling back and saying that's part of the social contract feels like passing the onus onto your players instead of owning up to the fact that Roll20 doesn't really "hide" things from them. Asking me to change the attribute names is about the most comical thing I've heard in a long time; I'm using paid content that utilizes the OGL Character sheet. I'm extremely grateful for the communities help, but It's getting really old being told I need to use an API script to band-aid the system and then having to constantly troubleshoot those breaking APIs.

I've created a suggestion for this on Suggestion & Ideas forum . I'm hoping to just to make this black and white as opposed to being this gray area between the social contract with your players and just knowing they can't see the content.

Jeremy said: I've created a suggestion for this on Suggestion & Ideas forum . I'm hoping to just to make this black and white as opposed to being this gray area between the social contract with your players and just knowing they can't see the content. Good idea Jeremy... this thread was starting to head off-topic as far as Roll20 is concerned anyway :) Since all options have been exhausted here I'll close this thread and let your suggestion be the basis for further ideas on this subject.