Player movement moves all last-selected tokens

[djrenren]

Description

If the DM performs a rectangular select in the app that includes at least one token, then a player moves their token in the web app, the selected tokens will move in addition to the token. This happens in both "All" and "Turn-only" interaction modes.

PS, I love this app so much thanks for all your hard work!

[Rycochet]

Actually this is something I like - but only outside of combat - when my players are exploring then it's nice to have a single one of them in charge of moving the party (snake mode here).

If there was some indication that all the tokens are selected (dotted outline?) and it didn't happen in combat at all then that might be the best solution. Also - make it an option: "Group movement on external screen" or similar ;-)

[djrenren]

Thanks, for taking the time to respond.

I think that's a super helpful use case but I don't think selection is the right tool to enable it. In general, in collaborative spaces, selection is a local (not shared) property. For example, in google docs each person can have a different selection. This makes sense because selection is conceptually step 1 in issuing a command, not a mutation of document state. Although we're not working with documents exactly, it makes sense that selection is not part of the shared tabletop state.

My concern is more than conceptual though. If I'm moving around things using selection, those are most likely non-player controllable things like objects or enemies. I really don't want them moving these things basically ever. (I could think of exceptions but they're far far in the minority)

I love the idea of a visual indicator (even just for myself when I'm editing outside sessions), and allowing players to follow a given player sounds great as well! but I think it makes sense for it be a more explicit feature rather than a side-effect of selecting. Like if I could select tokens and then click a button that says "follow..." and select a token to follow, that'd be great and a lot less errorprone. I don't want to get into the weeds bikeshedding that feature, I'm sure there's numerous good ways to do it, I just wanted to demonstrate that there's a way to enable that use case while still fixing what feels to me, like a bug.

[Rycochet]

I feel it's a side-effect rather than a bug - that makes it a feature right?

Definitely want a better way to do it that's all planned out etc - maybe needs a Party Movement state, where anyone moving (by default) moves everyone, unless they deliberately choose not to (or vica-versa) - maybe something like the old Baldur's Gate game - with a toggle on this external screen (could even be handled entirely within the external screen I think).

The final result probably needs some thought / planning on how to fit with #29 and how to allow movement in some ways and not others (controlled NPCs etc). Also links in with #15 on the whole highlighting thing :-)

[djrenren]

Yeah, it just interferes with simultaneous movement of things by the DM and the players in weird hard-to-prevent ways. 😕

Anyway I think it's pretty distinct from player-specific movement restrictions. Making selection a client-local state, is mostly disjoint from restricting who can move what. Also, hopefully a less invasive change.

Looking at the app architecture, this seems to be an issue with how the move event is handled on the server side. Since the selection state doesn't seem to be replicated on the web app, and the communication protocol just defines the singular id (see the creatureMoved event), it's likely a result of re-using the movement logic from the app UI (where moving a single creature moves the whole selection by the same delta) instead of skipping that step when the event came from the client.