Calling character sheet action buttons by name from API?

Hi Rowan! I don't know if it's what you are looking for, but the Token Action Maker script might fit the bill, since it supports the PF2 sheet. At the very least, it might point you in the direction of the code you need. You can also check out the Universal Chat Menus script .

1686277429

Thanks Keith! Hmmm, Universal Chat Menus might get me a little closer - it can create a button in the chat menu that works to call the sheet action when clicked. It looks like it uses the ability command button syntax to do so: [Label}(~<keyword>|<ability name>) But what I really want is to be able to have a script trigger an existing sheet action button directly, without needing to click it. I'm writing a script to handle the more complicated interactions of applying, removing, and adjusting the value of a condition, and it would be ideal if I can use the existing sheet action to do the applying and removing from behind the scenes. I think maybe sheet actions just aren't accessible to the API, though? And I'm not sure how to work around it since they're in the character sheet itself, not a campaign object like an ability where you could find the object and pull the text of it out to execute directly. Anyway, really appreciate your time and help! Rowan

1686280457

Edited 1686284885

Forum Champion

Hi Rowan,  Most character sheet actions are basically already macros in their own right. Just need the right command to trigger them.  I believe the commands for that are in the PF2e wiki.  How would your script differ from a macro button? Based on the description in your individual post it seems like you are trying to replicate what should already be basic functionality in most sheets.  As an example: I have created an Action called "Test".  I can call "Test" by using: %{selected|repeating_actions_$0_action} Now, how do I put that in front of a player so they understand it?  Chat Menu works well for this.  Example: Macro called "Actions" /w @{selected|character_name} &{template:default} {{name=Actions}} {{=[@{selected|repeating_actions_$0_name}](~selected|repeating_actions_$0_action) [@{selected|repeating_actions_$1_name}](~selected|repeating_actions_$1_action) [@{selected|repeating_actions_$2_name}](~selected|repeating_actions_$2_action)}} The macro can be set up to ignore repeating actions that are not present. If that is the direction you want to go and we can fill in the blanks etc. 

1686288132

Thanks for the thoughts, Gauss! I think part of the confusion I may have failed to clarify in my question is the word "action" -- what I want to access is specifically the default condition action buttons (as in, <button type="action" name="act_Wounded">), which are not repeating elements, nor actions like an attack that the player would take into the chat; they're buttons used to create/toggle specific repeating _ condition elements in the first place . That's where I'm struggling to figure out if and how the API can access it, because usually the buttons people are accessing in these ways are roll buttons (e.g. <button type="roll" name="roll_STR">) and seem to have a little more external accessibility -- you can drag them to the macro bar, it works fine to call them with ability syntax %{Test1|STR} from the API as well as manually. I wanted a script rather than a macro / chat menu because I was hoping to coordinate dynamically with things like status markers, does the condition already exist on the character, setting the value of the new repeating_condition elements, duration / conditions expiring with the turn order (probably through Combat Master). And even with APILogic installed that feels, uh, Tough to manage in a macro :). But! I did just in testing further discover that the condition action button does less than I thought, so I can probably work around it after all! The PF2E sheet auto-calculates debuffs for default conditions, e.g. for Clumsy it adds a -1 penalty to all dexterity-keyed skills, attacks, AC, etc. I'd thought the only way to tell it to do all the debuffs was by the action button creating/removing those temp modifiers (which I REALLY was not trying to remake by hand!!). It turns out the button actually just creates a repeating_conditions item named Clumsy (albeit with a nice pre-generated rules description), and then the sheet itself listens for any repeating_conditions item named Clumsy and applies the debuffs accordingly. So it will be more feasible for me to work around the action button by creating such a repeating element directly. Action buttons are still a mystery to me, though :)

1686288626

Edited 1686288638

Forum Champion

Could you screenshot the section of the sheet in question please? My sheet knowledge is general, not specific to any one system. 

1686306879

GiGs

Pro

Sheet Author

API Scripter

It sounds like you want to toggle attribute values (the conditions). The sheet normally uses action buttons to do this, but you can probably bypass them entirely. You just need to identify the names for the condition attributes, then you can use a script like chatSetAttr to toggle them on and off. Does that work?

1686414565

