Material Plane integration

[OmegaRogue]

I use Material Plane with foundry for an in-person setup. Currently, moving a token with Material plane uses its own movement handling. It would be extremely useful to instead have Drag Ruler handle this, especially in regards of the routinglib support.

[manuelVo]

Since I have never used material plane myself, I would need some help in sketching out what the possibilities are. Drag Ruler's concept is that you plan your movement in advance and then execute it once you're happy with your path. I think the best way to unite this with material play is to have Drag Ruler start measuring once you lift the figurine and then show the distance to wherever you move the figurine and then once you put down the figurine on a new space the movement is executed. This raises the question whether it's possible for a material plane to detect if a figurine is lifted and put back down, which would be necessary to implement it this way. Do you have any information on whether this is possible or not? Looking at the trailer, it looks like material plane simply always moves the token whenever you move the figurine, which to me implies that material plane probably cannot do that, but I could be wrong.

Since you have explicitly mentioned routinglib, maybe it's a good idea to ask Material Plane to add routing lip support into their module. Routinglib is extremely simple to integrate into an existing module and if all that you need is to have tokens find their way around walls automatically then this would probably be the way to go.

[OmegaRogue]

Since I have never used material plane myself, I would need some help in sketching out what the possibilities are. Drag Ruler's concept is that you plan your movement in advance and then execute it once you're happy with your path. I think the best way to unite this with material play is to have Drag Ruler start measuring once you lift the figurine and then show the distance to wherever you move the figurine and then once you put down the figurine on a new space the movement is executed. This raises the question whether it's possible for a material plane to detect if a figurine is lifted and put back down, which would be necessary to implement it this way. Do you have any information on whether this is possible or not? Looking at the trailer, it looks like material plane simply always moves the token whenever you move the figurine, which to me implies that material plane probably cannot do that, but I could be wrong.

Since you have explicitly mentioned routinglib, maybe it's a good idea to ask Material Plane to add routing lip support into their module. Routinglib is extremely simple to integrate into an existing module and if all that you need is to have tokens find their way around walls automatically then this would probably be the way to go.

Material plane detects if you put it down, theres also a mode where it only shows a rectangle as a preview for the target movement position, the code for which is at line 115 in the file i linked

[OmegaRogue]

I was going to make a Pull request with material plane and put the integration into there, but as drag ruler doesn't have API for that, it has to go into dragruler

[manuelVo]

My point is that depending on your use case (do you actually want to show the ruler) you might be fine without Drag Ruler. If all that you want is pathfinding, you can simply integrate routing lib into material plane directly, entirely skipping Drag Ruler.

[OmegaRogue]

My point is that depending on your use case (do you actually want to show the ruler) you might be fine without Drag Ruler. If all that you want is pathfinding, you can simply integrate routing lib into material plane directly, entirely skipping Drag Ruler.

yes, having the ruler there would be very useful to actually see how far the planned movement is

[manuelVo]

I see. I think the biggest roadblock here is that I don't have a testing setup to actually develop this feature. To provide a good experience, it would probably not only be necessary to make the modules compatible but to do other tweaks like moving the distance indicator further away from the ruler so that it isn't hidden by the token. I am not sure how to go about this in a purely virtual manner without any physical equipment.

[OmegaRogue]

where would that integration need to be added in drag ruler and what would need to be done? i could help with it/do it

[manuelVo]

That's hard to say without diving into the Material Plane code, but I suppose one way to go about this would be if Material Plane would be emitting events (for example FigurinePickedUp and FigurineMoved, analogous to Foundry's OnDragStart and OnDrag Event). Drag Ruler could then register to those events and handle them accordingly.

Another possibility would be to have Material Plane emit the Foundry-Native Drag-Events. If that was done, Drag Ruler should just work out of the box, as it shouldn't be able to distinguish between real Drag Events and the Events generated by Material Plane. This would additionally have the benefit that other modules relying on Token Drag should start working too.

