Open FullBleed opened 10 months ago
Pedantic moment. A* path finding uses heuristics and can be said to fall under the purview of machine learning/intelligence.
Is pathfinding a client side or campaign side thing? It should really be enforceable with campaigns that need it.
Pedantic moment. A* path finding uses heuristics and can be said to fall under the purview of machine learning/intelligence.
Perhaps... but at some point we're going to be able to use LLMs and on-the-fly generative art in-app. It could probably be done right now with the API's some of the various UIs support. And once we have that functionality, those features will line up with what is, currently, understood to be "AI". That big "AI" button on the top of the screen (which is only for "smart" pathing) is not aging well.
Describe the Problem
As is, the "AI Pathing" is too passive and misnamed. For low-tech/low-effort users to get more use out of it, there needs to be easier ways than onTokenMove and macros to enforce basic movement rules in their games. Smart-pathing and terrain modifiers are in the UI but get less use than they could since they don't do anything active. And for more advanced users that heavily use onTokenMove for rules enforcement, the built-in "AI" seems incompatible and is often turned off because it's passive and doesn't help them enforce any rules.
The Solution you'd like
1) Change name. There is no "AI" being used in this feature (as it's currently being used now in LLMs, generative art, and data training.) I hope that MT, someday soon, will actually incorporate the ability to use AI in-app to assist GMing. How that happens is a separate feature request, but continuing to call this feature AI just doesn't line up with what the expectations of AI are. Alternatives: "Path Tracking", "Movement Tracking", "Smart Pathing", etc.
2) Have a setting to allow the built in Movement Tracking to use token properties for "UsedMovement" and "MaxMovement". The actual names should be defaulted to something more unique so as to not impact existing frameworks, but should also allow users to set them to properties used in their frameworks. 2a) Allow the "UsedMovement" property to be modified based on the "AI" move. Deny move if "UsedMovement" plus the new movement is greater than "MaxMovement". 2b) Allow "UsedMovement" to be reset to "MaxMovement" a variety of ways: On new initiative, with a "Reset Move" button somewhere in the UI, by changing the "UsedMovement" property.
3) Add the option for a less passive enforcement of invalid moves by denying them. Currently the "AI" movement shows "invalid" moves by indicating "0" but still allows them. 3a) Instead of allowing all invalid moves, have the option for "Movement Confirmation" where if a token attempts an "invalid" move the GM could confirm/deny the move and allow it.
4) Continue to have a "Passive" mode option for people that prefer the current implementation or find the basic rules above are incompatible with their games.
5) Additional optional rules could most certainly be added to Preferences to support more systems overtime. The idea is to open the door to leveraging the tools built into MT to easily facilitate more active rules enforcement.
Alternatives that you've considered.
No response
Additional Context
The above is a very basic movement implementation, but it would allow users to use the smart pathing feature with some actual rules enforcement, movement tracking/blocking, and terrain modifiers. I currently use onTokenMove to enforce all of the movement rules in my primary framework and gain no benefit from the movement features built into MT because they are too passive and don't feel compatible with onTokenMove.