5E - Single Click Action

[fxg42]

Update 2021-09-08: Version 4.1.6 disables double-click on all buttons so this extension is no longer needed.

Super tiny extension that prevents players from accidentally double-clicking on power action buttons and in doing so, casting a spell twice or doing damage or healing twice.

Why
Having to double-click on weapon attacks but single-click on spell attacks regularly causes mistakes and head-scratches from newer or infrequent players. Having to fix spell attack and damage rolls live also causes delays on my end during combat.

Links

Forge: https://forge.fantasygrounds.com/shop/items/202/view
Source code: https://github.com/fxg42/single-click-action
Issues: https://github.com/fxg42/single-click-action/issues

[Zacchaeus]

Nice one.

[fxg42]

Thanks!

[Moon Wizard]

Very interesting. I like the simplicity of addressing the symptom without needing a re-design.

I might play around with this concept some more; though I have some other ideas on how to block without clock tracking. One of the things you mentioned was the dissonance between the weapons and spells for buttons/fields. I've thought about adding the buttons to weapons, but the PF/3.5E multi-attack always throws me off. Might just force limited buttons for those cases. I'm still considering whether blocking double clicks on buttons will be confusing to users that try to click multiple times, if I did add buttons (i.e. fighter multi-attack in 5E)

Thanks,
JPG

[fxg42]

Very interesting. I like the simplicity of addressing the symptom without needing a re-design.

Thank you for the kind feedback! You're completely correct in that the actual issue is the "sometimes I should double-click, sometimes I should single-click" and there is certainly a better solution to that than disabling double-click :) Thanks again!

[damned]

I think in situations where you need to make two attacks it would not be hard for us to get used to waiting 1s between attacks. I think most people that I have played with tend to let the first attack resolve before doing the second attack anyway. That is particularly important in the case where the first roll is a critical success and extra damage is auto calculated.

[fxg42]

I think in situations where you need to make two attacks it would not be hard for us to get used to waiting 1s between attacks.

Thanks! As it stands, the extension makes it so that clicks that occurs within about 500ms of the last roll are ignored. This could probably be shorten to 300ms or maybe even 200ms. I tested the extension yesterday with a group where a player is notorious for double-clicking spell attacks -- haven't had a single issue all session :)

[bmos]

Super tiny extension that prevents players from accidentally double-clicking on power action buttons and in doing so, casting a spell twice or doing damage or healing twice.Beautiful!
I don't play 5E, but this is a wonderfully simple workaround for a very common issue.
Also, thanks for having a git repo.

[fxg42]

Beautiful!
I don't play 5E, but this is a wonderfully simple workaround for a very common issue.

Thank you so much!

[MeAndUnique]

Gonna hop on the praise wagon here, very nice job!

[fxg42]

very nice job!

Thank you kindly! :)

[SirMotte]

Wonderful, the older folks at my table will love it!

[fxg42]

Wonderful, the older folks at my table will love it!

lol! I feel seen :)

[bratch9]

Looks good, just done a quick check.

Can you apply this to the 'droped' down buttons on the spells as well ? (spell.jpg)

Thanks, my group have this problem all the time, so will be using it this weekend.

[fxg42]

Can you apply this to the 'droped' down buttons on the spells as well ? (spell.jpg)

Hi! That's a good idea. I forgot those!

[MrDDT]

I'm having issues with this working with my other exts. Anyone else having issues? It simply just doesn't do anything. I'm wondering if maybe I need to change the load order or something.

[Weissrolf]

Nice workaround for a common problem that ideally should be solved on an application level.

Unfortunately it doesn't seem to do anything in combination with my other extensions, double clicking action buttons still applies the button action twice. Will test this further.


You're completely correct in that the actual issue is the "sometimes I should double-click, sometimes I should single-click" and there is certainly a better solution to that than disabling double-click :) Thanks again!
Like an option for users to choose between double- or single-click and then keep it consistent for all buttons.

[nephranka]

I'm having issues with this working with my other exts. Anyone else having issues? It simply just doesn't do anything. I'm wondering if maybe I need to change the load order or something.

The dbl click needs to be fast else it will not be seen by this ext as a true dbl click. I tested on its own and it was working. When I tried this ext with 5E Extension - Combat Automation v1.1 by Xelab\nAutomates Spellcasting and Weapon Attacks. They seem to be in conflict and it was not working no matter how fast I dbl clicked.

[bmos]

I posted a pull request that contains a potential fix for this incompatibility.

I haven't tested to make sure it's working though, so I'm just just a 'armchair contributor' here ;)

[fxg42]

I posted a pull request that contains a potential fix for this incompatibility.

Thank you so much! Can't wait to try out the PR :)

[fxg42]

Thanks to @bmos' idea, I uploaded another version in the Forge.

