[Feature]: Cross-layer token group hierarchies

[henczati]

Feature Request

By token group hierarchies I mean a "forest" containing potentially multiple potentially overlapping (graph-)trees of tokens and other, already defined token groups.

It would be awesome to be able to move or apply other transformations to (e.g. rotate) preset and potentially overlapping collections of tokens at once, also potentially involving tokens from different layers.

This would be great for easily controlled movable structures with player & NPC and object (e.g. doors, levers, containers, movable vision or movement blocking stuff etc.) tokens on them (e.g. realizing ships or other vehicles, moving platforms etc.).
Also, this would make altering maps with lots of tokens already on them MUCH easier.

There is something somewhat similar implemented through macros in Wolph42's Bag of Tricks lib, but it has multiple limitations:

• In BoT, clicking on a token selects all other tokens in a group, so (I assume) overlapping groups currently doesn't seem possible.
• AFAIK, there is no reference list of groups to easily find/select/access/apply-mass-operations-to the specific required group.
• AFAIK, group hierarchies are not possible, which would enable e.g. easily controlled movable structures with tokens on them (e.g. ships or other vehicles, moving platforms etc.).
• AFAIK, it is not possible to group (and apply transformations to) tokens on different layers, because it it currently also not possible to select tokens from different layers together.
• If overlapping groups were possible, without group hierarchies it would be error-prone to select all tokens also in other (to-be sub-)groups (possibly dispersed over a huge area), especially involving higher token-counts. It would be too easy to miss or forget about one-or-two tokens.
• Rotating of BoT token groups is limited.

The Solution you'd like

I imagine a "Group Explorer" dialog, similar to the existing "Map Explorer", which ...

