Map suggestions and bugs

[Guoccamole]

IMO, one of Fantasy Grounds principle strengths is 1) large library of commercial materials, and 2) large base of players with personal materials. All of these will need upgrading to the FGU LOS/FOW way of doing things. Which means the (time and general) pressure is on to remove glitches and UX inconsistencies, for general ease of use and minimal surprises. Many FG fans are immediately going to adapt maps to FGU, so FGU mapping will be a choke point to FGU satisfaction, IMO. Therefore, I’d simplify and solidify the mapping UX as much as possible before releasing to the ‘masses’.

So, I am going to document my mapping bug reports and UX suggestions in no particular order in a succession of posts, since I have a lot and will share them as I remember them. All my suggestions are in context of ‘simplify and solidify’ as much as possible, except where explicitly suggesting feature to solve problem (simplifying in larger context of converting, rather than simply mapping).

1) I would suggest making the option types (wall, terrain, door, or secret door) active when switched so that, if any mapping elements are selected, the element(s) changes to the new option type as appropriate (and possible).

2) Holding space bar would be great for toggling tool to basic pointer since that’s the most common tool needed on ad hoc basis. If space bar is considered ‘taken’, then please provide a different basic (non-shift) character for ease of access.

3) Need Style Guide. Videos are useful but not sufficient for easy reference or laundry list. Style guide with embedded videos would be even better.

More later.

[Guoccamole]

4) Selecting and deleting a few points in a circle (in my experience) usually deletes just one of the points and never deletes all the selected points. And then often (always?) deletes too many on the next deletion. So, takes two deletions plus some fix-up to address problem. Actually, now that I analyze the situation more, it seems pretty random (+/- 1/2) how many points get deleted, but never the correct ones.

5) Occasionally, selecting terrain option and laying down some terrain results in wall terrain (or, at least, red colored graphic representation). Restarting program fixes problem. I have not checked whether the laid down terrain stays wall upon reboot (as I have deleted it before reboot). Not sure what causes this. Happens occasionally. Not sure if there’s an easier way to ‘reset’ the wall condition than to restart FGU.

6) It would be nice if circles (et al.), when ‘undone’ after first creation converted from (laid) dots to drawable circle off of pointer so that they could be relain (e.g., enlarged, shrunk, elongated, et al.). Next undo could erase the circle (et al.) as desired. This feature is useful (e.g.) when map feature requires tight fit which leads to repeat attempts to match large imperfect shape on map, etc..

[Guoccamole]

7) Leave circles (et al.) selected, even after move or some other operation. Automatic deselection is non-standard and sometimes creates busy-work, and manual deselection is trivial (simple tap/click screen).

8) Terrain (closed) “lines” are annoying to use with the dangling line. Especially so on large areas where one can mistakenly double-tap and “close” the area prematurely. Also, this UX is different from wall lines. I recommend removing the dangling line UX. (More on “terrain” mode later.)

9) Terrain lines don’t seem sliceable (a la Doug Davison’s secret door video: https://www.youtube.com/watch?v=occJtzxaw3Q). I suggest keeping lines consistent, i.e., sliceable et al., across all tools option types. Otherwise... inconsistencies will bite UX and frustrate users.

[Moon Wizard]

Please place any bug reports or suggestions in a new thread. We want to keep the LOS thread mainly for LOS coordination on existing maps, and questions. I just don’t want it as a place for general concepts, especially since I tend to only quickly scan through this thread.

Thanks for the suggestions. A few comments:
1) I’ll have to think about this. I’m not sure this would be expected behavior for most users. At least it’s not for myself and other developers.
2) Spacebar is already used to mimic mouse single click for placing walls. It should also be able to activate the initial wall start, but that’s not working yet.
3) Doug and I have discussed a style guide; and it’s on his list to do. It may be a while, since we’re getting ready for beta.
4) I’m not sure what you mean by select points in a circle; selection is only by clicking on points or marquee selection. I think a video may help us understand what you are seeing.
5) A video here would help as well; since creating a reproducible scenario is the only way for us to identify the problem.
6) I’m not understanding what you are asking here. Perhaps an example would help.
7) Yeah, selection should not be changed after move. I’ll need to file an issue when I get back to my office.
8) I agree. That’s a recent change that occurred due to another fix; and I need to file an issue for this one as well.
9) The lines should create overlap points regardless of blocker type. I’ll need to investigate.

JPG

[Guoccamole]

MoonWizard/JPG, thank you for moving my posts and creating a new thread with them here for discussion. Since I had some additional comments (#10+) in the LOS thread which I never got around to posting, I shall post them here. I shall respond to your feedback/questions on 1-9 and add 10+ fresh, and clarify where necessary, so we can keep moving the UX ball forward.

I’d also like to add some focus to the high priority items. So I’ve separated items into Short-Term (ST) meaning ASAP to support simple, solid (no need to change fundamentals) map-making, and Long-Term (LT) meaning when time permits. ST suggestions would ideally happen before too many mapmakers start doing conversion (i.e., before too many maps are converted, and then need rework/reconversions), hence high-priority for user community (and presumably SmiteWorks).

I have also put some items earlier when I think they are key and simple to implement (low hanging fruit).

So the suggestions are no longer listed in numeric order (which was in no particular order) given new ST vs LT sort order, and pushing low hanging fruit.

For UX issues (#1), I defer to the new SmiteWorks staff UX expert though I shall make suggestions which I believe are UX standard.

... Short-Term suggestions

Feature Request
3) Need Style Guide. Videos are useful but not sufficient for easy reference or laundry list. Style guide with embedded videos would be even better.
JPG) Doug and I have discussed a style guide; and it’s on his list to do. It may be a while, since we’re getting ready for beta.
Guo). IMO, FGU kinda needs something now. How about a FAQ to get newcomers started with basic know-how of FGU LOS mapping?

Feature Operation (Terrain)
8) Terrain (closed) “lines” are annoying to use with the dangling line. Especially so on large areas where one can mistakenly double-tap and “close” the area prematurely. Also, this UX is different from wall lines. I recommend removing the dangling line UX. (More on “terrain” mode later.)
JPG) I agree. That’s a recent change that occurred due to another fix; and I need to file an issue for this one as well.
Guo) I am glad this terrain change is a recent change. I am hoping that means the current way of doing things is not set in stone. My suggestion is too long to lead with, even though I believe it's valuable and important. Please see separate post in this thread for discussion of Terrain (https://www.fantasygrounds.com/forums/showthread.php?51416-Map-suggestions-and-bugs&p=457547&viewfull=1#post457547). TY

... Long-Term suggestions (not as pressing, or not as important)

