FGU: Functionality

[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.