Gauss said: Could you screenshot the section of the sheet in question please? My sheet knowledge is general, not specific to any one system.  Sure thing, sorry, I didn't want to bog down with too much specific info if there was a more general answer about action buttons that would be clear (though it seems there isn't!). Here's the collapsible section of action buttons <div class="defaultConditions> , followed by the standard repeating section for applied conditions <div class="repcontainer" data-groupname="repeating_conditions"> . This state is the result of clicking the action button "Encumbered", which creates the repeating_conditions_$0_condition entry Encumbered. One of the effects of Encumbered is to also make you Clumsy 1, so the sheet creates that condition too (with their appropriate descriptions in _$x_condition_notes ). Clumsy imposes a temp status penalty to Dex-based checks and DCs, which includes AC when Dex-based: So the action button handles all of those things automatically. It also copies the bit between the ***'s into the armor_class_notes attribute (not shown) while the condition is active so you can see where the malus comes from, which is great. GiGs said: It sounds like you want to toggle attribute values (the conditions). The sheet normally uses action buttons to do this, but you can probably bypass them entirely. You just need to identify the names for the condition attributes, then you can use a script like chatSetAttr to toggle them on and off. Does that work? Yeah, I'm still trying to identify exactly what the action buttons specifically do beyond creating the condition -- there's some functionality that just creating the repeating_condition element doesn't reproduce, including cascading conditions as above Encumbered > Clumsy 1 > dex-based skill malus 1. For conditions that include a value like Clumsy X, just creating the appropriate attribute DOES work to apply the malus, as it recalculates / applies whenever the repeating_condition_$x_conditionvalue changes. But some conditions don't depend on a value, like Flat-footed which always applies a flat -2 AC malus, and that malus isn't triggered when creating the attribute manually / with chatSetAttr. The action button seems to handle that on creation since it's static. Given how much thought and dependencies clearly went into making the condition system in the sheet, I certainly don't want to remake it all by hand, which is why it would be great if I could access the action buttons directly from the API. So if that's not possible, it may be that I just need to readjust the workflow into chat menus that can call the action button as I think Keith suggested earlier - asking more steps from players is probably worth getting to use the action buttons in this case. Plus, requiring interaction to confirm even automatic changes (e.g. Frightened ticks down at the end of a creature's turn) might be for the best anyway to make sure everyone's aware of the current state of the battlefield. Really appreciate everyone's help thinking of potential workarounds!

1686419091

Edited 1686419127

Forum Champion

It looks like some of the Status effects do not use Attributes (such as Fascinated). Instead it appears they fire off a bunch of changes, then when turned off they reverse those changes. I could be wrong though, maybe there is a 'hidden' attribute? I am not an API Scripter, but from what I understand I don't think the API can do what you want here as there are no attributes to act upon for all of the status markers.  GiGs would know more though. 

1686424467

Edited 1686424547

Gauss said: It looks like some of the Status effects do not use Attributes (such as Fascinated). Instead it appears they fire off a bunch of changes, then when turned off they reverse those changes. I could be wrong though, maybe there is a 'hidden' attribute? I am not an API Scripter, but from what I understand I don't think the API can do what you want here as there are no attributes to act upon for all of the status markers.  GiGs would know more though.  Huh, that's interesting -- I've got the API logging any changes to attributes to the console while trying to figure all this out, and Fascinated does start all those changes with setting a hidden attribute @{selected|Fascinated} to 'on', which creates the Fascinated repeating_condition element and triggers all the little changes. Turning off the button sets @{selected|Fascinated} to 0, which removes the Fascinated repeating_condition element and strips all the changes as you noted. Setting @{selected|Fascinated} to 'on' with chatSetAttr creates a new repeating_condition element, with no name , that has the correct description, which then applies the -2 changes to all the assorted values. But then setting @{selected|Fascinated} to 0 with chatSetAttr can't find any conditions named Fascinated to remove (bc it's unnamed), so it can't strip the changes, and just leaves -2 in all the stats. I tried the same with Flat-Footed , which should behave similarly to Fascinated, using chatSetAttr to set @{selected|Flat-Footed} to 'on', and got this error to the console: "Translation Error: the key [Flat-Footed_description] is not in the translation object." And the description of the blank repeating element on the sheet just reads 'false': So I guess the existence of the Flat-Footed attribute set to 'on' is triggering the sheet to create a repeating condition and attempt to fill it with [Flat-Footed_description], but it's not finding it because the action button didn't provide it? Further cementing my takeaway that trying to circumvent the action button is not worth the headache, since behavior isn't uniform, but now I'm even more curious about what's going on under the hood. The Pathfinder Second Edition by Roll20 code isn't public anymore, though, right? The last version I found linked to on github was 3 years old and doesn't have this defaultConditions section at all. There's probably no way to access exactly what the action buttons do / what the sheet is trying to do from outside?

1686427979

Forum Champion