A third conceivable option would be to expose the Drag-Handling functions of Drag Ruler, so they could be invoked by Material Plane when appropriate.

This also comes down to whether the author of Material Plane is willing to add changes to their module for compatibility with Drag Ruler or not (do you have any information on this?)

[OmegaRogue]

This also comes down to whether the author of Material Plane is willing to add changes to their module for compatibility with Drag Ruler or not (do you have any information on this?)

yes, he said he'll comment on his view on how to do it later today

[MaterialFoundry]

I'm the developer of Material Plane.

Let me start out by saying that I'm not really familiar with Drag Ruler. I know what it's supposed to do, but I've never really used it, and I haven't looked at the code. But I am willing to make changes to Material Plane to get it to work with Drag Ruler.

I agree with the points made in @manuelVo's last comment, I'll quickly summarize and number the options for easier reference:

1. Material Plane emits Material Plane specific events, Drag Ruler picks up on those
2. Material Plane emits Foundry-native events
3. Drag Ruler exposes functions which other modules can call

I personally prefer both 2 and 3.

With option 2, other motion-related modules might also start working with Material Plane, which would be great. I could modify the drag events slightly so other modules can identify that Material Plane called the event, which might be useful. The only worry I have is that there might be some unforseen consequences, since motion is handled slightly different from native Foundry. But I'll give it a try and report back.

Option 3 is just nice to have, not just for Material Plane, even if I also implement option 2. It gives a bit more control over when to use it. For example, Material Plane allows NPCs to be moved, but the GM might not want to use Drag Ruler for NPCs. If functions like the following could be exposed, it would be great:

• start(); //called whenever a mini/token starts moving, starts Drag Ruler
• drag(); //called whenever the mini/token's position has changed
• stop(hide); //called whenever the mini/token stops moving, where the 'hide' parameter can be used to immediately hide the ruler, or to leave it on-screen
• hide(); //called to hide the ruler

[manuelVo]

Hi. Good to hear from you. I agree, that options 2 and 3 are preferable for maximum compatibility.

To what degree does movement in Material Plane differ from native movement? Drag Ruler replaces most of the native movement stack with a similar but modified copy that is able to special case handling for Drag Ruler. If movement needs to be different, this might implicate that Drag Ruler might need to do things differently when Material Plane is enabled.

Currently, Drag Ruler operates like this (which is similar to Ctrl+Drag in native Foundry):

• Once the token is being dragged (or the Figurine is lifted in Material Plane), Drag Ruler starts measuring. Starting from where the token's start position is to the location where the ghost token (or figurine) is.
• Once the token is being released (or the figurine is put down) the token will start moving from its initial location to wherever the ghost token (or figurine) was placed. The Ruler remains visible during that time.
• The token has arrived at it's destination (where the ghost marker or figurine is). Once this happens, the ruler will be hidden.

[MaterialFoundry]

The biggest difference is that for Material Plane there isn't really a distinction between the 'ghost' token and 'real' token. While the token's position isn't updated to the server until it is released, as far as the client is concerned it's always the actual token being moved. While the token is being moved, line of sight is being updated, and wall collision checks are being done. This also allows tokens to be moved around a corner in 1 go (there's currently no pathfinding, but it allows players to maneuver around walls). When the token is released it doesn't then travel from it's starting position to its new position, it just snaps to the grid and that's it (and deselects the token, if configured to do so).

This video (from around 0:40) is a pretty good demonstration of what this looks like: https://youtu.be/hNYFYm6KqTQ?si=bLu1kBribdQsbcqc&t=40

If I understand it correctly, for option 2 to work, Material Plane would have to call the Foundry onDrag functions. I think the only way that'd work is if I start modifying the prototype functions (and use libwrapper to try to get it to work nicely with other modules), but considering how much I'd have to modify them, it's probably more trouble than it's worth.

[manuelVo]

If I understand correctly, the movement mechanic in Material Plane works pretty similar to foundry native if the setting "Token Drag Vision" turned on. I suppose the two or three main differences are that "Token Drag Vision" doesn't hide the original token and does play a movement animation after dropping the token. Fog of war handling might be different too. "Token Drag Vision doesn't update the fog image while dragging the token; it's only updated during the animation. That way, areas will be covered by fog again if you drag the token too far and pull back before dropping it. How does Material Plane handle this?

While I'm not very eager to implement an entirely new movement scheme into Drag Ruler (I'll have to check how much effort it would be), I feel like a good compromise would be for Drag Ruler to force the "Token Drag Vision" setting on when Material Plane is enabled (and maybe skipping movement animations). While not exactly identical, this might be a good compromise to reach a similar visual effect while avoiding having to make huge changes to either module. What do you think?

