Player controllable tokens but hidden by dynamic lighting?

Im trying to hide keys and other items around the map which I want to players to find by exploring. The players should be able to reveal the item through dynamic lighting line of sight and then drag and drop the item. The only problem is that when i set the token to 'controllable by all players' it becomes revealed and all players can see it, just sitting in the dark. I know about GM layer and moving it to object layer but this interaction is meant to run independant of the GM without me there managing the interaction. Any advice is appreciated, thank you.

I don't have a great suggestion, but one way to do something similar is to give players control of invisible (100% transparent) tokens that each have a short tooltip like "copper key." It's not great, because someone might get lucky and mouse over a piece of darkness to activate the tooltip, or be within line of "sight" and still miss it because they haven't put their cursor in the right place. But it's a simple way to set up a hands-off scavenger hunt. (Also, once a player finds an invisible token that they control, they can make it visible by editing it to display an aura.)

Ah, I was worried that be the case. Thanks for taking the time to answer anyway. Would something like a 'reveal' macro be possible? Where players click a button when they enter a room or are close enough to the object to automatically reveal whatever is nearby?

There's the ItsATrap api script. Never used it, but pretty sure that's exactly what it does. Might be 5e only(?), as I think you can have it auto-reveal if passive perception beats a DC

Ah thanks mate, sounds promising, I'll take a look.

