Maptool: Option to be able to turn off MapTool client (player) use of the Token Property Editor

[adventuremagic123]

Is your feature request related to a problem? Please describe.
Because the Token Property Editor is known to create concurrency problems with two or more people updating a token at the same time, when I start the MapTool server, I would like to have an option to disable it for my players -- most of whom have no understanding of this issue.

Describe the solution you'd like
When I start the MapTool server, I would like to have an option to disable the Token Property Editor for my players -- most of whom have no understanding of this issue.

Describe alternatives you've considered
Verbally ask and remind the players not to use the Token Property Editor during games, but that makes me depend on their co-operation and understanding.

[Azhrei]

Oh, I LIKE this! 🙂

It seems a menu option to enable/disable it on Player systems would be best, sort of like how the Continually Enforce to Current Location menu option works.

The only big question is what to do if a Player is currently in the token editor when the GM changes the setting...

[Phergus]

People have been asking for this since the beginning and it always got shot down.

The only big question is what to do if a Player is currently in the token editor when the GM changes the setting...

They finish their change and the next time they try to open the dialog it is denied.

if (isConnectedToServer && isPlayer && editDialogNotAllowed) {
  No dialog for you!
} else {
  Open dialog normally.
}

Of course if it is a Menu item instead of a Server option then that has to be managed as well but we do that already for several Menu items when logging in as a player.

[JamzTheMan]

If you can solve that then why not just make it so when a dialog is opened it is first checked for a lock and refuse with an error it it is already opened?

If only one dialog for a token can be opened, does that solve the issue?

[Azhrei]

If you can solve that then why not just make it so when a dialog is opened it is first checked for a lock and refuse with an error it it is already opened?

The discussion in the past has always been that the clients couldn't actually open the dialog without receiving an okay from the server, and everything else in MT is asynchronous in terms of actions taken by the client vs. the server.

This uses a toggle instead and the state of the toggle is sent to clients and cached so that they don't allow the token editor to open in the first place. Much simpler and doesn't require any synchronous activity...

If only one dialog for a token can be opened, does that solve the issue?

The OP said he was concerned about concurrency issues. Those have been largely compensated for by sending individual properties, except the token editor allows changes to multiple properties, none of which are changed until the user hits "OK", so until the token editor can dynamically see changes made by asynchronous threads to the current token, I don't think a single instance of the token editor really solves much. (It does help, that's for sure, by reducing the scale of the problem.)

—

We've had discussions before about assigning permissions to various parts of the UI. While this uses a sledgehammer to remove permission for Players being able to open the token editor, the macro language is to the point where the token editor isn't actually _required_ anymore. Even the new VBL options and HL data is accessible via macro (that hasn't always been the case).

There are still a few things that can't be done via macro (that I know of), such as scaling the token image or positioning it within its space using the Config tab. The Speech tab is also unique, IIRC. So maybe we need two more macros and disabling the token editor is 100% without ramification from a usability standpoint?

[Phergus]

Actually, I think you can do everything you need for Speeches with macros. They could probably use a little update love like many of the macros have received lately.

The token image config though is definitely lacking macros.

[adventuremagic123]

If you can solve that then why not just make it so when a dialog is opened it is first checked for a lock and refuse with an error it it is already opened?

If only one dialog for a token can be opened, does that solve the issue?

No, because someone might be using a macro to update the token.

[adventuremagic123]

If you can solve that then why not just make it so when a dialog is opened it is first checked for a lock and refuse with an error it it is already opened?

The discussion in the past has always been that the clients couldn't actually open the dialog without receiving an okay from the server, and everything else in MT is asynchronous in terms of actions taken by the client vs. the server.

This uses a toggle instead and the state of the toggle is sent to clients and cached so that they don't allow the token editor to open in the first place. Much simpler and doesn't require any synchronous activity...

If only one dialog for a token can be opened, does that solve the issue?

The OP said he was concerned about concurrency issues. Those have been largely compensated for by sending individual properties, except the token editor allows changes to multiple properties, none of which are changed until the user hits "OK", so until the token editor can dynamically see changes made by asynchronous threads to the current token, I don't think a single instance of the token editor really solves much. (It does help, that's for sure, by reducing the scale of the problem.)

—