[OmegaRogue]

There currently are 3 supported movement modes in material deck: Live, Step-by-Step and Foundry Default, live is the behaviour described by @MaterialFoundry , Step-by-Step "moves the token onto every grid you drag along, updating the vision every step", and Foundry default is the default Foundry behaviour of updating the vision after movement.

I personally use Foundry default, as i have some quite large scenes that slow down foundry to a crawl with token vision animation enabled (might be some module problem tho)

[MaterialFoundry]

@manuelVo

If I understand correctly, the movement mechanic in Material Plane works pretty similar to foundry native if the setting "Token Drag Vision" turned on. I suppose the two or three main differences are that "Token Drag Vision" doesn't hide the original token and does play a movement animation after dropping the token.

Visually it's very similar to Token Drag Vision, but Token Drag Vision doesn't allow movement around corners, there always needs to a straight unobstructed line between the token's origin and destination.

That way, areas will be covered by fog again if you drag the token too far and pull back before dropping it. How does Material Plane handle this?

Material Plane doesn't do anything about that. If you've moved too far, FOW will be revealed and will stay revealed. This is because I want FOW to be updated along the exact path the figurine moved, not just the path from the tokens origin to its destination. While exploring with figurines, it would be really annoying to have to keep releasing the figurine in order for the FOW to update. This does mean that you might accidentally reveal too much of the map, but considering you'll probably be playing in-person I don't think that this is really an issue (it can't really be abused for metagaming purposes, because the GM will be sitting right next to you).

While I'm not very eager to implement an entirely new movement scheme into Drag Ruler (I'll have to check how much effort it would be), I feel like a good compromise would be for Drag Ruler to force the "Token Drag Vision" setting on when Material Plane is enabled (and maybe skipping movement animations). While not exactly identical, this might be a good compromise to reach a similar visual effect while avoiding having to make huge changes to either module. What do you think?

I don't think Drag Ruler should try to handle Material Plane movement. I wouldn't want there to be a difference in how movement is handled between having Drag Ruler enabled or not, and without having the hardware it might be difficult to properly implement it.

I think it would be better to focus on option 3, or I could implement Drag Ruler-like behavior directly in Material Plane. Unless I'm missing something, the most basic version (without pathfinding) is just drawing a ruler between the token's origin and current position which can be handled by native Foundry's ruler class.

@OmegaRogue Up until now I've only really talked about the 'Live' movement method, since I consider that to be the main movement method. For the 'Foundry Default' method, I don't see why calling the native Foundry movement events wouldn't work, which would allow Drag Vision to work for it. I could look into that.

[OmegaRogue]

@MaterialFoundry doing that for "Foundry Default" and option 3 or a custom ruler implementation for "Live" sounds like a pretty good option, giving the option to let drag ruler handle everything (maybe with some additional data so that drag ruler can draw the distance text a bit further away to not have it covered by the mini)

[OmegaRogue]

Are there any news on this?

[MaterialFoundry]

I've decided to implement my own version of Drag Ruler into Material Plane, including pathfinding using routingLib. So I think this issue can be closed.