keithcurtis said: Hi Ramsey! Assuming I read your description correctly, that sounds like standard setup. If a token represents a character sheet, that sheet must be controlled by a player. Note that after the token is assigned to represent a character, the token must then be saved as the default token for that sheet. Otherwise it will not still be properly set then next time it is pulled out. If a token does not represent a character sheet, it must have its "controlled by" field assigned to any non-gm player that wishes to move it. If you see "Controlled by" on a token, then it does not represent a character. Setting representation removes the ability to set a "controlled by" since that option becomes disabled. Thank you for offering the information. However it seems non-applicable and also irrelevant to the cause and the solution, at least in our case. To be a smidge blunt here: on Saturday the 2nd we did not experience this issue nor have we ever prior. Today we did, and there are absolutely zero things we have done differently. No tokens, sheets, or settings within the game interface nor outside of it were modified between Saturday and today when we experienced this bug. The sheets used were the exact same as Saturday. All tokens placed Saturday still functioned as expected, all tokens placed today did not. DM and I each have over 7 years experience using roll20 (and other VTTs and programs) as both player and DM, with over 20,000 roll20 game hours clocked between us, over 25,000 if you add in the other two at our table. Over 14,000 of those are mine with large majority as DM. So while not developers, we're all fairly familiar with how roll20 should typically function from both player and DM interfaces. And OP clocks over 800 hours including DMing based on their profile, which is not nothing. Bit of a hard sell for it to be a simple PEBKAC issue on one of the VTT's most basic interface functions I feel like, but I could be wrong. It would probably be easier if I just made a simple table with a couple screenshots for reference to show which setting combinations did vs didn't allow players control over their tokens. Something came up that took longer than anticipated and also I need to pop off soon, but I could probably do that tomorrow if it'll be helpful. Real quick, though, here's a bit more on our findings: Our table first experienced this bug on a map with dynamic lighting and presumed the issue was the dynamic lighting, but we ruled that out; it occurred on other maps, both ones with and without dynamic lighting. Tokens still on these maps which were placed on or before Saturday still functioned as expected, but any tokens placed onto those maps today did not. Based on our troubleshooting, my best guess is that new character sheets which the player created formerly made the token settings default to "Represents - (sheet name)" and as such "Controlled By - Determined By Character Sheet" (or perhaps even "Represents - None/Generic Token" and "Controlled By - [player name who created the sheet]" which also causes tokens to function as expected), but for reasons unknown to me they no longer do - in our tests they defaulted to "Represents - None/Generic Token" and "Controlled By - [empty]" - and pre-existing player-created character sheets changed to match (as per our findings). Meanwhile, tokens previously placed by the same player from the same character sheet maintained the former "Represents - (sheet name)" and "Controlled By - Determined By Character Sheet" in its token settings, which is what we saw on all the tokens we checked, hence why those could still be moved by the player. However, when the DM created a sheet and assigned it to a player, the token's settings automatically defaulted to "Represents - [sheet name]" and "Controlled By - Determined By Character Sheet" and could be moved by the player. The sheets are all 2024 sheets; we did not think to try recreating the issue on 2014 sheets before the DM had to head off.