Feature Request
1) I would suggest making the option types (wall, terrain, door, or secret door) active when switched so that, if any mapping elements are selected, the element(s) changes to the new option type as appropriate (and possible).
JPG) I’ll have to think about this. I’m not sure this would be expected behavior for most users. At least it’s not for myself and other developers.
Guo) I guess the real feature request is a (simple) way to change a map feature from one option type to another. The option selector is the obvious way (to me) to do that. However, if the SW UX expert has a better way to do it, that's fine. (Perhaps through an info dialogue for selected item(s)?). But I would suggest adding that feature as I've ended up redoing stuff multiple times because I mapped using the wrong option type by default, or because I realized too late that I really needed a different terrain option. This feature would ease the learning (and experimentation) curve as well, and eliminate some make-work redos.

Feature Request
2) Holding space bar would be great for toggling tool to basic pointer since that’s the most common tool needed on ad hoc basis. If space bar is considered ‘taken’, then please provide a different basic (non-shift) character for ease of access.
JPG) Spacebar is already used to mimic mouse single click for placing walls. It should also be able to activate the initial wall start, but that’s not working yet.
Guo) By the way, the feature I'm requesting would be to interrupt whatever is happening by pressing (and holding) space bar to access basic pointer as long as needed (i.e., monkey with some terrain dynamically, usually tweaking something and then releasing space bar to return to job, e.g., laying some wall).
I could see how spacebar is convenient if you're using cursor keys to lay down maps (a la Doug Davison's recent cool video... https://www.youtube.com/watch?v=7KDchDFdw8g). However, when using a mouse or pen/tablet, there's already a button to lay down a point. The extra way to lay down a point (space bar) is redundant. Under normal mapping circumstances in my experience, a far more valuable use for the space bar would be to invoke a quick use of the basic pointer tool to, e.g., clean something up. If pointer is not the default, please provide an option in FGU to make it so.
The quick access to basic pointer tool would allow quick fixes to loose ends, instead of having to either pause what you're doing to change modes (which usually feels like too much of an interruption) or remember to come back to deal with loose ends. On big, repetitive maps, dealing with loose ends repeatedly becomes a hassle and error-prone as loose ends are all too easily forgotten due to interruptions, complications, etc.. Having that basic pointer available at all times at the press of the space bar would be very valuable.
I also believe the space bar / basic pointer is UX standard (Adobe?). Please ask your UX expert.
I was tempted to put this one in ST because it (IMO) seems so basic/useful, however it could be a coding challenge (nested pointer tool UX), so perhaps not a low hanging fruit.

Non-critical Bug
4) Selecting and deleting a few points in a circle (in my experience) usually deletes just one of the points and never deletes all the selected points. And then often (always?) deletes too many on the next deletion. So, takes two deletions plus some fix-up to address problem. Actually, now that I analyze the situation more, it seems pretty random (+/- 1/2) how many points get deleted, but never the correct ones.
JPG) I’m not sure what you mean by select points in a circle; selection is only by clicking on points or marquee selection. I think a video may help us understand what you are seeing.
Guo) I can see how my description is confusing. Clarification. Having laid down a circle (of points), when I then select a rectangle subset of points from that circle to delete, the deletion does not behave as expected. Fewer points get deleted than I selected, and sometimes some different point(s) along with a few of the selected points. The second try to finish deletion seems to work. Always involve some make-work do-over, though. So something is amiss.

Non-critical Bug
5) Occasionally, selecting terrain option and laying down some terrain results in wall terrain (or, at least, red colored graphic representation). Restarting program fixes problem. I have not checked whether the laid down terrain stays wall upon reboot (as I have deleted it before reboot). Not sure what causes this. Happens occasionally. Not sure if there’s an easier way to ‘reset’ the wall condition.
JPG) A video here would help as well; since creating a reproducible scenario is the only way for us to identify the problem.
Guo). I am using PC only because FGU does not run on MacOS (yet). Is there an easy way to capture screen video which you/anyone would recommend?

Feature Request
6) It would be nice if circles (et al.), when ‘undone’ after first creation converted from (laid) dots to drawable circle off of pointer so that they could be relain (e.g., enlarged, shrunk, elongated, et al.). Next undo could erase the circle (et al.) as desired. This feature is useful (e.g.) when map feature requires tight fit which leads to repeat attempts to match large irregular shapes, etc..
JPG) I’m not understanding what you are asking here. Perhaps an example would help.
Guo) Yes. So, if I am laying down a terrain circle on a big turret which is not perfectly round (or any difficult to match map feature), I may not get the size/shape perfectly correct on the first/several tries. However, once I lay it down, the 'circle' turns from resizable dynamic circle to a bunch of dots connected by lines. It would be nice if there were a way to back up a step (undo) to the dynamic circle for retry... without having to delete the not-quite-right circle and start over. This is especially true of large features which are hard to see key details while laying the map. Redo's would be convenient, so as not to have to restage the whole terrain feature again from scratch, whereas starting with latest try may make for a few easy corrections.

Non-critical Bug
7) Leave circles (et al.) selected, even after move or some other operation. Automatic deselection is non-standard and sometimes creates busy-work, and manual deselection is trivial (simple tap/click screen).
JPG) Yeah, selection should not be changed after move. I’ll need to file an issue when I get back to my office.
Guo) TY

... Short Report Replies Continue In Next Post

Bumped against (annoying and arbitrary) 10,000 character limit in post. Cough, cough. So...
Short Reply #9 and four new short reports and one long report/suggestion... to go.

Please see next post for #9 reply and four additional short reports (all Long Term non-critical).
Please see next post after that for an extended suggestion for "Feature Operation (Terrain)"

[Guoccamole]

[Continued #9ff]

Non-critical Bug
9) Terrain lines don’t seem sliceable (a la Doug Davison’s secret door video: https://www.youtube.com/watch?v=occJtzxaw3Q). I suggest keeping lines consistent, i.e., sliceable et al., across all tools option types. Otherwise... inconsistencies will bite UX and frustrate users.
JPG) The lines should create overlap points regardless of blocker type. I’ll need to investigate.
Guo). TY. On this one as it relates to Doug's secret door application, I would suggest that for that specific case (secret door intersecting existing walls), laying the secret door should take care of ALL the busywork of cleaning up all extraneous lines w/in (new) secret door, and close off any intersected walls. Yes, that would be a 'special case' but, since there's so much pure busywork for that case which is totally doable by computer, I would suggest letting the computer take care of that in one fell swoop as side effect of laying (secret or non-secret!) door.
Having FGU take care of that special case would make for a great efficiency of map-makers by allowing them to lay (linear) walls in great sweeping first phase, and then laying of doors in rapid succession on top of walls... with auto-cleanup by FGU. And... even better demo video for Doug!-)

Non-critical Bug
10) Different terrain option types (e.g., wall to terrain) do not always seem to magnetically snap to each other. Since control key and magnet toggle control snapping, snapping behavior should work according to magnet (and control key) status for consistency.