This new version extends the functionality to buttons in the action "details" view. (see bratch9's comment).

Also, as this implementation does not interfere with UI elements, it could fix conflicts with other extensions (see MrDDT's and nephranka's comments). This has not been tested however.

[bmos]

Also, as this implementation does not interfere with UI elements, it could fix conflicts with other extensions (see MrDDT's and nephranka's comments). This has not been tested however.It should, although I've never seen anyone store the original function how you are doing it so I can't say for sure.
You also have a potential issue since you don't have an onClose function.
Because of that, every time your campaign script is called, it may be creating a ever-deeper nest of functions calling each other.

[nephranka]

It should, although I've never seen anyone store the original function how you are doing it so I can't say for sure.
You also have a potential issue since you don't have an onClose function.
Because of that, every time your campaign script is called, it may be creating a ever-deeper nest of functions calling each other.

That sounds bad...I assume that would lead to a system crash?
I will give it some tests.

[bmos]

That sounds bad...I assume that would lead to a system crash?
I will give it some tests.Not necessarily. It would only 'deepen' the nest of functions when the powers tab windowclass is unloaded/loaded and I'm not so familiar with when things get unloaded in FG.
I'd guess it would just get slower if the character sheet was closed and re-opened a bunch. Eventually it could crash, but probably it isn't getting unloaded enough times in a session to actually get there.

EDIT: I just realized the script in this extension is actually a named script now, it just hasn't been moved into /scripts (still in campaign/scripts as windowclass scripts usually are). So this concern is not a problem.

[fxg42]

EDIT: I just realized the script in this extension is actually a named script now, it just hasn't been moved into /scripts (still in campaign/scripts as windowclass scripts usually are). So this concern is not a problem.

Thanks! You had me worried for an instant :) I'll move the file to avoid future confusion.

[nephranka]

Thanks to @bmos' idea, I uploaded another version in the Forge.

This new version extends the functionality to buttons in the action "details" view. (see bratch9's comment).

Also, as this implementation does not interfere with UI elements, it could fix conflicts with other extensions (see MrDDT's and nephranka's comments). This has not been tested however.

I can confirm that at least with combat automation we still have a conflict. No change in the dbl click behavior with both running.

[fxg42]

I can confirm that at least with combat automation we still have a conflict.

Thank you for your help in testing this. For now, I've added a warning about this conflict on the forge page.

[bratch9]

Please do not keep changing the ext name in forge, as it does not remove the previous versions... so causes a mess in the extensions folder..

And for the non-devs, causes them issues because they see at the top list of extensions they have your extension loaded, but its not the new one... that one is down off the bottom of the list of extensions with a matching name.

Use the 'test' channel if you want to try things out and get more feedback on compatibility.

I do not want to see loads of extensions deciding to have v1,v2,v3,v4,v5.... version of extensions to clean up on the game folder.

( If this does happen we need a naming convention, so it easy to clean up, and so FGU can auto pick the new version from the bunch etc.. )

Just my 2p.. I know the less developer class people just will not spot and have issues if loads of developers start dropping loads of version history into the extensions folder. Just keep the name stable.

At worst change the <name> tag so have the version number so that its easy to see in FG what version is selected. Multiple lines of 'Single Click Action 5e Extension' in the list ( split top and bottom of the list ) does not help, as you might have to re-load a large module pack campaign when you notice its the wrong version. And we all know how fast FG is with initial loads of campaign folder.

[fxg42]

Use the 'test' channel if you want to try things out and get more feedback on compatibility.

I'll be sure to do that from now on.

[Ulric]

Any chance this extension could work with Starfinder? When I try it with Starfinder I get this error message.

[9/6/2021 6:00:33 PM] [ERROR] Script execution error: [string "campaign/scripts/single_click_manager.lua"]:3: attempt to index global 'PowerManager' (a nil value)

[fxg42]

Hi!


Any chance this extension could work with Starfinder?

Most likely. As it stands however, the implementation is 5E-specific -- it intercepts calls to one of the ruleset's modules (named "PowerManager"). Making it work with other rulesets would require analyzing the ruleset and adding a patch just for it.

My hope is that this behaviour (no double-clicks on actions) gets added into the system proper so we don't have to write a patch for every ruleset...

[Moon Wizard]

I've a completely different approach in the works; but it's bound up in a client update. But soon...

Regards,
JPG

[fxg42]

I've a completely different approach in the works

That's just awesome! Thank you!

[Ulric]

I've a completely different approach in the works; but it's bound up in a client update. But soon...

Regards,
JPG
Wonderful!

[Beemanpat]

I've a completely different approach in the works; but it's bound up in a client update. But soon...

Regards,
JPG

Was you referring to version release 4.1.6? Looks like the patch notes mentions something about "disable double-clicking"

[Moon Wizard]

Yes, in v4.1.6, double clicking on buttons is disabled by default, unless enabled by the ruleset/extension code.

Regards,
JPG

[Beemanpat]

this is great news. thank you

[fxg42]

Yes, in v4.1.6, double clicking on buttons is disabled by default, unless enabled by the ruleset/extension code.

Outstanding! I'll retire the extension. Thank you!

[Weissrolf]

Yes, in v4.1.6, double clicking on buttons is disabled by default, unless enabled by the ruleset/extension code.
Good news. Any chance to get an option for users to switch/decide between single- or double-click for all buttons? Or would extensions be able to change the behavior?

[Moon Wizard]

No, that would require the extension to override every button field and text field to offer alternate behaviors based on an option added by the extension.

JPG

[Weissrolf]

Forget my last post, I misunderstood that the problem was fixed by all UI elements being unified in click behavior by default. Instead only the symptoms are worked around similar to what the extension tried. So my post made no sense.

[Weissrolf]

I expect this bandaid workaround to be the final iteration of "solution" to this design problem, since we now learned that SW points to ruleset developers and ruleset developers point to SW. Let's hope our players get along with the remaining mix of single- vs. double-click buttons/fields and be happy that we got something out of the discussion.

[Beemanpat]

I'm happy progress has been made. Just goes to show we are heard and things are being worked out probably more than we realize.

[Weissrolf]

Actually we were only heard once someone took up the work of trying a workaround extension. Before it was "nah, we always did it this way, let's not change that". The problem was known for longer and the extra effort kindly invested by fxg42 could have been made better use of. Even now it remains a workaround to a more fundamental design issue.

Again, thanks to fxg42 for making this core change possible against all odds! :)

