FGU: Functionality

[snupy]

Some time ago I started a thread (https://www.fantasygrounds.com/forums/showthread.php?80186-FGU-The-interface) on the FGU interface which lead to some interesting discussions. I am now trying to do the same but with a focus on functionality. While this website (https://www.fantasygrounds.com/featurerequests) is available for features suggestions, a thread seems more indicated for extended discussions. I am going to make four points, as well as a plea (in the post below this one) for something I had already advocated for in the other thread.

1. Doing more with distance and speed. FG can calculate distance from a point in the map, and is aware of PCs/NPCs speeds. However nothing seems to be done with the speed data. It would be really useful if FG could color code or something similar movement on the map according to the available speed, like here (https://foundryvtt.com/packages/drag-ruler/). A possible color coding in PFRPG would be green for a single move action, yellow for twice the speed (move + standard), red for any further than that. The color coding should just be informative and not actually prevent token movement - for example in PFRPG you can decide to be running for the whole round, giving you 3x or 4x the speed.

This feature would be particularly useful to GMs, who have to move a large number of monsters and NPCs all having possibly different speeds. But it would also benefit players, who tend to forget about encumbrance or more complex movement rules. While the specific colouring would depend on the ruleset, the feature itself would be useful in most or all of them.

More advanced incarnations could offer a drop down menu to select a specific speed (normal, fly, burrow, etc) before moving the token, or take into account map areas denoted as difficult terrain.

2. More automation. When I was researching which VTT to use, FG was (almost) always listed as the one with the best automation, at least out of the box. That may well be (or used to be) true, I have never made an extensive comparison, but when I first tried it with PFRPG I was disappointed: not very much (class features, spells, feats) is automated out of the box. In fact, I found other threads with similar complaints. I was still happy enough to stick around, and community modules are largely to be thanked for that. But I think FG should capitalize on its fame, and improve out of the box support for ruleset automation (I mean with already coded effects, I know I can write them myself). As a lot of it has been done already by the community, I think it would make a lot of sense to see if an agreement with the community developers can be reached so that their work can be included in the appropriate FG ruleset rather than duplicating it from scratch. Extending the effect coding possibilities would also be welcome, and again this is already done in some available extensions.

Side note: I think that the amount of automation included in sold modules should be made much clearer. It seems natural to think that a paid module will expand functionality, while this is almost never the case. I know that now (well, it's been a while), but I was not happy when I first discovered it, and again I found that I was not the only one to be disappointed. The module description (at least for PFRPG) is a fairly generic blurb which really does not make this clear. I think that at a minimum the general description should include a line to the effect that the module does not add any new functionality. In fact, I think that the module description should specify which effect coding has been added, if any. In comparison, the description in the syrinscape module is very honest.

3. Triggers/events associated to fixed or moving areas in the map. Kind of building on 1, the possibility of denoting fixed or moving (associated to a token) areas on the map, and associate to them an event in response to some trigger. Fixed areas could be used for traps or environmental hazards - in fact the pit terrain is a rather specific case of what I am describing. However, it would be great if you could use more complex triggers and events, which apply effects to token, roll dice, and support if/then constructions and boolean logic. For example, if any character enters a specific square (trap) it triggers a spell which means it plays an animation (I wish) and a save roll is automatically triggered, or things like that. Moving areas could be used for things like auras, attacks of opportunity, flanking detection.

4. While I am dreaming, a natural extension of 2 would be the availability of a large number of triggers, e.g. entering an area, attacking, dealing damage… and associated events, like playing an animation, displaying a dialogue, applying an effect, rolling something, all supported by robust coding possibilities for the final user.

Now, I am aware 3, 4 are very complex, and not far at all from being a full implementation of the coding needed for a computer game. I certainly would expect them to be implemented very gradually over a long period of time. Perhaps some discussion here could help isolating reasonable requests/features, and identifying ways to implement them.

Also, functionality of this kind often draws critique on the basis of moving too much into computer game territory. I think this is a serious point, but I suggest it is discussed in a separate thread.

[snupy]

In the FG interface thread I advocated for a certain way of dealing with the duplication of, say, items which happens when loading several modules. As I still think it is a good idea, which applies rather generally, is backward compatible and could be implemented for the most part with relatively little effort, let me go over it again.

For simplicity, I will refer to items, but it applies to all other record types (classes, spells…). For each ruleset there is a master list for items, associating to each item a unique identifier. Importantly, this list is in the ruleset, not in one or many of the modules. If the module needs a longsword, ID 31, it calls for ID 31 from the master list when loaded (and probably copies the corresponding item from the master list but I am not very knowledgeable about FG inner workings). To preserve the ability to filter items by module, one extra data should be associated to "loaded" items: a list corresponding to all the modules which requested it. So you'd have something like loaded items: ID 31, [all the data of the corresponding to ID 31], {requested by: "Core rulebook", "Ultimate equipment", "Burnt offerings"}. When looking at the items record list, if no group is selected each unique id is only listed once, and "Multiple modules" displayed as the source on the right. If a module is selected only the items it calls are shown.

Advantages:

- Avoids duplications of code/text as each item, class, etc needs to be entered only once.
- Consequently, makes fixes or the addition of new features (say adding the coding of effects for a spell as I advocated for in 2) much easier as only one instance needs to be changed.
- In the case of modules fully developed with this system, solves the duplication of entries problem while preserving the ability too filter results by module.
- Backward compatible: the master list can happily coexist with a list of items within the module as done so far (of course it would not fix duplication of entries in this case).
- The new system would benefit all rule systems.
- In many cases, most of the advantages can be obtained by switching to the new system for a restricted number of books/modules. For example in PFRPG most items are in Ultimate Equipment, and items in secondary splatbooks but not in UE are unlikely to cause duplication issues.
- Creation of data for new modules within the new system is at least as fast as it was before (if say copying an item from UE was the method used), or much faster (if entering the item from scratch).
- For new modules, as far as I can see the system brings only advantages. Conversion of key older modules perhaps could be offloaded to the community by offering some incentive as it is currently done for the addition of LOS to maps. In any case conversion is not needed.

Now, the existence of a master list within the ruleset potentially means that its content is available to everyone, without having to purchase any specific module. Honestly, I think that people purchasing modules for the most part do so to support SmiteWorks and/or the RPG creator, and would still buy the module, but if this is a concern I suppose master lists could be encrypted.

[Zacchaeus]

As regards your second post, whilst a ruleset cannot be copyrighted everything else can. So including stuff in the ruleset which is copyright isn’t an option. Apart from that community developers who convert books into modules don’t have access to the ruleset in order to add anything into it (and I’m pretty sure the developers wouldn’t want them to be able to do that anyway - it would be really impractical to have several people all adding in stuff at the same time). I can see where you are coming from as regards duplicates but it is unavoidable and there are filters which somewhat mitigate that.

[Nylanfs]

And to follow up, the FG data isn't all in a database so that the ID numbers could be called by other modules.

[snupy]

And to follow up, the FG data isn't all in a database so that the ID numbers could be called by other modules.

Sorry but I don't understand what you mean.

[LordEntrails]

I like the ideas around distance and speed and even to some extent the movement triggers. Distance I would put higher on the list, but neither of them would be in my top 50 improvements. But, I hope you put them on the Feature Request list so others can voice their opinions with votes.

About More Automation, well when you look at PFRPG ruleset you need to keep something in mind, (unless I'm reading the Paizo website wrong) its an obsolete ruleset. I don't mean that in terms that people don't play, but all new product from Paizo is PF2E or Starfinder. Given that, I doubt it makes financial sense for FG to implement any new functionality in that ruleset. Realistically (from a business perspective), any automation needs to be justified for D&D 5E, and then ported to other rulesets via CoreRPG when (again) it makes financial sense. Not that such isn't possibly a good decision, but I think the financials needs to be considered and the realization that its only going to happen if it makes sense for the biggest ruleset.

To the sidenote, Perhaps more details on what automation is included should be detailed on the store page, but in general I know to assume zero unless the store page says that the product actually includes an extension. Because w/o an extension, a product can't change the ruleset code. But the 30 day policy is, imo, a better approach. Because whatever words are chosen, they are never going to be perfect. Being able to buy, try, and return is always going to be superior.

As for the 4th idea, about advanced automation. There is actually a lot of resistance to that from many GMs. Simply because they do not want to play a video game. But, I actually think it's inevitable to appear sooner or later. But this doesn't even top my top 100 list for improvements. And even if it were a goal adopted by the devs, would take years to get to that level. There are tons of foundational improvements that would be needed before we got there. Yes AAA games do this after a few years of development, with ~30 times the number of developers and a budget to go with it. We have to remember, we are in a very niche market.

I just don't see talking about it as particularly useful, it's so far down the roadmap and in the mists of uncertainty as to be practically useless because by the time FG gets close, technology will have completely changed and the current state of FG and VTTs will be vastly different than now. Perhaps the best approach would be to discuss a broad goal or approach to the VTT experience.

There is a ton of problems with the idea for removing duplicates. Many or most as previously discussed. Besides the fact that FG can not legally copy the text from numerous sources and make that available to the ruleset without purchase of the source, how do you handle When Item 10 from source ABC is mechanically the same as from Source EFG, but the text is slightly different? Who draws the line? Because if the text (or linked image, or...) isn't exactly the same, then who decides it's close enough? Or which one is the official one? Not that these things can't be solved, but really, what the value to the product? GMs often have multiple sources open, players don't to the same degree.

Now, I do see a couple of other ideas that would help with this without needing to determine which is unique and which is the master copy and would not incurring the huge cost of going back and editing old products.
A) Change the list filter behavior. Instead of All or One option we have now, enable check boxes for each list. This way you could display Source 1, 2, 5, & 8, but not 4, 6, & 7.
B) Enable the sources to be able to have a GM assigned priority. So that when two items have an identical name, only the one from the highest priority enabled (see idea A) source is displayed.

[Nick Frost]

Checking the "drag ruler" module for Foundry really made me miss the movement presentation from FG Classic. Simple lines and waypoints look so much nicer to me than the current token duplication + bold arrows. So yeah, I just made a feature request...

[claedawg]

I already have a request in the special place to add tracking of distance (although no mention of adding triggers to it or anything). Basically my idea was to make the current arrow/circle image that shows up when a player moves the character stay up and track the amount of distance moved between each point and the distance remaining until the character has completed its turn.

[JohnD]

Good to remember that Smiteworks has a 30-day money back policy if you decide any particular purchase just doesn't do it for you.

[snupy]

Thanks all for the comments.

@Zacchaeus I am not sure it is unavoidable. I was not aware of the legal difficulties, but all is needed is for IDs to be global and not internal to the module, could be e.g. an extra file which is encrypted instead of the ruleset. But ok, it may be too complicated to be worth implementing, and LordEntrails idea would help a lot with the duplication thing while being much easier to implement.

@LordEntrails nice to read your thoughts, I would be curious to read about you top wanted 5 or 10 features!
Re:automation
PFRPG is obsolete, but probably the second most played ruleset here, and one of the strong points of FG I believe? And as I wrote there are some great community resources, which hopefully could be integrated in the official product thus minimizing the amount of effort required.
Re: sidenote
sure, for a more experienced user it should be clear that modules essentially provide data, while extensions, well extend functionality. But that's not clear at all to a new user. Also I believe there are exceptions (advanced bestiary springs to mind), and in any case coding for effects is sort of a hybrid beast, as strictly speaking it does not extend functionality but merely provides already coded stuff, a bit like modules provide e.g. already entered items or NPCs. I think I remember a post with some developer writing that they try to include all reasonable effects when porting a product, and that's the kind of information which I think should be included.
Re: 4th idea. Fair enough it may be premature to talk about it. To be honest it's not clear to me how wide is the gap between 3 and 4, that is passing from a trigger which is location based (token enters a square) to more general ones, and/or how complicated would be different events (applying an effect vs rolling dice vs...) in response to a trigger to implement.
Re: duplicates. Ok, I am not convinced there is a tons of problems, but probably enough not to make it worth it, and I like what you suggest.

@JohnD I don't know if you are reminding me in particular, anyone who is reading, or both. As far as I am concerned, I am well aware. I genuinely think the description is inadequate, and I am not pointing it out because I am looking for a refund, but on behalf of new users. I don't think that having a refund policy (which I consider a bare minimum, and is legally required in many countries) means that descriptions can be inaccurate and it is the responsibility of the buyer to buy, test the product to see what really is contained, and in case ask for a refund. Now one may or may not agree with my take that the description is inadequate, but that is a different point.

[LordEntrails]

I don't disagree that new users often have difficulties learning all there is to learn about FG. But I'm also aware that most users (not just new ones) only absorb a tiny fraction of the info that is already presented for FG. It's one of the big challenges that Laerun and FG Academy try to help with. Perhaps more detail on the store pages would help, but it's also likely that a lot of users (who are less detail oriented than you) would either not bother reading or would be overwhelmed by more.

In a previous phase of my career I used to be a technical trainer. Teaching highly technical subjects to highly skilled people who were motivated. Even those folks could easily be overwhelmed :)

I'm not saying more info on the store pages isn't a good idea. I just don't know if it will help but for a few folks.

[Navigat0r]

Side note: I think that the amount of automation included in sold modules should be made much clearer. It seems natural to think that a paid module will expand functionality, while this is almost never the case. I know that now (well, it's been a while), but I was not happy when I first discovered it, and again I found that I was not the only one to be disappointed. The module description (at least for PFRPG) is a fairly generic blurb which really does not make this clear. I think that at a minimum the general description should include a line to the effect that the module does not add any new functionality. In fact, I think that the module description should specify which effect coding has been added, if any. In comparison, the description in the syrinscape module is very honest.


I would like to add my voice to Snupy's in this matter. IMO automation is one of the strong points of the Fantasy Grounds software. When researching VTTs online the out-of-box automation is one aspect that is frequently mentioned as a strength compared to FGU's competitors. Along with the "prep less, play more" tagline, I think it can create some expectations on the part of the customer that may or may not be realistic depending on the ruleset. In the case of 5e and PF2 both have quite good automation out of the box (learning to make use of it is another beast haha).

In my case, I decided to migrate from Roll20 after learning about the automation (the availability of official modules was another factor). So I took some of the items I got from a humble bundle and jumped in to using the software. With regards to the published modules, I was in fact able to "prep less, play more". The pre-placed enounters, ready to divide treasure bundles, shareable story entries and whatnot are great. However, the much-vaunted automation was not what I expected. Although the powerful FGU software is very /automateable/ in the case of my chosen ruleset (in this instance PFRPG, but i think many less popular rulesets will fit into this category) actually making use of the amazing capabilites of FGU requires a considerable amount of work on the GM's part to actually use.

To be clear, my post is not about FGU's ease of use (as I said before, that is another beast entirely). Of course, a tool as powerful as FGU is bound to be complicated. However, I agree with Snupy that making the state of automation clear would make for a better customer experience - especially when FGU has a strong reputation in that area. Hopefully that will translate to more people sticking with FGU when they have more realistic expectations and they know to what extent one of FGU's strongest selling points is implemented in their chosen game.

[MrDDT]

Throw my 2 cents in here, I'm not sure "MORE AUTOMATION" is what is needed, more likely ease of use. I think 2 things are the major issue why more are not coming to FGU before other VTTs (if they choose another VTT).

Ease of use.
Looks very old.


No other VTT comes close to the automation that FGU has and the things the OP is saying to have would mostly be moving away from TTRPG and more into just being close to a video game.

More automation you have the more limited scope of things you can say or do. FGU already has all those things you are asking to do, it's just not set up for you to 1 click and put it in.
I can set up traps and triggers. I can have attack rolls happen automatically when you get in range of something or trigger something. It's just not easy to set up with a simple click you need to think about it in a way of using effects and tools inside FGU.

[Nylanfs]

There were also the class effect xml imports that one could download that has the more common setups for that class on a sample char you could copy from. But I'm not sure where those are anymore.

[Griogre]

Unfortunately, most of them were lost :(

[deer_buster]

Throw my 2 cents in here, I'm not sure "MORE AUTOMATION" is what is needed, more likely ease of use. I think 2 things are the major issue why more are not coming to FGU before other VTTs (if they choose another VTT).

Ease of use.
Looks very old.


No other VTT comes close to the automation that FGU has and the things the OP is saying to have would mostly be moving away from TTRPG and more into just being close to a video game.

More automation you have the more limited scope of things you can say or do. FGU already has all those things you are asking to do, it's just not set up for you to 1 click and put it in.
I can set up traps and triggers. I can have attack rolls happen automatically when you get in range of something or trigger something. It's just not easy to set up with a simple click you need to think about it in a way of using effects and tools inside FGU.

As far as "Ease of use" goes... As a software developer of many, many years, I have come to the realization that developers are the WORST people to design things for others to use. We KNOW the intimate and intricate details on how the software we develop works, and so we are too close to the trees to see the forest. This is not a dig on any developers of Fantasy Grounds, but it is a generalization about all developers that, from my experience, has been 100% true with both myself and every other developer I have worked with.

Probably the best thing that Smiteworks could do, to fix "Ease of Use" and "Looks Very Old", would be to hire a competent UI/UX designer as well as put together a rotating UI/UX focus group of users that would get together with the UI/UX lead and discuss usability and design issues, suggestions, and feedback that really has nothing to do with features or rules or automation (per se) that can then be taken back to the developers to focus on for the next iterations.

[snupy]

Throw my 2 cents in here, I'm not sure "MORE AUTOMATION" is what is needed, more likely ease of use. I think 2 things are the major issue why more are not coming to FGU before other VTTs (if they choose another VTT).

Ease of use.
Looks very old.


No other VTT comes close to the automation that FGU has and the things the OP is saying to have would mostly be moving away from TTRPG and more into just being close to a video game.

More automation you have the more limited scope of things you can say or do. FGU already has all those things you are asking to do, it's just not set up for you to 1 click and put it in.
I can set up traps and triggers. I can have attack rolls happen automatically when you get in range of something or trigger something. It's just not easy to set up with a simple click you need to think about it in a way of using effects and tools inside FGU.

Not saying that looking old/ease of use are not priority areas, but they have more to do with the interface so I gave my perspective in the interface thread.

Automation capabilities out of the box depend on the ruleset, and as I wrote for PF1 there is little, maybe you use 5E. You cannot do all the things I listed - I don't think it would be possible to do the colour coded movement even with an extension with current API. I would not know myself, but it was commented to that effect by someone in another thread. Also I would be curious about how you would code say PFRPG automatic flanking detection and relative bonus with an effect, I don't think it's possible.

"No other VTT comes close to the automation that FGU has" Not sure about this. Are we talking out of the box or with extensions? And again I would imagine it depends on the ruleset. PF2E support in FoundryVTT is said to be top notch. FG has a strong reputation, and the effect coding is very powerful, but I am very suspicious of such a blanket statement.

Finally, not having to code effects, or even worse a full extension, surely contributes to ease of use.

[MrDDT]

Not saying that looking old/ease of use are not priority areas, but they have more to do with the interface so I gave my perspective in the interface thread.

Automation capabilities out of the box depend on the ruleset, and as I wrote for PF1 there is little, maybe you use 5E. You cannot do all the things I listed - I don't think it would be possible to do the colour coded movement even with an extension with current API. I would not know myself, but it was commented to that effect by someone in another thread. Also I would be curious about how you would code say PFRPG automatic flanking detection and relative bonus with an effect, I don't think it's possible.

"No other VTT comes close to the automation that FGU has" Not sure about this. Are we talking out of the box or with extensions? And again I would imagine it depends on the ruleset. PF2E support in FoundryVTT is said to be top notch. FG has a strong reputation, and the effect coding is very powerful, but I am very suspicious of such a blanket statement.

Finally, not having to code effects, or even worse a full extension, surely contributes to ease of use.

Out of the box or using exts/modules. Nothing is as good as FGU for automation.

Yes out of the box you can't do all the things you talking about wanting it to do, but with extensions currently out there you can.

I do think that FVTT is progressing very fast and it's catching up to what FGU can do, but I expect it's a ways off and FGU is still moving faster these last few years than it has before. So maybe we will see the changes.

I'm excited to see what FGU has to offer coming over this year, from what I'm seeing I expect it will really change the things we need in it. It's like they got some of the roadblocks out of the way to open the flood gates to do what is needed/asked.

Heck outside of FGU just getting the FORGE up and running was a huge step in allowing people to add into their games EXTs that most people using FGU never knew how to do before or would do.

For me why I see so many looking at FVTT before FGU is a major part of marketing. Roll20 and FVTT both have good marketing systems. If FGU overhauled it's UI to look better, and then also put out a marketing campaign, you would see a lot of heads turning to look at FGU as #2 VTT instead of #3, and it would eat up more of the market share of #1 VTT.

[snupy]

Yes out of the box you can't do all the things you talking about wanting it to do, but with extensions currently out there you can.


Ok, then could you please link extensions which replicate the behaviour of the dragruler foundry module thing linked in the first page, and which automate flanking for PFRPG? I'd really like to use them. Sorry if I sound slightly conflictual but I made specific points/asked for some source for your claims and you provided neither, simply restating the same things as facts.

I also noticed how FG is improving and I am pleased by that. Usually my posts are meant to be constructive criticism/observations, not complaints.

[Dudin]

Ok, then could you please link extensions which replicate the behaviour of the dragruler foundry module thing linked in the first page, and which automate flanking for PFRPG? I'd really like to use them. Sorry if I sound slightly conflictual but I made specific points/asked for some source for your claims and you provided neither, simply restating the same things as facts.

I also noticed how FG is improving and I am pleased by that. Usually my posts are meant to be constructive criticism/observations, not complaints.

I don't think anyone has a good way to quantitatively prove FGU has more automation than FVTT. I haven't used FVTT, but from what I have seen/read FGU has more automation out of the box.
Reading your post, you seem to be hanging whether FGU is more automated than FVTT on two specific additional functions, movement tracking (which doesn't exist on FGU) and PF1 flanking automation, which doesn't seem like a good benchmark to use. Even if FGU doesn't have the dragruler function (though I would like to see it on FGU) that doesn't mean it can't provide more automation overall. Flanking automation exists for 5E ruleset, but I am guessing no one has taken the time to write an extension that does it for PF1.

[SylvanSnake]

Mitigating duplications could theoretically be handled internally by each module. Simply a switch inside a specific module that would check if another module is loaded. An example would be in Pathfinder Advanced Player's Guide, it would not load the Summoner class rules if Pathfinder Unleashed was also loaded (the newer version should have precedence).

[Jiminimonka]

Hold down both mouse buttons and drag on the map. Drag ruler.

[snupy]

Hold down both mouse buttons and drag on the map. Drag ruler.

Thanks, that works for measuring distances, but does not take into account the speed of the creature moving, while drag ruler does and color codes accordingly (green = movement action, yellow = standard+ movement, etc). Which can be kind of useful for players (to take encumbrance into account), and very useful for GMs, which have to move a wide variety of creatures with different speeds.

[celestian]

Probably the best thing that Smiteworks could do, to fix "Ease of Use" and "Looks Very Old", would be to hire a competent UI/UX designer as well as put together a rotating UI/UX focus group of users that would get together with the UI/UX lead and discuss usability and design issues, suggestions, and feedback that really has nothing to do with features or rules or automation (per se) that can then be taken back to the developers to focus on for the next iterations.

I agree with your comment 100%. Along with that I would add that it would be extremely beneficial for the developers inhouse and the community if there were better development tools. At the very least a breakpoint and variable analyzation option.

[Jiminimonka]

I agree with your comment 100%. Along with that I would add that it would be extremely beneficial for the developers inhouse and the community if there were better development tools. At the very least a breakpoint and variable analyzation option.

You asked about that a couple of times on the FG stream. Maybe a feature request?

[Jiminimonka]

Thanks, that works for measuring distances, but does not take into account the speed of the creature moving, while drag ruler does and color codes accordingly (green = movement action, yellow = standard+ movement, etc). Which can be kind of useful for players (to take encumbrance into account), and very useful for GMs, which have to move a wide variety of creatures with different speeds.

So it picks up the movement speed of the token selected and colour codes according to that?

This would need to be different for every ruleset.

[snupy]

So it picks up the movement speed of the token selected and colour codes according to that?

This would need to be different for every ruleset.

Yes and yes, it would be different for different rulesets. However I think that once the basic implementation is in place (reading the token speed and providing the ability to colour code as you drag), adapting it to different rulesets should be almost trivial. I imagine it would boil down to changing the values of A,B in if statements like

if ( distance dragged <= A) then colour green
if (A< distance dragged <= B) then colour yellow
if (B< distance dragged) then colour red

with most rulesets being accounted for by simply setting different values for the variables A,B.

[Zacchaeus]

You'd also need to take account of temporary effects which increase or decrease movement. So way more complicated than simply looking at the movement speed. You'd also need to consider difficult terrain and all sorts of other things (you mention carrying too much as being another factor). Most rulesets don't pay any attention to movement speeds at the moment (that is you can move your token as far as you like).

[pindercarl]

Yes and yes, it would be different for different rulesets. However I think that once the basic implementation is in place (reading the token speed and providing the ability to colour code as you drag), adapting it to different rulesets should be almost trivial. I imagine it would boil down to changing the values of A,B in if statements like

if ( distance dragged <= A) then colour green
if (A< distance dragged <= B) then colour yellow
if (B< distance dragged) then colour red

with most rulesets being accounted for by simply setting different values for the variables A,B.

I've considered exposing some the token measurement tool to the API, like the start/end colors and the starting number. I'll run it by John and see if it fits anywhere in the schedule.

[snupy]

You'd also need to take account of temporary effects which increase or decrease movement. So way more complicated than simply looking at the movement speed. You'd also need to consider difficult terrain and all sorts of other things (you mention carrying too much as being another factor). Most rulesets don't pay any attention to movement speeds at the moment (that is you can move your token as far as you like).

Yes, that would be just the baseline. Even just that would be already quite useful for GMs, which are the ones who would benefit the most for this feature, as encumbrance don’t usually come into play for NpCs and monsters.

With that said, encumbrance in PF1 does not look too bad as it modifies the base speed, so the same logic would apply with a different base speed for the token. In fact I think FG does change a character speed according to encumbrance already.

Kinda the same applies to difficult terrain, which effectively acts as a multiplier on the base speed. Now, having a difficult terrain square apply an effect which changes the base speed on tokens entering it is more complicated and falls into the more ambitious kind of functionality which I mentioned in the initial post. Spells and the like are probably more of a mixed bag.

Still, even if not everything is covered a partial implementation would still help a lot. Seems to me that the FG developer team usually implements features gradually rather than all at once, which seems very sensible.

Lastly, I guess part of my point is that the most of the coding effort in the development of this feature would apply to all rulesets, and to then adapt it to a specific rule set would require no more then setting a few variables to specific values. I may be missing something though.

[snupy]

I've considered exposing some the token measurement tool to the API, like the start/end colors and the starting number. I'll run it by John and see if it fits anywhere in the schedule.

Great to hear that!

[dmbrown]

As far as "Ease of use" goes... As a software developer of many, many years, I have come to the realization that developers are the WORST people to design things for others to use. We KNOW the intimate and intricate details on how the software we develop works, and so we are too close to the trees to see the forest. This is not a dig on any developers of Fantasy Grounds, but it is a generalization about all developers that, from my experience, has been 100% true with both myself and every other developer I have worked with.

Probably the best thing that Smiteworks could do, to fix "Ease of Use" and "Looks Very Old", would be to hire a competent UI/UX designer as well as put together a rotating UI/UX focus group of users that would get together with the UI/UX lead and discuss usability and design issues, suggestions, and feedback that really has nothing to do with features or rules or automation (per se) that can then be taken back to the developers to focus on for the next iterations.

I know at one point they had a job posted for a UX/UI position. I don’t see it anymore, so I don’t know if they ever hired someone or decide not to fill that position. Maybe some one from Smiteworks can comment?

[ThirdSign]

I think the biggest functional hurdle for players using FGU is how touchpad unfriendly it is. When my players show up with laptops, no one brings a mouse.

I didn't realize how big of a problem it was until I watched one of my players struggle and fail to use the little doodad in the bottom right of the map to move the map around. Not to mention all of the shortcuts that require using the middle mouse button (doesn't exist) or right and left click simultaneously (also not possible).

[snupy]

I think the biggest functional hurdle for players using FGU is how touchpad unfriendly it is. When my players show up with laptops, no one brings a mouse.

I didn't realize how big of a problem it was until I watched one of my players struggle and fail to use the little doodad in the bottom right of the map to move the map around. Not to mention all of the shortcuts that require using the middle mouse button (doesn't exist) or right and left click simultaneously (also not possible).

Have you updated? That used to be one of my major complaints but now you can pan with wasd keys and also dragging while holding space.

[Trenloe]

As mentioned by @snupy - with the recent 2.5D map views, keyboard shortcuts have been added. See this section of the FG Wiki for more information: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1275232424/Common+Shortcuts+Hotkeys#Map

[ThirdSign]

Oh that's fantastic. I'll have slightly less grumbling next session!

[Nylanfs]

I miss my thinkpad with the little mouse/joystick thingy. :(