Non-critical Bug
11) When creating rectangles and doors, and then manipulating the shapes, it would be nice if all corners behaved as if fully integrated, rather than one corner having two ends... which select and move separately. This corner inconsistency is different than the other three corners for no apparent reason. (Presumably it’s a start-end corner, but user does not create that, so the fiddly behavior makes for undesirable surprises and make-work.)

Feature Request (FAQ request for existing feature?)
12) On shapes, e.g., pre-existing terrain, having a way to create new points on a line would be very useful for picking up where one left off, tweaking existing terrain features, and resuming after a premature double-click. (Perhaps this feature already exists, but I just don't know the gesture or shortcut to get it?)

Feature Request
13) Shift should lock 1) lines into horizontal/vertical, 2) rectangle (or any closed polygon) into square or appropriate regular polyhedron, and 3) ovals into circles. Shift circles work. Not so much the others.

... Please See #8 Feature Operation In Next Post

[Guoccamole]

[Continued]

Perhaps the key suggestion I have is to simplify default Terrain from “closed” polygons to simple lines (a la existing Walls but with simple, configurable terrain settings). I believe this approach would both simplify UX and (presumably) code for the better. FGU mapping UX would become more consistent. FGU code would become DRYer for the better.

Obviously, these are my opinions, so feel free to take them with a grain of salt. Or feel free to drill me down if there’s something which needs clarity or does not (seem to) make sense. FYI, all of these opinions are based on my experience converting the “Hoard of the Dragon Queen” player maps (available here https://www.fantasygrounds.com/forums/showthread.php?50591-FGU-Sharing-LOS-Definitions-for-Maps-Crowd-Project&p=450748&viewfull=1#post450748) which provided plenty of map variety and conversion challenges as well as the experience-based inspiration for a 'new' Terrain approach.



8) Terrain (closed) “lines” are annoying to use with the dangling line. Especially so on large areas where one can mistakenly double-tap and “close” the area prematurely. Also, this UX is different from wall lines. I recommend removing the dangling line UX. (More on “terrain” mode later.)




8) I agree. That’s a recent change that occurred due to another fix; and I need to file an issue for this one as well.



... Philosophy: Simplify and Solidify UX for wider release (beyond alpha)

Echoing my opening thread post, here are the three priorities of these suggestions (driven by simple and solid UX for beyond alpha FGU user):

1) Consistent, standard UX (e.g., with existing graphics UX),
2) Simplicity, and
3) Minimal Surprise

I shall try to go into sufficient detail without going into all detail due to post limit (10K). If the proposal does not land, then I don't waste everyone's time. If it lands, and you would like more detail, that's great. I would be happy to oblige.

I suggest a different way of handling terrain LOS than the default closed polygon. Use lines (a la Walls).

FYI, I am not the only one finding the current Terrain UX confusing and non-intuitive, and thinking lines are intuitive to address Terrain LOS concerns (https://www.fantasygrounds.com/forums/showthread.php?50608-Alpha-testing&p=450688&viewfull=1#post450688).

I believe there are very objective reasons the current polygon Terrain approach has issues. The current terrain approach has not only the interfering dangling (closing) line, but it's also inconsistent with Wall use of line tool. I suggest keeping the line tool as a... line tool. In other words, keep the UX and the code as simple and consistent (minimize surprises, inconsistencies) as possible. Simple and consistent will make FGU easier to learn and use. This proposal aims to do just that.


Starting at the top...

The current FGU mapping modes are:
Modes: Play | Layers + Basic Paint + FX | Layer LOS + Global LOS | Grid
Let's focus solely on "Layer LOS" since that's where the lion's share of mapping happens. This discussion takes place entirely in the context of "Layer LOS" mapping.

The "Layer LOS" tools and options are:
"Layer LOS" Tools: Selection/Edit [basic pointer] | Add Line + Add Rectangle + Add Ellipse
"Layer LOS" Options: Wall + Terrain + Door + Secret [door] | Duplicate Paint Lines | Point Delete + Point Segment(s) Delete | Magnetic-snap
Let's focus on the "Layer LOS" tools and just their first four options: Wall + Terrain + Door + Secret [door].

... The Four "Layer LOS" Options (Wall + Terrain + Door + Secret [door])

Let's look at the UX of these tools options in pairs.
Wall and Terrain UX work similarly, except Terrain has a dangling closing line. Both create multiple line segments, though Terrain attempts (achieves?) to create closed polygons.
Door and Secret [door] UX work identically. They both create doors.

Let's look at the effects of these tools options in pairs.

Door and Secret [door] effects have different side effects, but they behave similarly. One has UX visible to GM and players, while other is invisible to players until GM toggles visibility to the Secret [door] for the players. This door in/visibility effect could be configured via a simple toggle selection in a map feature dialogue during map conversion/creation.

Wall and Terrain UX both create walls. Wall can create open and closed (polygon) walls. Terrain tries to create only closed (polygon) walls, but has issues (e.g., creating double line segments w/o any area, blocking line of sight in open areas, and conflicting LOS with neighboring Terrain areas) with effects which are not always the desired effects and bounds. The "closed polygon" effect which distinguishes these two options could be a simple toggle selection in a map feature dialogue, which either adds a closing line segment, or is only available for walls which end where they begin (i.e., are already closed manually).

NB: The two doors have identical UX and differ only on effect feature (in/visibility setting). They are consistent. The Wall versus Terrain... not so much. Terrain goes off the UX rails with dangling line, and conjures up many edge cases with its odd UX.

I suggest a different way of handling terrain LOS than the default closed polygon. Use lines (a la Walls).

Rather than make things complicated, I'm going to simplify to make my point.
Instead of Doors and Secret [doors], just have Doors (and a toggle for visible/secret).
Instead of having Walls and Terrain, provide Walls with LOS toggles (and other useful LOS parameters).

I.e., get rid of special Terrain UX. Let Walls handle LOS.

... How Would Walls Cover LOS?

Wall line segment(s) would have options for visibility as follows: None.None (no way, a la Wall), Left.None (one way, a la cliff), Right.None (one way, a la cliff other way), Left.Right (two way, a la Window). A basic 2x2 matrix covers the binary visibility options.

These options would be built-in to existing terrain options, and customizable via a Terrain Configuration Panel.

Likewise, each direction with visibility would also have a trigger toggle (none, either, or both directions), each of which could have a distance (default: 5 feet). Visibility would trigger off distance) as tokens approach the terrain feature. Trigger distance could be configured in terrain configuration panel (where toggles would also be configured). This Walls/LOS approach works great for ledges, balconies, stairways, and many other common map terrain features.

Wall line segment(s) could also have a toggle for permeability in the terrain configuration panel similarly: None.None (no way, a la Wall), Left.None (one way door), Right.None (one way door other way), Left.Right (two way passage). Walls would have no permeability. "Terrain" features such as hills and rooftops would be pass-through (permeable). This configuration opens the option for windows (transparent, but impermeable).

