[API] Add who to change: events

What do I want changed?   Add the 'who' parameter to any change: command. (player id, player name) What is it currently? Any time a change: command is sent, you get two parameters, "current" and "previous." These two objects are the parameters of what the token state was previous to the modification, and what the parameter was after the modification. Why?   Currently, if someone makes a change to an object, we cannot determine if its a GM or a Player. So, if we have a script that prevents a player from moving an object, a GM must unlock the object to allow themselves to move the object. So, if I wanted a script that locks down movement from players while its my turn, or if I only wanted to permit players to move X amount of feet, but, as a GM, I should have freedom of autonomy from the script, I cannot make that determination from the API, as I can't tell if its a GM making the change, or the player making the change. This also means that you cannot create an API between allowing players to "see as" a specific token, but not be able to move it. For example, I would like to have it set that players can "see" as a Token (for example, a Spectator, or another player), but not be able to modify the state of the object. Currently, if you are a player, if you aren't listed in the "controlledby" list, you cannot see as (your vision is not updated to include the object) or modify the state of the object. If you are listed in the controlledby, you can freely change the state of the token, without recourse. Why not have a second "hassightas" parameter in Tokens? Because this is not the scope of this suggestion, and persists to only the API scripts. Its also odd that all of the change: commands do not have an audit trail available to API Scripters that allow the API to see who committed the action, allowing them to react differently to commands. Such a change would probably be more significant to add, and come with some much different implications. What about the checkboxes for "see/edit" on the 2nd Page of the Token? This is also incorrect, as it globally allows players to See the state of the Token's properties, or Edit it if they are controlled. It doesn't allow for permissions per player, it is just a global setting. It also doesn't allow for the detection on who made the change, giving an audit trail to the API. For example, a script *could* be created that whispers the GM whenever a Token or Character Sheet was modified, and what exactly was modified, but it couldn't tell you who made the change. What incompatibilities would be introduced as part of this suggested change? None. As it is a third, new parameter, any script that is expecting two parameters wouldn't need to be modified. How difficult do you think it would be to create this change? As I do not have access to the program, I am unsure, but I can't imagine that capturing the playerid and playername from the person that made the change should be too difficult.

Absolutely would love this. 1000% this. Has this really not been suggested before? I am currently working around not having this by doing a combination of who is on page, who has control, who should be on page, and who should be touching tokens to infer but this won't work for situations where all these identifiers can't be used.

I just found it weird that the event does not fire with a who parameter attached in the first place, and I found it frustrating that the only way to differentiate between a GM Token and a Player is by scanning the controlledby property, and determining if any of the PlayerIds were playerIsGM() == false || id == 'any'. I was hoping to make something along the lines of allowing players to move tokens on their turn, and even allow them to modify certain sections of their token, including updating their current HP, but I didn't want them to be able to change their stats, skill points, etc. I also wanted to have the option to be able to move a token without restriction as a GM, but limit a player's movement. As it stands, I can't determine if its me making the modification, or if its the player, which is annoying.

Thanks for the suggestion! After 30 days, Suggestions and Ideas with fewer than 10 votes are closed and the votes are refunded to promote freshness. Your suggestion didn't build the right momentum this time, but feel free to submit it again! We find that the best suggestions describe the problem you are having, and the solution you want. You can learn more about the process of making suggestions on the Roll20 Wiki! More details can be found here .