Monster Rolls are all whispers to GM

Everything worked fine (more or less) on my first campaign, now for my second I am having a problem I can't find the solution to.  I have the game settings set for dice rolls to "Never Whisper" to GM.  However, whenever I (GM) make a roll from a creature's character sheet, it always whispers it to me.  My players can't see saves or attack or damage or anything if I use the creatures sheet to just click for a roll.  If I use the dice roller it shows up fine.  I'm sure it's a setting I have set wrong, but other than the games settings I can't find where to fix it. If I click the PC's character sheet to make a roll for them, it doesn't whisper.  It's only the NPC's and mobs that are part of the module. I don't think it makes a difference, but just in case it's a known issue we are playing Chains of Asmodeus.

You may have the campaign set to never whisper rolls to GM, but the individual tokens may be set to whisper.  I would check that first. (had a similar issue in the past until I figured that out).  Annoying to change them all, but if that is what the module was originally set up as from the module maker, the general settings won't change that. (The general settings only effect new tokens that you make, not pre-existing ones, I believe.)

Hi Tim C.,  Could you supply a screenshot of an NPC's character sheet that is having an issue? Also, to elaborate on Feyte's comment, if you set the campaign to Never Whisper but you did not apply those settings in game then it did not change any existing character.  In that case please click on the My Settings tab, then Miscellaneous, then Apply Default Settings. Checkmark the desired setting you wish to change, hit Apply, then WAIT for the nearly invisible bar to complete.  Note: sometimes the Apply Default Settings system is buggy and does not correctly apply the setting, especially with whisper. 

First off, Gauss, thank you.  That fixed it.  It didn't the first time, because of how mind bogglingly unintuitive that is.  The "Whisper Rolls to GM" checkbox doesn't mean "Do you want to whisper rolls to GM?"  It means "Do you want to use the the "Whisper Rolls to GM" setting that you already said you wanted to use". Now.....  Make this make sense.  I choose the settings I wanted to use.  But that didn't do anything.  I now have to go in game and choose which of the settings I already choose that I actually want to use.  This is not at all how "default" works.  This is like going to a restaurant and placing your order.  Then having to go to the kitchen to tell the chef which of the items you just ordered you would like prepared.

Technically, that setting is for "How do I want new characters to act?" It will ensure that future creatures have that setting.  Those game settings options don't change anything that already exists. The in-game "Apply default settings" feature retroactively applies those choices to in-game content.

I can see that's how it is supposed to work, but it makes no sense, and it's not good UX.  If someone says "never whisper" I feel it can safely be assumed they don't mean "only new characters/creatures never whisper".  I have never met a GM that hides his attack rolls as a general rule so why is this even something a module can change?  An auto-apply default would be appropriate here.  Allowing those setting to be selected before game creation so it applies game wide would be appropriate.  If I'm wrong in my assumption that the majority of people using pre-made adventures want the entire game setup to behave a certain way then at the very least displaying a warning that "Game Settings" doesn't apply globally and that you will have to apply those settings again in game with instructions on how to do so would be appropriate.  I can't be the first one to go through this. But since we are on the subject of "this applies to new characters", I had another problem I already fixed but you made it relevant here.  I had to manually adjust 2 new PC's so they auto rolled damage + crit because my chosen settings didn't get applied to them when they created their characters.  The "Apply Default" may have worked to fix it had I known to do it before I manually changed them, but wouldn't this indicate that the Default Sheet Settings don't automatically apply to new characters either?

