maptool
maptool copied to clipboard
RPTools
[Feature]: Show Hidden Token Properties in the UI.
Describe the Problem
Token properties that are not declared through a Property Type can exist on the token but can't easily be seen through the UI. You have to build/use special tools to see and manage these "hidden" properties which many users don't have or use. And there is also the phenomena of tokens ending up with unintentional hidden properties that were misspelled, accidentally created, or legacy.
The Solution you'd like
I'd like the GM to be able to see and manipulate "Hidden" token properties through the existing UI Token Properties tab. It could simply be under a collapsible Token Type called "Hidden".
Alternatives that you've considered.
No response
Additional Context
No response
This would basically be a more complicated version of disallowing this hidden properties at all. You can already declare properties that only the GM can see. Is there any use case for hidden properties?
I think this would be a way to expose ALL token properties. Whereas today, if you don't run a function to find them, and then add those to your Campaign properties, you'd never know they existed (or how much space / big, they may be).
This would basically be a more complicated version of disallowing this hidden properties at all. You can already declare properties that only the GM can see. Is there any use case for hidden properties?
local variables in tokens are made into a hidden property aren't they? without that function, you'd have to define how long of a lifetime a variable actually has, which might break something.
I might be in favour of showing these hidden properties in the Edit Token dialog so that they aren't completely hidden from GMs even when looking at specific token.
But I'm not a fan of shoving this into Campaign Properties. The concept doesn't match the rest of the dialog, it wouldn't allow manipulating the properties like the others, it would be noisy for larger / library-heavy campaigns, and would still require other tooling to address any issues discovered. If this is added, it should be a dedicated tool that could directly address any needs (fixing names, deleting properties, whatever else). But honestly I think this is a great case for add-ons rather than core functionality.
I think this would be a way to expose ALL token properties. Whereas today, if you don't run a function to find them, and then add those to your Campaign properties, you'd never know they existed (or how much space / big, they may be).
why would you want them in your campaign properties? I don't get that, they don't need to be there. This is why I am hesitant any time someone asks for a macro function to add to campaign properties because people will start adding every framework token variable they have to campaign properties which is not only not required but going to be super confusing to everyone trying to use it with 0 benefit.
Plus any framework writer would gain more benefit from not having GMs fiddle with internal saved variables than allowing it.
The Solution you'd like
I'd like the GM to be able to see and manipulate "Hidden" token properties through the existing UI Token Properties tab. It could simply be under a collapsible Token Type called "Hidden".
The problem is, that you allow users to edit stuff, and they will, which means you place a greater burden on framework developers to ensure that every time they read/update a "hidden" token variable, they sanity-check it to make sure it still ok (sure they probably should be doing this anyway as they could still be updated other ways, but it's not being done and limited opportunities for users to fiddle is saving them). It also now gains all the downsides of the "non-hidden" variables when it comes to conflicts of updating the value while the edit box is open. I get why you would want to start clearing out old stuff, but when you are using a framework how do you know you are not removing something required by the framework?
IMO, the biggest issue is a variable in a macro with the same name as a “hidden” property. Those are a nightmare to debug.
I’d be happy with a deprecation warning when writing to such a property (maybe once per macro execution) that tells people it’ll become a fatal error in a future release. They can still read it without the warning so existing macros don’t generate too much spam, but writing should become setProperty() calls which makes it explicit and helps readability down the road. And of course, we can encourage using getProperty() at the same time…
From a debugging perspective, allowing read-only access to such properties (for both player and GM) via the token editor seems reasonable.
I think this would be a way to expose ALL token properties. Whereas today, if you don't run a function to find them, and then add those to your Campaign properties, you'd never know they existed (or how much space / big, they may be).
Exactly.
And here is another quirk of the way things are now...
One of the things I always do when I import a 3rd party lib token is take a look at their "hidden" properties (and they are all basically hidden because the token type doesn't transfer with the token). Then I create a token type with those properties so that I can see the properties that the lib is using. It's annoying to have to do this, but if I ever want to modify the token (which I often do in order to better integrate it into my framework), I've got to know what's going on with it. Life would be so much easier if I could pop the token open, see the "hidden" properties (i.e. all properties on the token NOT declared in the type) without jumping through hoops to "show" them.
I understand "hidden properties" when it comes to keeping players from messing with stuff, but I just don't understand hiding properties from myself... ever.
IMO, the biggest issue is a variable in a macro with the same name as a “hidden” property. Those are a nightmare to debug.
Yeah... that's a big potential issue, too. There really are a lot of cases where hidden props are problematic... and it's not like I can't run Raoden's Quick'n'Dirty Token Manager ... Rev even has a "multi token editor" that might do some of the same things... so I'm just not sure why the functionality isn't more integrated.
Some of what you guys are talking about is probably just going over my head (or touching on things I didn't mean to infer would need to be touched)... and maybe I don't understand how showing a collapsible "hidden" property type (properties not in the Token Type) on the token in the Edit Token>Properties windows fundamentally changes anything... but glad to see you guys talking about it.
I understand "hidden properties" when it comes to keeping players from messing with stuff, but I just don't understand hiding properties from myself... ever.
It's not hiding them from yourself as a GM, it's giving framework developers the ability to hide their internals so the framework knows its the only thing managing those properties (on lib and non lib tokens). If we expose these to the token editor dialog we now break what framework developers have been relying on (even if they don't realise it, most of them are relying on this as they are not coded defensively). And we are not even getting into conflicts that will arise if these hidden fields are updated while the edit dialog is open, hidden properties have avoided all the other issues that people constantly run into with other properties simply due to the fact that they don't appear in this dialog.
If extra values are causing problems then maybe we need another way to deal with it, but adding them to the token editor will do more harm than good
IMO, the biggest issue is a variable in a macro with the same name as a “hidden” property. Those are a nightmare to debug.
I’d be happy with a deprecation warning when writing to such a property (maybe once per macro execution) that tells people it’ll become a fatal error in a future release. They can still read it without the warning so existing macros don’t generate too much spam, but writing should become setProperty() calls which makes it explicit and helps readability down the road. And of course, we can encourage using getProperty() at the same time…
Given how long it its been like this (before macros were big even) and the amount of partially maintained frameworks that wouldn't get updates (or even maintained ones with code paths that are rarely executed), I don't see this happening it would just end up with too many broken macros and frameworks.
I'm in favour of a checkbox on a GM's view of the edit token dialogue panel allowing all properties to be visible. It would be a handy dev tool.
And it would let people see my copyright notices on things.
I think that still would have the potential to cause desync errors, though.
Would it be possible to have the hidden properties in a separate, read-only section? This hypothetical section would not be updated on closing the edit token dialogue, as it would never need to being read-only. I think that at least would go a ways towards helping with debugging while avoiding the potential consequences.
I don't know that hidden or not matters, the issue is whomever closes the edit token dialog last wins. Same goes for macros tho, whatever macro writes the property last wins and this happens "today". Just like if a GM and a player had a dialog open that writes to the same property, whoever writes it last wins and losers data is lost, hidden property or not.
If a player is allowed to open the edit token dialog box that is a GM / Server choice. If you want to "protect" that data, don't let players edit the token properties through that dialog. MT offers a way to protect that data.
MT should offer a way to delete a token property once it's saved. You can't even null a property to remove it. There is no way to clean a token without manually recreating it and dragging macros back and forth.
It's frustrating that if I want to test some new add-on or lib:token, that I risk pollution of every asset in my campaign and what's worse, I don't even know it happened.
edited to add, I'd be ok with a couple new functions, like a deleteProperty and deleteLibProperty and not worry about any changes to the dialogs.
MT should offer a way to delete a token property once it's saved. You can't even null a property to remove it. There is no way to clean a token without manually recreating it and dragging macros back and forth.
There's no resetLibProperty(), but resetProperty() can just as well be used for those (though it's a bit unwieldy).
As an example, it's "easy" to clear all properties on a lib:
[r, foreach(vProperty, getLibPropertyNames("Lib:Elf")): resetProperty(vProperty, "Lib:Elf", getTokenMap("Lib:Elf"))]
It just occurred to me. This is a valid use for the pointless collapsable tree.
All we need is to check for GM and list extraneous properties under another toggle.
It just occurred to me. This is a valid use for the pointless collapsable tree.
Yeah, that's exactly where I expected it to be visible... under a standard "Hidden" collapsible tree.
I didn't want to derail my own feature request, but I was also thinking forward to whether or not (once we had a universal "Hidden" tree along with the actual Property Type) we could have multiple "token types" attached to a single token. I would use that for property organization on the token instead of the goofy spacing hacks that are often used now. We could, for example, put Stats, Weapons, Armor, Equipment, etc., under different token types and assign them to tokens as needed. Then the Edit Token dialog would have each section in its own collapsible tree, and the stat sheets could have standard delimiters, too.
But, of course, that opens some other issues that would require consideration and discussion (like there would probably have to be a primary Type to keep frameworks from breaking. But maybe allow Property Types to support Groups of Property Types moving forward?)