This approach uses a terrain configuration panel to for maximum leverage (and expandability) to configure/tweak desired effects of Wall segments. The UX would remain identical to placing lines, but greatly empowered by configuration. Custom configurations could be assigned custom terrain options for easy, quick access (e.g., windows for modern settings).

Also, unlike the current Terrain polygons, neighboring LOS lines would not conflict due to troublesome overlaps or areas of effect as they could inter-operate even when their effects overlap. Nor would LOS terrain block open area visibility unnecessarily. The LOS lines could be very selective or permissive about direction.

Lines are easy to understand and less fiddly. Just lay the LOS line, configure directionality of LOS, and done. If keyboard shortcuts are provided, the configuration could be done w/o going to terrain configuration panel, and could be tweaked with same shortcuts. Options could provide the common configurations (a la Door vs. Secret [door]).

I believe I have covered the basics of the proposal, and the character limit beckons.

Bottom line: lines are much simpler and more appropriate for controlling LOS than 'areas'. The current "Terrain" UX boils down to lines (when simplified). And everything (including code) simplifies when sticking to lines. Areas overcomplicate the common LOS situations.

... Next Steps

A more advanced terrain configuration panel could include a "closed" feature which creates areas. Areas could be used as triggers for special cases (e.g., reveal hidden terrain on 2+D maps). As a next step, I would encourage 'area' support with a 'closed' toggle in a ("the") terrain configuration panel as areas can solve some special case problems. Areas could be configured to support preconfigured map area effects (e.g., darkness spell (area)) or map reveal (2+D caves, tunnels, bridges) by proximity to location. But this topic would be a subject for another day...

I hope this experience-based exposition/proposal helps 1) illustrate practical problems with current area Terrain approach, and 2) provides a simple, effective path forward with this Wall/LOS Terrain proposal.

The closer to 'done' FGU mapping can be before FGU gets swarmed, the better. I hope this Wall/LOS Terrain approach helps inform a solution to replace the current Terrain approach. This Wall Terrain + LOS directionality is how I was thinking about terrain while mapping the player maps of "Hoard of the Dragon Queen", and (as mentioned above) I am not the only one to have intuited how Terrain must work via LOS line segment(s) directionality. This approach leverages walls with a Terrain Configuration Panel for a simpler, consistent, yet more powerful Walls/LOS based UX.

TY for reading this far.
Comments, feedback, questions appreciated.

[Moon Wizard]

Style Guide
I understand you want something now for the style guide. I'll mention to Doug again. However, as we have mentioned before, we only have a handful of people to work on this project, and we're trying to get a release out the door. Also, this is a bit of a moving target, since some of the stuff we suggest is being driven by what you guys are finding. We're doing our best, and we'll try to get something out soon.

Screen capture
I use a tool called Screencast-o-Matic to capture videos of issues (MP4). It also does animated GIFs, but those are much larger than MP4s, so those are better for us to be able to reference in our bug tracking system. There are a few tools out there you can try that do partial screen capture, if you want to explore one that works for you.

Dangling lines
Filed as issue FGU-528.

Multiple LOS selected point deletion
Thanks for clarification. Filed as issue FGU-530.

Point selection cleared on move
Filed as issue FGU-532.

Terrain lines not sliceable
I'm not able to recreate this. If I draw a terrain polygon, then I draw another wall blocker through one or more lines of the polygon; then intersection points are created. You can then remove the blocker you used to create the intersection points. While this isn't an optimal workflow and we've talked internally about eventually adding a "cut" type of tool, it is something that can be done today per Doug's videos.

Snapping between blocker types
I'm not seeing this. Snapping is defined specifically to work on points, not on shapes. When I just tested, I was able to get the points to specific points added to snap to the nearest points already defined. Are you seeing something different? Or referring to a different capability than just point snapping on addition?

Polygon corners
Filed as issue FGU-533.

Terrain as lines
As I mentioned in the other thread, terrain is defined by us as a region into which a token can see, but can not see outside of. Therefore, terrain must be a polygon, or there is no "end point" to the vision they are allowed to see. As defined above, terrain is meaningless as a line, and would provide no blocking at all.

Feature Requests (FR)
Please note that we are focused primarily on getting a system out the door for all the functionality, not just the image handling or map creation features. So, we are not focused on feature requests at this point. There's just too much to do to prioritize feature requests with the team we have right now. So, I will be adding tickets for feature requests, but it will be quite some time before feature requests are prioritized. Most likely, we won't even start looking at stuff like that until next year, especially for things that can be accomplished already but take a few more steps.

FR: Changing Blocker Type
This can be done by deleting the blocker with the wrong type, and redrawing a blocker with the new type. I appreciate the additional information clarifying what you were asking for; and have added as a feature request.

FR: Spacebar
Keyboard access is a high priority for Doug, and it can make creating content much easier for someone familiar with the keys. Also, it is much faster and more precise to use a mouse and keyboard combo; because pressing a mouse button can cause the mouse to move slightly for many people (it does for me.).

Also, the spacebar is overloaded in so many different application types that there is no "standard" that I see when reviewing various software documentation. I've actually seen it used for panning in image applications much more than for default selection state toggling. Please don't get hung up on the exact key combinations. The main ask that I'm taking away is that you'd like shortcut keys for toggling between tools (selection, line, square, circle). I've added that feature request to our system.

FR: Resizable LOS shapes
Thanks for the clarification on this. At this point, we are suggesting that you move the points to fit the shape you want after initial circle drawn. I'll add this as a feature request.

FR: Continuing blocker draw
I'll add as a feature request. You can accomplish this today by dragging the points into new positions, creating intersection points as noted above, or just appending to what you have so far.

Also, this is another advantage of using the spacebar method above. The blocker doesn't complete until you double-click or press Enter.

FR: Horizontal/vertical lines
The Shift key already performs the operation to force rectangles to squares and ellipses to circles. I just tested, and this is working as intended.

We have been internally talking about adding the ability to allow forced horizontal/vertical walls already; and it's filed as a feature request. However, the Shift key is already used as a modifier to "close" a wall/secret occluder as a polygon; so we'll need to figure out whether to remap one or the other.

Terrain Suggestions
I appreciate the write-up you made; but we're probably not going to change terrain drastically at this point.

Besides the fact that a major design change would introduce potential and unknown complications, the terrain option you suggest (one-way blockers) requires another level of UI to identify the one-way direction of the blocker as well as UI to be able to change the direction. Internally, the winding order of the points determines the one-way-ness of a blocker, which means that changing directions means data must be re-ordered and recalculated, which introduces more code complexity.

I'm not convinced that adding yet another dimension to blockers (one-way vs. two-way) is a simpler UI paradigm. While it fits everything into more efficient buckets of features, it requires the user to understand concepts that may not be natural to their way of thinking (like us engineers). The concept of "wall", "door", "terrain" and "secret" are more likely to resonate with an average non-technical user.

