toggling larger areas?

[Wokeye27]

Awesome module! Simpler and more reliable than the Manual Fog alternative I've been using to date. One thing I noticed that it was onerous to toggle larger areas, esp when you accidentally re-toggle hexes when clicking quickly to cover a lot of ground efficiently. Suggestion: a 'painter' type function to toggle a larger number of hexes on (or off) quickly.

[CarlosFdez]

Will consider it.

[RuebenMF]

I'd also really appreciate this feature :)

[epsilon7430]

Just bumping this feature request. As a GM user, it would be useful to be able to show/hide the fog for larger areas in one mouse click or perhaps using a drawing. This is especially useful for larger scenes, e.g., world maps, where there are may be expanses of known areas that could be revealed or hidden more quickly than one cell at a time. Thanks

[CarlosFdez]

The problem with this is coming up with the UI or the particulars. The only thing that comes to mind is a new brush control with a slider application ala simple fog as a little popup application. Then we would reveal every single spot based on some metric, which would be either if the center point of the grid square/hex overlaps, or if there is a supermajority of the grid spot inside the brush circle.

Placeable objects that reveal a circle around them is a possible solution for more granuar reveals, but for a permanent reveal in mass we need something more specific that maintains the tile by tile reveal approach, as that's how reveals are actually persisted as.

In general I've only been developing based on a need basis from my ongoing campaign. Given the end of the new year, the campaign has been on some hiatuses, so combined with my current system dev and contract work that has impacted feature dev.

[epsilon7430]

Perhaps a minimalist solution is to bind an optional key press to work with the mouse click so that the toggle tool affects a larger area, e.g., pressing shift-click could toggle cells in the circle around the selected cell. Using two different keys, e.g., shift and ctrl, to either reveal or obscure. It would help if the key press were to roughly highlight the cells that will be changed before the subsequent mouse click. The circle diameter size could be adjusted while pressing the key and using the mouse wheel (left decrease, right increase).

[CarlosFdez]

Its a bit more complicated than that, because the toggle tool is a binary flip for the current grid position, and has no radius (its an intersection check). That solution requires us to make it a circle, decide on what mechanism we will use for checking what's in there (midpoint inside the circle is my guess), and then decide how the flip will work. For example, will every space around it flip on/off from their respective position (like one of those puzzle games)? Or will it still work like it currently does for the tile you're clicking on, but then whatever that tile is set to, it will share its new state with all other tiles within the circle?

Hotkeys are also too complex for most people.

A "share" approach might work but it might be cumbersome. I think we'll need to have a brush tool and eraser tool.

[epsilon7430]

Selecting based on cell centroid should be sufficient and I suspect it will be important for users to see a preview of the circle and/or affected cells as the mouse moves across the canvas. It might be similar to viewing a circle spell template.

Flip state definitely needs to be the same for the affected cells or we will go insane playing Whack-a-Mole. I agree a brush (reveal) tool and erase (obscure) tool would be more user friendly. These tools wouldn't replace the single cell toggle tool, which would still be very handy.

I suppose the circle radius could be set with a slider. I suspect performance factors will limit the maximum possible radius.

Thanks for the consideration!

[CarlosFdez]

Its likely the initial version wouldn't even have a slider, maybe just be a circle with a preset size (maybe 1.5 units diameter) that you can swipe around with. For want of time constraints it might be best to handle 90% of cases.

I'm very busy with a work project, and this is something on the more involved side. I might get around to it afterwards but I cannot start now by any means.

[EsotericOdyssey]

desperately need some kind of functionality for toggling larger areas on/off, as it stands there's no way I'd be able to make practical use of World Explorer for my current campaign map it's an awful lot of squares to have to individually toggle

[CarlosFdez]

Its very likely a brush reveal/hide mode will exist in some form in the future, the problem currently is one of time and experience. I'll have to learn more pixi and how the Application class in foundry works to implement that, while I'm already busy with other things.

I'd accept a pull request, but until then, it can only be when I find some time. Between PF2e dev and DMing its hard to find any, but at least it should be possible now that I've dropped developing for Better Rolls.

[CarlosFdez]

This isn't quite what was wanted quite yet, but there is a reveal/hide tool that supports click dragging. There's no brush size though. That will need to be added later.

[EsotericOdyssey]

click-dragging helps quite a lot, still!

[epsilon7430]

Sadly, the click-dragging REVEAL feature is not currently usable on my PC. The lag between dragging and seeing grid cells revealed is like watching a very slow animation, and most cells don't become revealed. The PC is thinking hard because the fans ramp up quickly. The behaviour is also curious: if I drag real slow to reveal two cells, the first starting cell changes its state AFTER the second cell changes (i.e., doubles back on itself). The cells are hexes.

Not tested with other modules inactive, however, no console errors showing up. (Enhanced Terrain Layer is inactive because of its known incompatibility).

Dragging using the hide tool seems to work as expected.

[CarlosFdez]

That's so....strange. I'll need to consider implementing buffering so that updates are batched, or checking if perhaps its sending updates constantly. I should migrate the data format while I'm at it, just in case that is the cause.

[CarlosFdez]

I've optimized the storage format a tad (unreleased) but it didn't fix the issue. I suspect the problem is because foundry's io updates have a delay, and I will need to implement buffering. Unfortunately looking into this has cut into my campaign prep time, so I will need to revisit it this weekend. For now, draw slower..

[epsilon7430]

Thanks for investigating. Our players (probably) do not appreciate us enough.

I do wonder why the hiding of fog doesn't seem to have the same issue, but there may be good reasons. It is all too arcane for me.

[CarlosFdez]

I think fog is handled locally per player. So it doesn't have to contend with scene updates.

Not that making this perform well is impossible, more that I'll need to be a bit more clever than triggering a scene update on every flip.

[CarlosFdez]

As of the recent release, buffering should make the updates quicker. This should hopefully be resolved now.