RPTools
State edits results in unusable state grid on token
Describe the bug Scenario: You have an existing campaign, with many maps and many states applied to tokens. For whatever reason, you need to edit an existing state in Campaign Properties, but when you do so, any existing token that had that state applied, will now be gone (good), but the grid slot it was taking cannot be used anymore by other states (bad).
To Reproduce Steps to reproduce the behavior:
- I would suggesting using your existing campaign because states are already created.
- Apply one of your states on a token (preferably one that is grid image with 3x3 grid size).
- After the state is applied, go into Campaign Properties and edit that state - rename it from like Slowed to Slow for example. Save it.
- You will notice:
A) The previously applied state vanishes (expected), however, B) Any new states applied to that token, avoids the slot the previously named state was taking, as if it was still there (bug). Even if I 'clear states' on the token, that slot in the 3x3 is no longer available for future states.
Expected behavior If a state property is renamed (edited), the state that existed on any tokens should be deleted AND the grid slot it was taken should be available for other states.
MapTool Info
- Version: 1.8.4
Desktop (please complete the following information):
- OS: Windows 10
- Version 19043.1165
The problem stems from the original state still being part of the token. So if you had a State called Old and renamed it New existing tokens will still have the Old state in their internal States collection even though it won't show up on the States tab nor can it be enabled via setState() function. If you save the token, edit the content.xml and remove the offending State, then load the edited token back in the grid states will function as expected. (Not suggesting you do this necessarily. Just making an observation.)
When the rename process scans the tokens and adds in the "new" state, it need to remove the old one from the token.
If an existing state is being modified, shouldn't the changes be reflected on every token that has that state? For example, if the state changed its positioning policy, wouldn't you expect to see that reflected on the map when the dialog was closed? Changing the name of the state doesn't need to be any different.
I don't have any expectations but changing properties other than the name of a state happens as you say.
Changing the name adds a new state to the token but doesn't remove the old one. Whether it modifies the existing state on the token or adds a new one while removing the old doesn't really matter as long as old states that are no longer part of the campaign are removed from the list on the token.
What happens if you save token, delete it, then drop it back on to map? I would assume the drop process does some cleanup assuming tokens could have other attributes not found in current campaign. I would assume [h: setAllStates(0)] would clear all states, even ones not apart of campaign. If not, that should probably be the fix we're after.
Tested:
- [h: setAllStates(0)] does not fix the issue.
- Saving the tokens with the screwed up states, and adding them back is a workaround, as it worked.
The worst part of this is that "Clear State" and setAllStates(0) don't clear the old states. If they did, this could at least be worked around. That said, because bars are also technically states, there isn't currently a great way to clear all states without potentially nuking the token's bars, which would be very surprising for users. We could check that we at least don't clear bars in these cases, but at that point we might as well make more aggressive improvements.
I'd suggest these changes be made together:
- Change states and bars to be identified by a GUID, not by name.
- Separate state and bar values in
Token. - Change "Clear State" and
setAllStates(0)to clear all states regardless of whether they are currently defined in the campaign properties.
(1) and (2) both require code to ensure backward compatibility, since they'll result in a change to how bar and state values on a token are serialized.