We'll definitely keep this in mind, because I definitely like efficiencies like this; but as I mentioned, it's not something we want to take on at this point. A design change of this magnitude could push back release by several weeks to a month, and might require every map done so far to be redone (depending on what is needed).

Regards,
JPG

[Moon Wizard]

Another point I just thought of is that the terrain regions are more complex than you think. Simple one-way walls would immediately block LOS once you passed them, which doesn't give the effect we wanted. When you are within a terrain region, that region does not block LOS at all. When you are outside the terrain region, then you can see into, but not through the region. This is more complex than a simple one-way wall region.

This model was arrived at after working on many maps, and coming up with a solution that handled common elements we came across (trees, barrels, bags, rubble, etc.).

Regards,
JPG

[Guoccamole]

Dear JPG:

Your responses do not seem to be in the same order as my comments, nor in numeric order. Please keep the reference numbers to ease replying (or quote my text) as I do for you. I apologize if I get the context wrong for some of your replies as I have tried to reconnect your replies with their respective numbered comments.

Apologies for being blunt, but neither of us has oodles of time.

Now, thanks for all the issues resolved and filed, and also some comments as appropriate.

3)

Style Guide
I understand you want something now for the style guide. I'll mention to Doug again. However, as we have mentioned before, we only have a handful of people to work on this project, and we're trying to get a release out the door. Also, this is a bit of a moving target, since some of the stuff we suggest is being driven by what you guys are finding. We're doing our best, and we'll try to get something out soon.


To be clear, I am not asking for myself. I am asking because FGU users would benefit from it, including the wave of beta users who are imminent. You would probably benefit from a mapping FAQ by not having to field as many questions.

So “my” FAQ suggestion is more on behalf of FGU + beta community, not myself.

5)


Screen capture
I use a tool called Screencast-o-Matic to capture videos of issues (MP4). It also does animated GIFs, but those are much larger than MP4s, so those are better for us to be able to reference in our bug tracking system. There are a few tools out there you can try that do partial screen capture, if you want to explore one that works for you.


√ Screencast-o-Matic. TY
For everyone’s information, while researching Screencast-o-Matic, I also just found a Windows 10 built-in which seems to work for screencasting (games):
https://www.nextofwindows.com/windows-10-screen-recorder

If I come across “selecting terrain option and laying down some terrain results in wall terrain” again, I shall take a screencast capture.

8, 4, 7)


Dangling lines
Filed as issue FGU-528.

Multiple LOS selected point deletion
Thanks for clarification. Filed as issue FGU-530.

Point selection cleared on move
Filed as issue FGU-532.


3x TY!

9)


Terrain lines not sliceable
I'm not able to recreate this. If I draw a terrain polygon, then I draw another wall blocker through one or more lines of the polygon; then intersection points are created. You can then remove the blocker you used to create the intersection points. While this isn't an optimal workflow and we've talked internally about eventually adding a "cut" type of tool, it is something that can be done today per Doug's videos.


If I catch this happening again, I shall screencast capture it.

10)


Snapping between blocker types
I'm not seeing this. Snapping is defined specifically to work on points, not on shapes. When I just tested, I was able to get the points to specific points added to snap to the nearest points already defined. Are you seeing something different? Or referring to a different capability than just point snapping on addition?


I am referring to simple capability, snapping to existing points. If I come across it again, I shall screencast capture it.

11)


Polygon corners
Filed as issue FGU-533.


TY!
12, 13)


Feature Requests (FR)
Please note that we are focused primarily on getting a system out the door for all the functionality, not just the image handling or map creation features. So, we are not focused on feature requests at this point. There's just too much to do to prioritize feature requests with the team we have right now. So, I will be adding tickets for feature requests, but it will be quite some time before feature requests are prioritized. Most likely, we won't even start looking at stuff like that until next year, especially for things that can be accomplished already but take a few more steps.


Understood. That’s why I triaged issues into pressing and the rest, and identified their nature, though some feature requests are very low hanging fruit (so perhaps not inappropriate for some TLC to support early users).

1)


FR: Changing Blocker Type
This can be done by deleting the blocker with the wrong type, and redrawing a blocker with the new type. I appreciate the additional information clarifying what you were asking for; and have added as a feature request.


Yes, total rework as workaround. Understood. TY for adding feature request.

2)


FR: Spacebar
Keyboard access is a high priority for Doug, and it can make creating content much easier for someone familiar with the keys. Also, it is much faster and more precise to use a mouse and keyboard combo; because pressing a mouse button can cause the mouse to move slightly for many people (it does for me.).

Also, the spacebar is overloaded in so many different application types that there is no "standard" that I see when reviewing various software documentation. I've actually seen it used for panning in image applications much more than for default selection state toggling. Please don't get hung up on the exact key combinations. The main ask that I'm taking away is that you'd like shortcut keys for toggling between tools (selection, line, square, circle). I've added that feature request to our system.


That feature request sounds strong. However, my first priority request really rests specifically with the selection/pointer tool since that’s the one that is generally invaluable while map-making.

6)


FR: Resizable LOS shapes
Thanks for the clarification on this. At this point, we are suggesting that you move the points to fit the shape you want after initial circle drawn. I'll add this as a feature request.


TY for feature request. (Other workaround is undo + rework.)

6?)


FR: Continuing blocker draw
I'll add as a feature request. You can accomplish this today by dragging the points into new positions, creating intersection points as noted above, or just appending to what you have so far.

Also, this is another advantage of using the spacebar method above. The blocker doesn't complete until you double-click or press Enter.


Space bar FTW! TY for adding feature request.

13)


FR: Horizontal/vertical lines
The Shift key already performs the operation to force rectangles to squares and ellipses to circles. I just tested, and this is working as intended.

We have been internally talking about adding the ability to allow forced horizontal/vertical walls already; and it's filed as a feature request. However, the Shift key is already used as a modifier to "close" a wall/secret occluder as a polygon; so we'll need to figure out whether to remap one or the other.


I shall have to try this use of SHIFT key out! That may provide a solution to #11 (closing squares).

Once again, I run into post limit of 10K. Annoying. Conclusion (window terrain) in next post.

[Guoccamole]

And IMO, my most valuable alpha tip.



Terrain as lines
As I mentioned in the other thread, terrain is defined by us as a region into which a token can see, but can not see outside of. Therefore, terrain must be a polygon, or there is no "end point" to the vision they are allowed to see. As defined above, terrain is meaningless as a line, and would provide no blocking at all.


Rubble was the first ‘Terrain’ example provided (in one of Doug’s early FGU videos). Rubble does not fit the definition you give (as I understand it). In any case, IMO, that’s a very narrow definition of Terrain... which is being used for common cases.