I agree that I wish the 'Apply Default Settings' and other game default settings were a little easier to understand and use. But since you have a Pro subscription, you can also use a TokenMod macro to adjust tokens to whatever your preferred defaults are. Here's an example of mine (this is for NPC 'mook' characters, also using TokenNameNumber, MonsterHitDice, ChatSetAttr, and some other scripts): !?{Token Name?|@{selected|character_name}} {Add Number?|Yes, %%NUMBERED%%|No,""} ?{Darkvision?|Yes,has_night_vision|No,} ?{Darkvision Distance?|60} ?{Passive Perception?|@{selected|passive_wisdom}} ?{Size?|Medium/Small,1|Large,2|Tiny,0.5|Huge,3|Gargantuan,4} !setattr {{   --silent   --sel   --replace   --hp|''   --passive_wisdom|?{Passive Perception?}   --advantagetoggle|'{{query=1}} {{normal=1}} {{r2=\lbrak\lbrak0d20'   --rtype|'\at{advantagetoggle}'   --wtype|\ques{Whisper\ques\|Public Roll,\|Whisper Roll,/w gm }|    --npc_name|\at{selected\|token_name} }} !delattr {{   --silent   --sel    --npc_name_flag    --dtype }} !token-mod {{ --on showname showplayers_name showplayers_aura1 ?{Darkvision?} --off playersedit_name playersedit_bar1 playersedit_bar2 playersedit_bar3 playersedit_aura1 playersedit_aura2 showplayers_bar1 showplayers_bar2 showplayers_bar3 showplayers_aura2 --set name|"?{Token Name?} %%NUMBERED%%" controlledby|= bar1_link|  bar2_link|npc_ac bar2_max|  bar3_link|passive_wisdom bar3_max|  bar3_current|?{Passive Perception?} aura2_color|#0000ff aura2_radius|  night_vision_distance|?{Darkvision Distance?} scale|?{Size?}u bar_location|overlap_bottom compact_bar|on defaulttoken }} /w gm Mook Token Full Setup for @{selected|character_name} !token-mod --set name|"?{Token Name?}" bar1|@{selected|hp|max}

Tim C. said: <snip>I have never met a GM that hides his attack rolls as a general rule so why is this even something a module can change? <snip> Hi, I am an old school DM. For the last 30+ years I have always rolled behind the DM screen for in-person games and I continue to do so for online games. :) Now you have met someone. There are many of us out there.  Additionally, many folks do not want players to see the mechanics of the creature, something Roll20 does not hide when you roll an attack. (Unless we spend the time to make macros to double-wrap things in inline brackets.) Tim C.  said: But since we are on the subject of "this applies to new characters", I had another problem I already fixed but you made it relevant here.  I had to manually adjust 2 new PC's so they auto rolled damage + crit because my chosen settings didn't get applied to them when they created their characters.  The "Apply Default" may have worked to fix it had I known to do it before I manually changed them, but wouldn't this indicate that the Default Sheet Settings don't automatically apply to new characters either? Unfortunately the Apply Default settings are bugged sometimes. It can take multiple attempts, may still not work. Alternately, perhaps the new characters were imported from Roll20 Characters? They would already have their own settings already. Or the +Character button was pressed by a player? (+Character puts the character in Roll20 Characters) Roll20 Characters has made new characters more of an issue. 

Tim C. said:  I have never met a GM that hides his attack rolls as a general rule so why is this even something a module can change?   I also hide attack rolls. Many GMs do (viz. Mat Mercer). I hide them because they frequently contain information that should be unavailable to the players (the "goblin" is a disguised shape shifted dragon, the trusted NPC is a doppleganger), and also, I dislike players being sidetracked by auditing the rolls. If I make a math mistake (in either direction), or there are extenuating circumstances that might alter a roll, I would prefer not to have to explain myself or retcon things. It makes the game go faster, and (for me) deepens immersion. As for the way things work, part of that is determined by how Roll20 is set up as a browser app. When you are on the settings page, the game is not loaded. The page says, "Customize new pages and tokens to use the settings that best fit your game." (Emphasis mine). Roll20 cannot interact with the game data at that point because it has no access to the game. The game has to be loaded. It can be misleading for new players, but once learned, it is easily remembered. It might be good to have a disclaimer on the save button to help newer users. That's worth a suggestion, since the mechanics of making the change to the app would be difficult to implement.

I'll concede some GM's may want rolls hidden.  I'm not willing to say "most" but it doesn't really matter to me. The Settings page doesn't need access to a loaded game, because the loaded game has access to the settings data.  That is all you need.  You can either do it by checking file info, creation date, change date, etc to determine if auto apply is necessary, or a better, safer way would be to simply add a checkbox to the settings page, or a dialog pop-up when user clicks "Save Changes" that says "Update game content with these settings?".  The mechanics are already implemented (Apply Default Settings button exists so the code to do it exists), you just need to read the first line of a config file on game load and add an if/then to decide whether to call it automatically or not.  Compared to the changes they have made in the last year, this is a doddle.

The current system allows you to pick and choose which settings get updated. This adds a level of "Are you sure?" to potentially game-breaking changes. I concede that not everyone may like this method, but it does have its uses. There have been few complaints that the system is two-tiered, but Jumpgate development is an excellent time to make such suggestions. Either the suggestion forum or the Jumpgate feedback thread might be a good place for dev visibility.