If the players can see the item tokens even when they are in darkness, that means that you have them set with Vision on.&nbsp; Make sure vision is turned off and they won't see the items.&nbsp; However, they will still be able to click on them and select them (or if they click and drag over darkness they'll see them selected (blue selection outline). Tooltips also appear when moused over. Unfortunately there's no way with the regular token settings to have a token that is not discoverable at all until the players 'see' it with another token. However it is possible with another script workaround. (Roll20 Pro subscription required.) The approach would be to give your players a TokenMod macro that allows them to change the 'Controlled By' settings for a targeted token.&nbsp; When they see the item, they could click on the macro that has a @{target|token_id} reference.&nbsp; (I'll use a 'key' for this example.) 1. Create a Character named 'Item' that the players have Edit &amp; Control access over. 2. Create a Key token but do not link &nbsp;it to a character sheet (make sure the Represents is set to 'None'). 3. Place the Key on the Object layer and make sure it doesn't have vision turned on. 4. Then when your players find the Key, they can use this macro to target the Key and change it to 'Represent' the Item character, which they have control over:&nbsp; !token-mod@{target|represents} --ids @{target|token_id} --set represents|@{Item|character_id} You also have to make sure you have TokenMod configured with PlayersCanId On: use this command !token-mod --config players-can-ids The beautiful part about this setup is that it will only work on Keys (or other tokens) that do not currently have anything set in the 'Represent Character' field.&nbsp; So they can't just change a random NPC enemy or their own characters to become the 'Item' character.&nbsp; Once the Key is linked to the 'Item' character, they can move it around as needed.&nbsp; (If you have other tokens on the Object layer that are unlinked, this could be an issue if your players like to 'experiment' all over to see what else are hidden items that you don't &nbsp;intend to become items.) If you set the nameplate as visible to players who have 'Edit' access, then once they control the token, the nameplate will appear, so you could also name each one uniquely, such as Red Key, Yellow Key, etc. I'm not sure what you want them to be able to do with the Keys once they can move them around, but that should get you partway there! If you have other needs or specific uses that you're looking for, maybe there's more options available to flesh this out a bit more. Update: I made a quick video showing what it looks like (GM screen on left, Player screen on right):&nbsp;<a href="https://imgur.com/a/jCWylIJ" rel="nofollow">https://imgur.com/a/jCWylIJ</a>

One more thought: if you want each Key (or item) to be linked to a different Character Sheet, that should be possible as well.&nbsp; You could use one of the Bar Max Values as what is referenced for the Character Sheet.&nbsp; Bar 1 Max Value: @{Item|character_id} Macro !token-mod@{target|Item|represents} --ids @{target|Item|token_id} --set represents|@{target|Item|bar1|max} And another quick update with a report function: !token-mod@{target|Item?|represents} --ids @{target|Item?|token_id} --set represents|@{target|Item?|bar1|max} --report all|"@{selected|token_name} found the @{target|Item?|token_name}"

Holy Crap dude! That's awesome help! Thanks so much for taking time to write all that and expecially the extra effort for the video!!!!! People like you are amazing! Took me a while to wrap my head round it but it's working now!

The one caveat with any @{target| macro is that the mouse curser will turn into crosshairs when hovered over a token on the Object layer, so your players can technically see where ‘hidden’ objects or other tokens are at any time. That’s just a Roll20 setting/limitation, but something to be aware of.&nbsp; If your players are Roll20 savvy, they can create their own @{target| macro, so this doesn’t technically give them any functions that wouldn’t be available to them otherwise.&nbsp;

Thanks again mate! Stellar help!&nbsp; Two questions though: Would every player need the Roll20 Pro subscription required for API access? And I get an error that says 'No attribute was found for targeted token by the name of represents' I'm able to now control the key though but so is every other character, not just the one who found it.

T said: Would every player need the Roll20 Pro subscription required for API access? Nope. The only person who needs a Pro subscription is the game creator (which is typically the GM). And I get an error that says 'No attribute was found for targeted token by the name of represents' Ah I forgot that I am using the Stylus extension to hide those error messages. You need to add &amp;{noerror} to the macro: !token-mod@{target|Item?|represents} --ids @{target|Item?|token_id} --set represents|@{target|Item?|bar1|max} --report all|"@{selected|token_name} found the @{target|Item?|token_name}" &amp;{noerror} But that doesn't fully fix the error message problem... let me look at this a little more. Edit: solution in next post. I'm able to now control the key though but so is every other character, not just the one who found it. The control of the Key will be dependent on the 'Edit and Control' settings for the character sheet that it gets linked to.&nbsp; Let's say that the character sheet is named 'Item' like in my example, you need to open the 'Item' character sheet and look at the 'Can be Edited and Controlled by' field, and set that to what you want.&nbsp; If you only want it to be controlled by the player who 'finds' it, then we'll need to add another part to the TokenMod macro to set&nbsp; the 'controlledby'. Also, how are you testing out the player view?&nbsp; I strongly suggest not using Ctrl-L or 'Rejoin as Player', and instead using a ' Dummy Account '. In the example video I have two separate accounts logged in - 'Tester' is my own player account that I use to test things out from a Player's viewpoint.

Jarren said: Ah I forgot that I am using the Stylus extension to hide those error messages. You need to add &amp;{noerror} to the macro: !token-mod@{target|Item?|represents} --ids @{target|Item?|token_id} --set represents|@{target|Item?|bar1|max} --report all|"@{selected|token_name} found the @{target|Item?|token_name}" &amp;{noerror} But that doesn't fully fix the error message problem... let me look at this a little more. So this is a common error with a relative simple fix. For some reason the &amp;{noerror} doesn't work sometimes on its own in a macro, but it works if the macro is calling another macro. You actually need to create two &nbsp;macros: Item? %{selected|ItemMacro} &amp;{noerror} ItemMacro !token-mod@{target|Item?|represents} --ids @{target|Item?|token_id} --set represents|@{target|Item?|bar1|max} --report all|"@{selected|token_name} found the @{target|Item?|token_name}" &amp;{noerror}

How about leaving the key unassigned until the players discover it on the map. When they do, then you can give control to them.&nbsp;

Bro, you need to be getting paid for this or some sorta reward cause this is god's work you're doing. Just logged back on and will work through the advice you gave! Edit: Ok! The error message is gone! Awesome dude, thanks again. May I also ask if I would need to make a new item 'character sheet' for evey individual item? or would they all work off of the one main 'item character sheet' depending on if I wanted custom macros or descriptions for them? And is there anyway to reveal the character sheet in Handouts tab once they pick on the item? Also thanks for replying Aaron! I followed Jarren's advice and 'pre-set' the 'controlled-by' on the character sheet so I can pre-allow who is able to control the item once they 'find' it. i.e. Player A finds it using the macro which annouces it to everyone but only Player B can pick it up. I think that's how it works.&nbsp;&nbsp;

T said: May I also ask if I would need to make a new item 'character sheet' for evey individual item? or would they all work off of the one main 'item character sheet' depending on if I wanted custom macros or descriptions for them? Also thanks for replying Aaron! I followed Jarren's advice and 'pre-set' the 'controlled-by' on the character sheet so I can pre-allow who is able to control the item once they 'find' it. i.e. Player A finds it using the macro which annouces it to everyone but only Player B can pick it up. I think that's how it works.&nbsp;&nbsp; If you are planning on pre-setting which players can pick up which items, and they're not all going to be controlled by all players, you may not even need to use a character sheet at all.&nbsp; It might be better/easier to use the controlledby setting instead of represents. Here's a different way where you could set each token item individually: 1. Set the Bar1Max value to="PLAYERNAME" 2. Update ItemMacro to: !token-mod@{target|Item?|bar3|max} --ids @{target|Item?|token_id} --set controlledby|@{target|Item?|bar1|max} bar3_max|"Taken" --report all|"@{selected|token_name} found the @{target|Item?|token_name}" &amp;{noerror} Unfortunately it looks like @{selected|controlledby} can only be referenced when a token is linked to a character sheet.&nbsp; So instead I'm using Bar3Max as the reference to add the word 'Taken', which will prevent the macro from being used on a Key that is already found. Now, that is if you want to pre-set which player can control each Key.&nbsp; If instead you want the player who finds &nbsp;the key to be the one who can move it, then you'll need to change the 'controlled by' to a 'controlled by' reference of the selected token... which I'm not sure is a valid argument to pull from the selected token to use here in TokenMod. Though it is a valid argument for the --report function... so it might be possible. I'm guessing TheAaron may have a solution within TokenMod, or timmaugh may have a solution using his meta scripts.