And that’s where I think we are at cross-purposes. After converting many large maps for “Hoard of the Dragon Queen”, I was informed that the current terrain works very narrowly. I already had figured out what I needed generally. So I’ve recommended that more general feature... since many maps will be getting converted RSN.



[some bolding added by Guoccamole]
Terrain Suggestions
I appreciate the write-up you made; but we're [1] probably not going to change terrain drastically at this point.

Besides the fact that a major design change would introduce potential and unknown complications, the terrain option you suggest (one-way blockers) [2] requires another level of UI to identify the one-way direction of the blocker as well as UI to be able to change the direction. Internally, the winding order of the points determines the one-way-ness of a blocker, which means that changing directions means data must be re-ordered and recalculated, which introduces more code complexity.

I'm not convinced that adding yet another dimension to blockers (one-way vs. two-way) is a simpler UI paradigm. While it fits everything into more efficient buckets of features, it requires the user to understand concepts that may not be natural to their way of thinking (like us engineers). [3] The concept of "wall", "door", "terrain" and "secret" are more likely to resonate with an average non-technical user.

We'll definitely keep this in mind, because I definitely like efficiencies like this; but as I mentioned, it's not something we want to take on at this point. [4] A design change of this magnitude could push back release by several weeks to a month, and might require every map done so far to be redone (depending on what is needed).


TY for sharing your observations in such detail.

[2] another level of UI: Yes, I mentioned as much up-front. Though, the UI you have to select terrain would already provide the hook + place you need for terrain configuration. So I don’t view the UI requirement as all the much of a technical stumbling block.

[3] average non-technical user resonate w/ "wall", "door", "terrain" and "secret": OK, then do the usual hiding behind the buttons. However, the ‘window boundary’ approach provides basic elements which will support much more than just the dungeon boundaries and could support one-way windows, etc., which are common modern day. The code on the inside would be simpler. And down the road, you could expose some of that with a ‘Terrain Designer’ for advanced FGU users... creating new types of terrain for FGU.

[4] design change: Yes, that and the map rework problem are why I mention this recommendation is probably more valuable. In my experience, the current terrain approach has narrow application. The simpler ‘window boundary’ approach is an 80% solution, simpler to implement and debug. Right now, I found myself using the ‘Terrain’ for common problems and found it bizarre and overcomplicated. When all I need is a boundary, why bother with area? And neighboring boundaries break the area model (as Doug’s recent terrain video demonstrated: https://www.youtube.com/watch?v=dpaUojfIFCw). As I keep mentioning, the area model does not work for general terrain.

[1] probably not:
Let’s try to solve the 80% problem.
FGU is about to get a lot more users (testers). I’d suggest solving an important 80% problem ASAP. I have tried to provide a solution, but I shall stop trying if this alpha suggestion fails to land.



[inserted from next post]
Another point I just thought of is that the terrain regions are more complex than you think. Simple one-way walls would immediately block LOS once you passed them, which doesn't give the effect we wanted. When you are within a terrain region, that region does not block LOS at all. When you are outside the terrain region, then you can see into, but not through the region. This is more complex than a simple one-way wall region.

This model was arrived at after working on many maps, and coming up with a solution that handled common elements we came across (trees, barrels, bags, rubble, etc.).


I have worked on enough maps “Hoard of the Dragon Queen” to know that this solution does not apply to common cases. As you say, it’s more complex and does not work as I expect. That behavior does not solve 80% solution, and does not pass the no-surprises test.

Hence, my suggestion for a simpler, more general approach (and definition, I guess) for Terrain. Solve the common ledge, platform, cliff problem. Solve the window problem. None of these need area as a parameter, just an edge.

[I don’t have anything against *an* area solution, but it’s a narrow case. E.g., a hill... define an area as a hill, and then add a point in the middle of the hill. Tokens can only see “their” half of the hill. Makes for a very dynamic, realistic view port onto the hill. Area is key to defining hill. Or... E.g., an area as a trigger for vision... to see a tunnel/bridge from one direction but not another. I have come across this case in 2.5D maps I needed to convert. But those are one-offs... narrow cases. So, yes, area is cool, complex, and desirable... but not IMO a first-priority feature.]

The first priority feature I recommend is (IMO) proper general purpose terrain which you can implement with ‘window boundary’ model quite simply, hidden behind common terrain buttons as you wish ("wall", "door", "terrain" and "secret").

’Window boundary’ terrain is my biggest and strongest alpha user contribution. But I shall stop recommending if it is already too late to make such a change (though I obviously disagree; I think a more effective terrain model essential to mapping which is why I’ve recommended it over and above bothering to debug area terrain at this point). If a general terrain solution has merit, then FGU users deserve it (IMO) regardless of the work required. If that same solution saves support headaches, the SmiteWorks programming team deserves it (IMO). And if a change to terrain map tooling could require rework of maps, then then map-makers deserve that (those?) key changes earlier, not later. IMO.

The key question I pose is whether a more general Terrain definition and solution has merit (compared to the current narrowly defined area solution). I believe it does, but I leave it to you (JPG and team) to make the final decision.

Guoc out.

[Kelrugem]

Personally, I think a lot of your issues can already been done in one or another way with the terrain feature when one remembers that the terrain feature can be opened and closed. E.g. the boundary problem you refer to (one of Doug's videos) can be solved with that, simply open the terrain when you want to determine the vision of someone who can see through the whole terrain (when I remember it correctly then Doug even mentioned this in the video) :) Simply think about the vision of the group as a whole: When some player is "far enough" and getting this boundary problem, then simply open this terrain for the most of the time. As far as I know the players share their vision now and so there should be no problem (and you still can close the terrain if you need it). Of course this needs some manual work. When you are worrying about that players may accidentally see hidden NPCs because you wanted to determine the vision of one of your NPCs by opening the terrain, then I have to say that I personally think that the LoS system is especially for player visions, NPC visions may have still to be determined manually for specific situations (depending on the context) which is absolutely no problem because only the GM controls them and the GM has global vision. Since the players don't have global vision of course, they need some automated help (w/ or w/o some manual help of the GM) and that's for me personally the purpose of the whole LoS system :) (and you still have things like FoW and token invisibility and so on to play with, helping you to hide NPCs etc.)

I also have the feeling that you sometimes may not see the use of terrain. I do not see any problem with cliffs for example. For simplicity assume we are now only using rectangles for terrain and the cliff goes from north to south. Then the height of the rectangle is given by the length of the cliff/chasm and the width is given by the size of your "trigger zone". Then put the rectangle solely on the top side of the cliff. Then everyone at the bottom of the cliff can see a bit the top but never through it because they can not enter the rectangle (since it lies solely at the top). While people at the top can then see everything of the bottom when they are near enough the cliff :)

Being a mathematician and physicist in real life, it can be a vicious circle to simulate now everything, you do not really have something like this in actual science (not even completely in theory, strictly speaking...). I know that you do not ask for everything been simulated, just wanted to point out the difficulty of optical systems and their simulation. Especially because we're speaking about 2D maps :) And especially optical systems are in danger of getting serious performance problems which FGU had at the beginning (and still may have, depending on one's computer, but that is being worked on :) ), or look at Roll20 whose visual system has serious performance problems since months (and always had, I am glad that I do not use it anymore, I didn't see getting the value of my sub due to this when I was still using Roll20; to their defence: This of course also depends on one's personal setup). Adding new features can cause serious new performance issues