• ... when nothing is selected on the map, would display all defined group hierarchies.
• ... when one or more token is selected on the map and/or Map Explorer (depending on whether [Feature]: Keep on-map and "Map Explorer" selections the same or in sync #3678 is implemented), would display all group hierarchies that contain the selected tokens (directly, or indirectly through containing a (sub)group that contains them). This -- depending on the implementation -- can potentially be computationally intensive---in this case a "show groups of selection" or a more adequately named button and/or context menu entry would be acceptable to call this functionality on-demand.
• ... when right-clicked or otherwise displayed the context menu on a displayed token hierarchy, would apply the selected operation to all tokens in the group and its subgroups.
• ... clicking on a token group (hierarchy) could select all tokens in the group (directly contained) and in subgroups (indirectly contained) on the map (if [Feature]: Allow map-selection of tokens from different layers #3677 is implemented) and in the Map Explorer (if [Feature]: Keep on-map and "Map Explorer" selections the same or in sync #3678 is implemented).
  • Alternatively, selecting group elements on-map and/or in the Map Explorer could be on-demand e.g. by button or context menu entry. This would allow to have a separate selection on-map and buttons in the Group Explorer to add/remove on-map selected tokens to/from the group currently selected in the Group Explorer respectively.
• ... by default could display only the name/id of groups with a "+" before -- basically a collapsed subtree --, which could be expanded to show elements (subgroups, and potentially also tokens---see next sub-item).

  • The elements displayed in the expanded groups might be only their subgroups if [Feature]: Keep on-map and "Map Explorer" selections the same or in sync #3678 is implemented, and the directly contained tokens could in this case be selected in the Map Explorer (and also on-map if [Feature]: Allow map-selection of tokens from different layers #3677 is implemented) when clicked on the group name/id.

    Alternatively, expanding a group could also list the contained tokens, not needing to change the current selection in order to see what is contained, but potentially introducing clutter by overpopulating the lists and making it harder to have an overview of the separate group trees.

    These alternatives could potentially be option-switchable.

  • Subgroups might also be expandable inside their containing groups for easier overview and finding of specific tokens, but could introduce additional clutter mentioned in the previous item and would require to have synced copies of the same groups multiple times: the groups themselves, and every other time they are contained in another group.

    This behavior, if implemented, might be option-switchable.

• ... if right-clicked on a group name/id, would show a context menu ...
  • ... potentially different from that of token selections containing group operations (e.g. add/remove token).
    • If left-clicking the group name/id (or a group context menu entry or a button in the Group Explorer) would select all (directly and indirectly) contained tokens, there would be no need for the group context menu to contain the token-selection-specific operations, as it would be possible to invoke these on the resulting selection.
    • Alternatively, group context menu could also contain the token-selection operations---this would allow to operate token groups without changing the current selection (on-map and/or in the Map Explorer, depending on whether [Feature]: Keep on-map and "Map Explorer" selections the same or in sync #3678 is implemented), but would probably entail more complex implementation (having a slightly modified or extended copy of the token-selection context menu).
    • Alternatively, group-specific operations might only be accessible through buttons e.g. at the bottom of the Group Explorer dialog for easier implementation.

The selection context menu (on-map and in Map Explorer) could have a new "Grouping" or more adequately named entry containing grouping-related operations, e.g. create new group from selection, add selected token(s) to existing group, remove selected token(s) from specified group(s).
For operations concerning "existing groups", to avoid a dynamically changing context submenu, I imagine a dialog popping up, potentially on-demand discerning the groups the selected tokens are in directly (for remove) or all currently defined groups (for add). The pop-up dialog could have a multi-selectable list or a multi-checkable checklist of discerned groups.

Creating a new group ...

• ... could initially be named "Group ", similarly to groups created for drawings in the Draw Explorer.
• ... could be done by selecting some tokens and clicking on a "create"/"+" or more adequately named button in the Group explorer and/or in a "Grouping" or more adequately named submenu in the selection context menu.

  • If left-clicking and/or selecting a single or multiple group names/ids in the Group Explorer would not auto-select tokens on-map and/or in the Map Explorer (depending on whether [Feature]: Keep on-map and "Map Explorer" selections the same or in sync #3678 is implemented), then to-be-subgroups could also be selected in the Group Explorer and directly added to newly created groups, together with selected tokens (on-map and/or in the Map Explorer).

    Otherwise (if selecting groups in the Group Explorer auto-selects them on-map and/or in Map Explorer), to-be-subgroups could be added to already created groups in the Group Explorer by context menu entry (e.g. with pop-up dialog selecting the parent group) or button (e.g. by adding all-except-last-added-to-group-selection groups to the last group added to the selection of groups in the Group Explorer, or by selecting the target from a pop-up dialog as with the previously suggested context-menu option).

Implementation of group operations, e.g. group-rotation, spacing/group-resizing/scaling might potentially be done using on-group-operation-execution-generated dynamic bounding-object-hierarchies. This dynamic generation would probably allow overlapping groups avoiding conflicts in pre-generated overlapping hierarchies and lower memory requirements (due to always having to keep the hierarchies of only the currently selected groups that the operation is invoked on), but would potentially introduce too high computational requirements.
Alternatively, a subtree of a pre-generated hierarchy could be invalidated and right-away or on-demand re-generated if an operation on a overlapping other group makes it necessary. This, however, might need more complex implementation. Keep in mind, that all hierarchies should be able to fit in memory anyway, if all groups are selected for the operation.

Unresolvable conflicts in group operations on multiple (potentially overlapping) groups might result in the refusal of the operation with an error/information dialog showing why. This, however, needs to be able to detect such conflicts before any token or group is "touched" in the operation.

It should be possible to add tokens from different layers to the same group. So groups should not be layer-limited.

As drawings can already be grouped in a simple manner, potentially, groups could be removed from the Draw Explorer, and the Group Explorer might have separate tabs for token and drawing group hierarchies, which would work in similar ways. This was also suggested in #3681.

Alternatives that you've considered.

Grouping in Wolph42's BoT lib, which is better than nothing, but has multiple limitations.

Additional Context

No response