[Trenloe]

I expect this bandaid workaround to be the final iteration of "solution" to this design problem, since we now learned that SW points to ruleset developers and ruleset developers point to SW.
You should be well aware that the situation has moved on since the original post from Moon Wizard you refer to. If the situation was as you say, Moon Wizard wouldn't have done the recent change to the ruleset - he'd have left it to each ruleset developer - but he didn't! He also outlined expected standards (see first post below) that ruleset developers are expected to adhere to.

This is what I was referring to when I mentioned a SmiteWorks standard:


Buttons are single click; text fields are double-click. That should be consistent.

Redesigning the UI in that area is on our list, but not currently scheduled.

Note the bold part - it is something SmiteWorks plan to look at in future.

Also, if you refer to a later post in the thread you referred to:


My original goal with the buttons were to help indicate that there was a clear "action" at that point, with the plan to move away from having any text field interactions at all (i.e. remove double-clicks; and force all actions through buttons only). I agree that double-clicking on text fields is not necessarily an expected use case.

However, the character sheets were not originally developed by me; so a lot of this was adopted from other developers over time, and forcing change causes people to have "issues" with the changes. (i.e. "well, it worked that way before; and I want it back.") Also, adding single click obvious button/action behaviors also increases the number of controls/objects needed in sheets, causing both visual overload as well as increasing performance considerations.

So, there's not simple blanket answer that works for everyone, while I can appreciate the call for consistency. Like I said, it's a slow process, and it's not the highest priority.

This is not just pointing to ruleset developers to make changes to the UI behaviour - it's acknowledging and re-iterating that it's on the cards for future development. As there is a SmiteWorks standard (see first quote in this post) as the PF2 ruleset developer, I'm not going to change that standard and will keep to that standard as SmiteWorks make future changes.

I'm afraid this appears to be a case of you wanting an immediate change, and not being happy having to wait for what *you* want to happen down the line. You've also stuck with the one mention of "It's actually up to each ruleset how they want to implement" but not adapted to the discussion and information presented - where the standard has been outlined (both in the quote I posted above and in a thread you opened in the PF2 forum), and my response saying that if SmiteWorks change the standard, then the ruleset I'm responsible for will follow.

Please take this away, as it appears you've missed this information:

There's a standard there - I know you don't like it, but there is a standard.
The main FG developer has said they plan to look into redesigning the UI in the future - I know you don't like the fact that they're not immediately making changes, but it's up to SmiteWorks to prioritise development tasks.


I also refer you to the final post directed to you, in the main thread where you first broached this subject:


As noted in my email to you, I will not allow bullying and nagging via posts. Posting the same message across 5 different forums just to prove a point of how you perceived our answers is just blatant.

You have made your points here; and I have talked to @superteddy57 about letting me answer you since his post is "not" relevant to this particular scenario (though ruleset devs can override, there are common templates). There is no need to generate half a dozen additional posts to make a point.

So, please don't go on and on and on about things like you usually do. You've had a clear message from the main developer that you've made your points and that changes to the GUI is on the table for the future.

[Weissrolf]

Nope, just a case of conflicting information being given from forum officials, far from any "clear message". It's been: -> ruleset developers -> don't post twice -> sorry, didn't see you posted in rulesets -> don't post in rulesets -> locked (core) and locked (rulesets). Very concise way of handling things, I give you that.

The UI behavior hasn't been changed in years due to "no changes" and it won't be changed until it hurts the bank. At least my players don't have to deal with accidental double-clicks, except for all the remaining ruleset based single-click fields that are *not* affected by the latest changes.

I may be the loudest proponent of proper User-Experience-Design around here, but I sure am not the only one. And again thanks to fxg42 for motivating the precious little flower of innovative change.

[Moon Wizard]

Closing this thread. It has devolved from the original post; and the behavior of this extension has been included.

JPG