In one point I can completely confirm your statement: There is the danger that actual maps with done LoS may be outdated in the future due to new features (which hopefully come! :) ). But you always have this problem, already now, just look at old modules of FG. I have the complete SRD for 3.5e from the store and you can not really use the NPC data there without some manual adjustments because these datas where from some "older times". (I still like to use it due to the nice library informations of the rules which I can link everywhere and due to having all dragon types for all ages) Of course it is then better to have the new features earlier than later but Moon Wizard already said that new features would now delay the release which Smiteworks want to avoid and I completely understand that.

(and I of course understand you, too, having a semi-permeable wall is also a nice feature)

[Guoccamole]

@Kelrugem: While I agree with your general statements (except perhaps the manual labor suggestion, since, e.g., FGC has that with manual unhiding!), your post changes the scope of discussion and therefore ignores some pressing issues. Perhaps you are smoothing differences to bridge divide? OK.

BTW, I probably did use some of the creative ‘Terrain’ techniques to convert “Hoard of the Dragon Queen” maps, so good on you. However, I feel like those are hackish in nature, since they really don’t use area but, rather, just the directionality of the current ‘Terrain’ feature. And now accepted practice seems to be that ‘area’ is important to specify even though it creates problems. So I feel the current system is inherently complex, error-prone, brittle, and much more appropriate to solve problems where ‘area’ specifically adds value. Otherwise, it just gets confusing (to me).

The cliff example you describe is an illustrative one though, and gave me another wrinkle for how to handle LOS. Instead of the 5’ trigger length default, make the default be the height (or altitude, if we are thinking more generally) of the creature/character. We are used to humans who are all about... 5-6’ tall. But a giant on a cliff would see the majority of the lower terrain earlier... because they’re taller. So creature height would be nice built-in default for default LOS trigger... which FGU could handle automatically (new system). No area required.

[Kelrugem]

@Kelrugem: While I agree with your general statements (except perhaps the manual labor suggestion, since, e.g., FGC has that with manual unhiding!), your post changes the scope of discussion and therefore ignores some pressing issues. Perhaps you are smoothing differences to bridge divide? OK.

BTW, I probably did use some of the creative ‘Terrain’ techniques to convert “Hoard of the Dragon Queen” maps, so good on you. However, I feel like those are hackish in nature, since they really don’t use area but, rather, just the directionality of the current ‘Terrain’ feature. And now accepted practice seems to be that ‘area’ is important to specify even though it creates problems. So I feel the current system is inherently complex, error-prone, brittle, and much more appropriate to solve problems where ‘area’ specifically adds value. Otherwise, it just gets confusing (to me).

The cliff example you describe is an illustrative one though, and gave me another wrinkle for how to handle LOS. Instead of the 5’ trigger length default, make the default be the height (or altitude, if we are thinking more generally) of the creature/character. We are used to humans who are all about... 5-6’ tall. But a giant on a cliff would see the majority of the lower terrain earlier... because they’re taller. So creature height would be nice built-in default for default LOS trigger... which FGU could handle automatically (new system). No area required.

About manual labor: Yeah, just wanted to say that it will still not be fully automated :) And yes, I tried to see if one can not already accomplish your wanted features in sense of "your feature is just a special case of the existing more complex one"

Hm, yes, one has to think a little bit when putting terrain. One has to think about when can I see what? :) Heights of tokens has to be done manually (opening/closing the terrain) but the height of terrain can already be simulated now :) Probably you already have seen that because you mentioned hills, but you can put up the boundaries of the terrain areas similarly as the lines of constant niveau/height as on hand-drawn geographic maps. Then you get a nice 3D effect after you defined which steps of height-jumps you get by going from one boundary to the next :)

Hm, maybe one can think of the boundary of terrains as these lines of constant height for obstacles with a height high enough to block vision of some tokens (maybe in some interval around some specific height value)? (But only for obstacles with "bounded size in the plane" because there is also this cliff example which may not decrease on the other side anymore after one climbed it. There you have the effect of that you simulate that someone can not see below the cliff when one is too far away. So terrain-LoS seems to be a mixture with that, taking height and the angle of the vision of the token's top to the plane into account. Hm, I have to think about that (and about how to formulate that better, is probably confusing now :D))

Height of tokens is complicated and was sometimes discussed here in the forums. I am not sure whether it is worth the issue to simulate token heights on 2D maps, it needs more data and you have to think about some things. Maybe it is then better to go already to 2.5D or even 3D? I am not sure :)

[Guoccamole]

My focus is best way to provide simple (to FGU mapmaker) LOS in 2.5D world. I assume focus of SmiteWorks is converting their existing content to FGU, and all the existing content is 2D (which means in some cases 2.5D, as with several maps of “Hoard of the Dragon Queen”). I personally think it’s really cool seeing artists ‘cheats’ to add 3D in 2D world. It was fun seeing how we use maps without second thought, but which technically don’t ‘fit’ in 2D. Of course, then it would be nice as map-converter and GM to handle those map elements seamlessly in FGU. But that’s a discussion for another day as those features are niche compared to simple LOS.

[Kelrugem]

My focus is best way to provide simple (to FGU mapmaker) LOS in 2.5D world. I assume focus of SmiteWorks is converting their existing content to FGU, and all the existing content is 2D (which means in some cases 2.5D, as with several maps of “Hoard of the Dragon Queen”). I personally think it’s really cool seeing artists ‘cheats’ to add 3D in 2D world. It was fun seeing how we use maps without second thought, but which technically don’t ‘fit’ in 2D. Of course, then it would be nice as map-converter and GM to handle those map elements seamlessly in FGU. But that’s a discussion for another day as those features are niche compared to simple LOS.

Yup, surely something one can discuss about for a long time :D It's interesting for sure :)

[Zacchaeus]

So it's probably just me but I can't really get my head around what the issue is here. So here's a couple of images. In the first the creature is below the first contour and therefore can't see the terrain above it. In the second the creature has moved onto the top of the contour and the next one is now blocking LoS and the bit below although revealed cannot be seen through. So what is the issue with this?

[Kelrugem]

In very short essence basically this: (so, he finds the UI and the way how terrain works unintuitive and not the best for LoS mappers and sometimes the boundary of terrain blocks vision while one may still see things behind that (depending on the shape), therefore I mentioned that one can then open the terrain if needed. Roughly)


