Slash command: secret ("blind") roll?

I'm trying to create a slash command that makes a secret skill roll (to begin with). The roll should only be seen by the GM. I'm using "rRoll.bSecret = true;", but it has no effect.

I'm aware of the dice tower, but I want to create a slash command because then the players can store the command in a hotkey, potentially speeding up game play quite a bit.

Any tips?

Try "-hide" on the chat die roll. i.e.
/die 1d20 -hide
I don't know if it works. It's not documented for working on die rolls, but it does for table rolls. See https://fantasygroundsunity.atlassia...#Chat-Commands

Not knowing exactly how you're implementing this roll action, it may be hard for us to provide accurate assistance.

In theory, setting rRoll.bSecret = true in the standard FG action cycle should hide the roll from the players. But there may be additional code needed, depending on exactly how you're coding the action (dice roll).

Quote:

---

Originally Posted by Trenloe

Not knowing exactly how you're implementing this roll action, it may be hard for us to provide accurate assistance.

In theory, setting rRoll.bSecret = true in the standard FG action cycle should hide the roll from the players. But there may be additional code needed, depending on exactly how you're coding the action (dice roll).

---

I'm coding this for the Basic Roleplaying ruleset.

I could not upload the files nor post the code so I put the code on google drive: scripts\blind_skill_roll_command.lua and scripts\manager_action_blind_skill.lua

blind_skill_roll_command.lua registers the slash command and looks up the skill value and manager_action_blind_skill.lua does the actual die roll.

Thanks for including the files, that helps to examine the issue. As you're using a custom action, with a custom onRoll script, you'll need to code for the secret flag in that onRoll function - because it's this function that displays the data in chat.

Also, as the script is running on the client, we're limited in what Comm.deliverChatMessage can do in terms of delivering to just the GM. As detailed in the Wiki here: https://fantasygroundsunity.atlassia...verChatMessage "If client, then the message will always be distributed to all connected clients (regardless of recipients parameter)."

So, the final delivery of the message has to be ran on the GM side, and this requires OOB Messaging, where the player client offloads processing to the GM instance. See the attached for an example of using OOB messaging to transfer processing to the GM instance. In this example, the presentation of the message is transferred to the GM side - you may want to transfer the processing earlier, so that the base dice roll is also initiated from the GM side and the players can't see it.

Try this one - it moves the OOB messaging to earlier in the process. Use your original manager_action_blind_skill.lua and the blind_skill_roll_command.lua from the attached ZIP file.

Quote:

---

Originally Posted by Trenloe

Try this one - it moves the OOB messaging to earlier in the process. Use your original manager_action_blind_skill.lua and the blind_skill_roll_command.lua from the attached ZIP file.

---

Thanks for the code. After cleaning up my own code and doing some testing this extension now works. It doesn't have the same output as the dice tower but that can be a later development. It's enough (for now) that the result of the dice roll is only visible to the GM. I'm going to publish this extension as a free download on the forge. It will help avoiding a lot of micro-pauses in the gameplay in my games and hopefully it will improve the FG experience for others as well.

Well CoreRPG has a built in function that might handle this whole thing if you wanted to use the dice tower.

DiceTowerManager.sendRoll(rRoll, rSource);

The rRoll structure would need to be calling ActionSkill.getRoll(rActor, rAction) to collect the rRoll and the rSource would be the same rActor fed to the ActionSkill.getRoll. So sounds like it's about 2 or 3 lines of code. This is some napkin coding from reading the exchange, so more work might be needed.