We've had discussions before about assigning permissions to various parts of the UI. While this uses a sledgehammer to remove permission for Players being able to open the token editor, the macro language is to the point where the token editor isn't actually _required_ anymore. Even the new VBL options and HL data is accessible via macro (that hasn't always been the case).

There are still a few things that can't be done via macro (that I know of), such as scaling the token image or positioning it within its space using the Config tab. The Speech tab is also unique, IIRC. So maybe we need two more macros and disabling the token editor is 100% without ramification from a usability standpoint?

I still recommend having a token editor to facilitated macro development -- or maybe fixing a serious problem during game play OR doing something that is not yet supported by macros (developed for a game).

My desire is to allow the GM to deny the players the ability to use it during game play.

[adventuremagic123]

So, I still want to have the token editor available. Please don't take it away.

[Phergus]

No one is suggesting taking the editor away. The comments are merely that access to it can be denied as the majority of reasons to access it can instead be handled via macros.

[adventuremagic123]

Ok. Thank you. :grinning:

[adventuremagic123]

I should make a clarification. As the GM, I'd like to be able to disable the Token Property Editor and anything else that might cause a concurrency issue with updating a token. So, that means disabling access to any of the tabs in Edit Token that might be associated with this issue. That might mean disabling access to the Notes, Properties, VBL, State, Speech, Ownership, Config, and Hero Lab tabs -- maybe the entire Edit Token dialog.

In other words, l want to limit players to updating their tokens via macros I've provided while we play a game. I would also like to be able to turn access on-and-off for myself (as the GM), where I would also be limited to changing tokens via macros. Though, I (as the GM) must be able to give myself access to the Edit Token dialog and all the tabs during a game if I need it.

The Hero Lab functions provide all the Hero Lab access I need during a game, so it's fine to disable the entire Token Editor (again, with the GM having the option to re-enable it for himself if needed).

[Merudo]

Have we agreed where the option to enable the Token Property Editor should be in the UI?

Would a menu option "Lock Player Token Editor" in the Tool Menu right below "Lock Player Movement" be appropriate?

[Phergus]

That's a good choice IMO, that way that GM can always enable/disable it if needed during a game.

[Merudo]

PR #1556 adds the menu item.

[Merudo]

@wolph42 raised a good point on discord. Even with the token editor locked down, players can just impersonate their token and edit it by running macro commands.

Perhaps locking down the token editor should also disable players from running macros? Basically, the chat panel would no longer be able to launch macro commands, and the players would no longer be able to launch trusted macros. Trusted macros would still work fine.

[wolph42]

And here I am. My point is that I'm actually against this feature for 3 reasons:

1. Merudo mentioned this, there's nothing stopping a player from changing his properties
2. It adds yet another failpoint to MT, more bugs,
3. It adds to the (yet already significant) complexity of using MT; more confusion amongst user who don't understand why they can't edit there token and/or what does that setting mean

@Merudo: your suggestion to also prevent using macros to update stats will magnify points 2 and 3 considerably.

[Merudo]

@wolph42 regarding 3., I suggest adding a mouseover tooltip for the grayed out Edit ... option, something like

Token Editor currently disabled by the GM.

As for 2., I find that players accidentally / purposefully editing their tokens during session creates plenty of framework-related bugs.

[mrkwnzl]

I’d be interested in preventing the players from using to edit the token, even if they could change the properties via chat command. It has a simple reason: My players tend to accidentally open the Edit Token window and get confused. For some reasons they can’t remember that they need to open their character sheet via macro and just double-click the token. Also, some players change their token image all the time, which is confusing and I don’t want tell them all the time that they shouldn’t do that.

[selquest]

Maybe a better approach would be to lock only derived properties? If MT could detect the presence of references to other properties or we could otherwise mark them specifically as do-not-allow-edits, we could keep the token editor from showing some of its most confusing aspects and prevent the most damaging framework interference without running too far afoul of the dangers @wolph42 brings up.
I think I'd even suggest that derived properties at least be on a different tab for GMs too - we don't necessarily want to go as far as to prevent direct edits by GMs, but it might be worthwhile to steer them away from accidental edits to overwrite calculations.

[bubblobill]

Since there are plans to redo the token properties in the campaign properties UI, how about a flag to disable visibility in the Edit Token properties tab. I don't personally like taking macro power away from players as most of my players write their own. It would be nice however to hide properties that are derived or easily corruptable through manual editing though.

If you could create a property that contains a clickable link to a framework character editor and leave the rest hidden that would alleviate most framework GMs problems.

[Phergus]

how about a flag to disable visibility (of properties) in the Edit Token properties tab.

That has potential.

As mentioned above, there are reasons other than properties to deny access as their are plenty of ways for players to mess things up in the various tabs of the dialog.

• They can add terrain modifiers to themselves or set themselves to ignore terrain.
• They can change their sight to something they don't have.
• They can change their token's Property Type and now framework macros stop working on them.

[Azhrei]

So really what we want is to disable access to _some_ of the fields but not others. Can we do that on a tab-by-tab basis? Then the VBL tab could be disabled, or the Config tab could be disabled, but the Notes tab would still be available (which I use, as a player).

[Phergus]

The VBL tab is disabled for players already. I think an argument could be made for locking out the Config tab during play but I can see that being an issue for long-time groups where they generally don't have issues.

[JamzTheMan]

This is a tough one, arguments for all sides.

2 cents for last night, we had a token problem during game, hp properties were 0. I fixed it, rechecked, 0 again. WTH. I think the issue was the GM, me as a second GM client and a player were all trying to fix it I think. And people probably hitting OK instead of close when not making any changes was still making changes.

Seems minor but when you are on discord and there are 2 or 3 things going on, having that dang panel open can be as pain.

[Phergus]

Players do have an extremely annoying habit of leaving the the edit token dialog open for long periods while they are distracted looking stuff up in manuals or whatever.

[selquest]

As long as it's an option as implemented here, I don't know that there's a downside to the "Lock Player Token Editor" feature existing - I just probably won't use it myself. Sounds like we may have some ideas for additional feature work to add some finer-grained control or adjust the default behavior. I added a new feature proposal for my 'prevent edits to derived properties' bit: #1641

[bubblobill]

This should all probably be thrown into the bucket of considerations under the umbrealla of rewriting the Campaign properties UI.

[Phergus]

@Merudo just testing the change and having the menu item selected either before server start or afterwords didn't stop a player client from opening the dialog. Side-effect of some later change?

[Merudo]

@Phergus it works for me, except the "Lock Player Token Editor" option is reset on server start.

[Phergus]

Weird.

[Merudo]

The option prevents the menu from being opened by right clicking on the token and selecting Edit ... because the option becomes grayed out. It does not close the token editor if it is already opened.

[Phergus]

It was opened by double-clicking on the token.

[Merudo]

Oops! Forgot you could open the token editor that way.

[Phergus]

And I never use the other way. :)

[Asurasan1]

I'd just like to comment that this is a useful feature for me. I run a touch-screen setup for my game and there are times where due to the nature of the touchscreen, a token is 'double clicked' and that causes the edit window to pop up. This feature would be something I would use.

[Phergus]

Tested latest fix. Working as expected.