BTW, I probably did use some of the creative ‘Terrain’ techniques to convert “Hoard of the Dragon Queen” maps, so good on you. However, I feel like those are hackish in nature, since they really don’t use area but, rather, just the directionality of the current ‘Terrain’ feature. And now accepted practice seems to be that ‘area’ is important to specify even though it creates problems. So I feel the current system is inherently complex, error-prone, brittle, and much more appropriate to solve problems where ‘area’ specifically adds value. Otherwise, it just gets confusing (to me).

[Kelrugem]

Sometimes the boundary of terrain blocks vision while one may still see things behind that (depending on the shape), therefore I mentioned that one can then open the terrain if needed

For reference for this: https://www.youtube.com/watch?v=dpaUojfIFCw

Around 1:46 you can see that the sight of the chosen token can not see the rest of the plateu on the right side though the token should be able to see it. I guess that is what Guoccamole is referring to, too :) (he probably doesn't like it to have to open the terrain then manually, like one also has to do it when one wants to allow vision to the lower plane) (Guoccamole, correct me when you meant some other thing :) )

[Guoccamole]

@Kelrugem: Thank you for answering with some examples. Yes, those are good explanations and examples. TY also for linking the Terrain demo video for good examples.

@Zacchaeus: I would describe the basic problem as unnecessary complexity (not just in code but) in UX. Another good example in the Terrain demo (https://www.youtube.com/watch?v=dpaUojfIFCw) is at the 5min mark where Doug suggests that he could refactor the Terrain of the map to address some unintended visibility issues. The refactoring simply creates different unintended visibility issues. This refactoring catch-22 is a sign that this approach is not smooth sailing (and may be unduly complex).

After doing some mapping of my own, I realized the catch-22 could be resolved by simplifying, doing away with the unnecessary parameter, area, attached to the current FGU-alpha definition/approach/implementation of ‘Terrain’. So I suggested distilling the LOS Terrain to its bare essentials for a solid (less problematic) 80% solution: line-based terrain.

In short, I’d prefer a solution which matches the problem and not one that creates catch-22’s and its own issues. I also believe the undue complexity causes UX surprises, as explored in Doug’s video refactoring... such as the unintended visibility issues. My suggested approach is simple, straightforward, (and could even be used as a building block to build back up to area triggered effects). I believe the simpler, more direct solution would benefit the FGU community, specifically the mappers and map converters, and ultimately SmiteWorks.

Alas, there is no time since some maps have been converted to the FGU-alpha system. However, I bet there are even more maps which have *not* been converted, so the tail may be wagging the dog.

Actually, the key issue may be just getting the Terrain working properly to make FGU the best it can be with rich 2.5D maps, and a rich (but simple and sensible, surprise-free) map language for providing best UX experience for mappers, GMs, and players. An overly complex system which hobbles mapping is an impediment to optimal FGU and mapper/players UX. And if you can’t fix Terrain during FGU playtest, not even during alpha phase of FGU playtest, *and* existing (alpha phase) converted maps result in lock-in, then when could you even playtest (much less fix) such an issue?

Sometimes people need to slow down to speed up. IMO, FGU Terrain may be such a time.

[Bidmaron]

’Window boundary’ terrain is my biggest and strongest alpha user contribution. But I shall stop recommending if it is already too late to make such a change (though I obviously disagree; I think a more effective terrain model essential to mapping which is why I’ve recommended it over and above bothering to debug area terrain at this point). If a general terrain solution has merit, then FGU users deserve it (IMO) regardless of the work required. If that same solution saves support headaches, the SmiteWorks programming team deserves it (IMO). And if a change to terrain map tooling could require rework of maps, then then map-makers deserve that (those?) key changes earlier, not later. IMO.

The key question I pose is whether a more general Terrain definition and solution has merit (compared to the current narrowly defined area solution). I believe it does, but I leave it to you (JPG and team) to make the final decision.

Guoc out.
Guoc, I know you have the best of intent, but you have made your point, sir, and you may note from the absence of response from MW or anyone from SW that they are politely hoping you follow your highlighted promise. SW has set the release date for the beta, and they are not going to delay that date to pursue what you have emphatically, repeatedly suggested/requested. Quite respectfully, sir, I request you follow your earlier promise and drop it, at least for now.

Or keep going, whatever you prefer (and I am enjoying the technical details). MW has already spoken and politely tried to say that they aren't doing what you are suggesting at this time. I think it's time to move on, but do what you will.... I am just concerned that you have a lot to offer with your background and experience, but if you keep beating the bloody horse, people may stop paying attention when you move on to the donkey.

[Guoccamole]

[Off Topic]

@Bidmaron: Everyone has been polite so far. As for “MW or anyone from SW” responding, it took quite some time just to connect the dots on MW’s most recent message, so I’d be disappointed if he didn’t at least acknowledge the post. He also took some time to respond previously. In a recent post, he also said he just skims certain threads. So, he’s pretty much allowed wildcard behavior for his replies.

However, to your point, I have seen him post elsewhere since my reply to him, so maybe you’re right... my last reply could be left dangling.

OTOH, we’re still in alpha where (in theory) fixes would happen, concerns would be addressed, FGU would improve. I don’t think MW or SW would delay beta at this point, but that’s not necessary to make changes ASAP. SW would just need to... decide to make changes, warn map converters, bite the bullet, and make happen. So I think you’re jumping to conclusions about beta cutting off refactoring (but that’s a guess; perhaps you have better feel for SW than I do).

As for your highlight, implying I am breaking my self-imposed agreement (third try, and out), you are reaching to imply that’s a general gag order. There’s no gag order, and (to be perfectly frank) I don’t like the insinuation that I wouldn’t keep my promise.

In other words, as (polite) questions and posts arise from other quarters (than MW/SW), I reserve the right to respond, confirm, clarify, what-not. I also wonder whether MW/SW even hopes others will tease out more information while they weigh their options? Until MW/SW responds, who knows? Or time will tell with silence.

But if MW/SW comes back with another deflection, then so be it.

PS: Finally, if I’m already being stonewalled, then your “I am just concerned that you have a lot to offer with your background and experience, but if you keep beating the bloody horse, people may stop paying attention when you move on to the donkey.” is not much of a concern since... if stonewall silence is the “fix” for my suggestion(s) and is already in (as you surmise), then the wall is already up. Then there’s really nothing more to be concerned about as the wall (or “fix”) will already be in. Done deal. Too late.

[Guoccamole]

if you keep beating the bloody horse, people may stop paying attention when you move on to the donkey.

Apparently some horses are worth beating, even if the horse is long dead by the time it finds its legs. And, yes, @Bidmaron, you were correct as I was soundly ignored in alpha and beyond after your post... even if the issue had legs.

FYI, FGU KS Update #35: https://www.kickstarter.com/projects/smiteworks/fantasy-grounds-unity/posts/2981343