D&D 2024 Sheet: Can Mods/API modify sheet resources like Lay on Hands, Rage, Channel Divinity, etc.?

Hi everyone, I’m trying to figure out whether the new D&D 2024 character sheet supports modifying sheet resources through the Roll20 Mods/API, or whether those resources are effectively read-only/generated from the sheet’s internal state. I’m building a custom API script for single-target attacks, saving throw spells, healing, range checking, FX, and resource tracking. Most of that is working well. The issue I’m running into is with limited-use resources on the D&D 2024 sheet, specifically Paladin Lay on Hands . Using a sheet-inspection helper script, I found that the visible Lay on Hands resource appears to live inside the character’s store object here: store.integrants.integrants.XbjS1iInfNvU21tGf98Pt.value The max value appears to be here: store.integrants.integrants.XbjS1iInfNvU21tGf98Pt.maxValueFormula.flatValue The same object has fields identifying it as Lay on Hands, and it appears to include recovery data such as Long Rest recovery. My API script can successfully read the resource. For example, it reads: available: 10 max: 15 The script can also heal the target token correctly, calculate the amount spent correctly, and display the expected remaining value in chat. For example, after spending 1 point, it displays something like: 9 / 15 left However, the actual visible resource on the D&D 2024 character sheet does not change. It still shows the original value on the sheet, and later API reads may show the value has reverted or been rebuilt from the sheet’s internal state. I also tested directly modifying the store object path and writing it back using API methods such as: attr.set({ current: rootObject }); and: attr.setWithWorker({ current: rootObject }); The script does not error, but the visible 2024 sheet resource does not update. So my questions are: Are D&D 2024 sheet resources inside the store.integrants.integrants structure intended to be writable from the Mods/API sandbox? If they are writable, what is the correct supported method for changing a resource value so that the visible sheet updates? Is there a different flat attribute or sheetworker-facing attribute that should be modified instead of the store object? Are resources like Lay on Hands, Rage, Channel Divinity, Bardic Inspiration, etc. exposed to the API in any supported way? If the store object is generated/read-only/internal, is there currently any recommended API-compatible method to deduct and restore D&D 2024 sheet resources? My goal is to have API macros deduct from the same resource pools that the sheet displays and restores on Long Rest, rather than creating duplicate custom API-only attributes. Any guidance from people who have worked with the D&D 2024 sheet structure would be appreciated.

Beacon sheets do not use attributes... at least not like legacy sheets. They don't even have to use an object named "store". Everything is bespoke, and everything of the UI contract has to be rebuilt and implemented by the sheet dev. It is very much a "white list", permission-play model, and if the dev doesn't understand the VTT UI contract well enough to implement the functionality or access, or doesn't think some part of the contract is worth implementing, or simply doesn't have time to implement some part of the contract, then you are out of luck. The 2024 sheet, specifically, *does* use a store object. The store is read into memory and the engine is run on a player computer connected to the game. You can overwrite it, but as you've discovered, your changes are then overwritten when the engine -- which is running it's own store implementation (read from the store attribute when the beacon engine spins up) -- decides to commit its changes back to firebase. What you can reach via the API -- what the devs have decided to expose -- is a limited set of sheet datapoints. I *believe* they generally correlate to the items that are exposed for chat retrieval via:  @{Character|computedName} ...syntax... but I could be wrong about that because... pain. The general -- and very, very lacking -- accepted/expected course of interaction is that you would access a thing with getSheetItem() and set a thing with setSheetItem(). If you can reach it with getSheetItem(), then you can set it with setSheetItem()... ...except that there isn't a "thing" you're setting if, by "thing", you are imagining a standard Roll20 object which you can then interrogate and pull other properties from, or from which you would implement other methods (like .set() ). ...and that retrieving the value in the first place requires you to have its name (no agnostic retrieval). ...and that you only get the value of that thing, not any other metadata (like its existence or lack thereof). So if you can reach the items you need via chat-retrieval syntax, you *should* be able to retrieve them with getSheetItem and set them with setSheetItem. If you can't...? You have been fong-ed.

Have you found any class resources with the chat retrieval syntax? I can’t figure them out.. 2014 sheets are so much easier to automate

Have you modified any sheet class resources on 2024 sheets such as spell slots, lay on hands, sorcery points, etc..?

Dom said: 2014 sheets are so much easier to automate Which is why I am still using the 2014 sheet. :)

I have not explored any of those things... but... ...you see now what it is to try for Beacon-ready-code. There's nothing agnostic. So not only do you not know ... you don't know what you don't know . I think the best you're going to be able to do is check the computedSummary off of the Campaign() object: let allComps = Campaign().computedSummary ...if I remember correctly. That might tell you what is available. At least for the 2024 sheet. So much is bespoke about the beaco-sphere that I don't know if that same summary would be available for another beacon-based sheet unless the dev of the sheet decided (remembered... knew how) to implement it. I mean, it might. I try to stay away from the beacon stuff as much as I can.

Additional Technical Feedback: 2014 vs 2024 Sheet Automation Architecture After further development and testing of my SmartTarget automation system, I wanted to provide some additional technical feedback regarding the differences between the 2014 sheet architecture and the 2024 Beacon sheet architecture from the perspective of API/mod developers. This is not intended as criticism of the 2024 ruleset itself. The issue is primarily how the sheet architecture affects automation workflows. Current SmartTarget Workflow on 2014 Sheets With the 2014 sheet, SmartTarget functions as the primary automation controller. The script can directly read and modify character attributes including: Spell slots Class resources Custom resources Hit points Temporary hit points AC values Saving throw DCs Attack modifiers Resource counters Because these values are exposed as traditional attributes, the entire spellcasting workflow can be controlled through a single macro invocation. Example workflow: Player clicks a spell macro. SmartTarget validates required resources. SmartTarget verifies spell slots or class resources are available. If resources are unavailable, casting is blocked. Player selects targets. Damage is rolled automatically. Saves are resolved. Damage is applied. Status effects are applied. Resources are deducted. A single integrated spell card is displayed. From a user perspective this is effectively a one-click experience. The script owns the entire transaction from validation through resolution. Resource Validation One particularly important capability on the 2014 sheet is resource validation. For example: Fireball requires a 3rd-level spell slot. Rage requires an available Rage use. Channel Divinity requires an available use. Sorcery Points must exist before metamagic can be applied. Because SmartTarget can directly read resource attributes, it can enforce game state before execution. Example: Current Level 3 Spell Slots: 0 Player attempts to cast Fireball. Result: "Unable to cast Fireball. No Level 3 spell slots remaining." The action never proceeds. This prevents accidental or intentional resource bypassing. 2024 Sheet Workflow The Beacon sheet changes this architecture substantially. The sheet itself now acts as the primary controller of spellcasting and resource management. My SmartTarget system can no longer reliably access the same information or perform the same validation checks that were possible on the 2014 sheet. As a result, the workflow becomes a staged process: Player clicks the Beacon sheet spell. Beacon sheet executes its internal logic. Beacon sheet spends resources internally. Beacon sheet generates a spell card. Player activates SmartTarget. Player selects targets. Player manually enters damage results. SmartTarget processes targets. SmartTarget applies damage and effects. SmartTarget generates a second results card. Example macro: !smarttarget --sheetMode|2024 --damageSource|external --deferDamage|yes --sheetCharacterId|-OuJrYJZfBC5jQEBKcHi --sheetAbility|repeating_spell-1_cfcRYbNhA_spell ... Several design differences become immediately apparent: Sheet-Generated Abilities The 2024 workflow relies on sheet-generated repeating abilities. For example: repeating_spell-1_cfcRYbNhA_spell These generated identifiers become embedded inside automation macros. While functional, this creates a dependency on sheet-generated internal identifiers that did not exist in the traditional 2014 attribute model. Staged Damage Resolution With the 2014 sheet: SmartTarget knows: The spell The damage formula The save type The save DC The resource costs and can therefore perform the entire operation. With the 2024 sheet: The Beacon sheet performs the roll internally. SmartTarget often cannot reliably determine: Final rolled damage Upcast calculations Applied modifiers Internal sheet calculations As a result, damage must be staged and supplied back into the automation flow manually. Loss of Resource Enforcement This is currently the most significant operational difference. While the Beacon sheet does decrement resources internally, SmartTarget cannot reliably query and enforce those resources before execution. On the 2014 sheet: SmartTarget can block actions before they occur. On the 2024 sheet: SmartTarget must assume the sheet has handled the resource correctly. More importantly, there is currently no equivalent API-accessible validation layer that allows SmartTarget to prevent execution when resources are exhausted. For example: Level 3 Spell Slots: 0 A SmartTarget-controlled Fireball on the 2014 sheet can be prevented entirely. On the 2024 sheet, SmartTarget has no reliable mechanism to validate and enforce that restriction before the sheet action is executed. This removes a major safeguard that existed in the 2014 automation model. Duplicate Output Cards Another consequence of the staged architecture is duplicate chat output. 2014: Single SmartTarget card. 2024: Beacon-generated spell card. SmartTarget-generated targeting/results card. Since the Beacon-generated card is not under SmartTarget's control, the results cannot be merged into a single unified presentation. Summary From an automation developer perspective, the difference is not simply that the 2024 sheet requires new integration work. The fundamental control model has changed. 2014 architecture: Sheet → Data Source Script → Controller 2024 architecture: Sheet → Controller Script → Secondary Processor This significantly impacts: Resource validation Resource enforcement Automated spellcasting Damage automation Unified chat presentation One-click workflow design While SmartTarget can still operate alongside the 2024 sheet, it can no longer function as a complete end-to-end automation system in the way it can with the 2014 sheet architecture. For groups that heavily utilize API-driven automation, this represents a substantial functional difference beyond the rules changes introduced by D&D 2024.

Join the chorus. Beacon is a sunk cost debacle that violates core pillars of Roll20's UI contract. Any component of the UI contract that you might wish to see in a sheet (roll template, inline rolls, attribute exposure, token interoperability, etc.) has to be recreated and added by the dev on a bespoke, sheet-by-sheet basis. That means the dev not only has to be aware of that functionality, but they have to value it enough to build it, and they have to have the skill  and time to be able to build it. And so does the author building the next sheet. And the sheet after that. Because it's bespoke turtles, all the way down. It took 2 years for the 2024 sheet to round into "beta release" form. Seven months ago, the first attempt at updating ChatSetAttr to work with beacon revealed that the sheet wasn't even exposing user-created attributes at all, and certainly not with API integration. I recently looked at updating my Fetch script to work with Beacon, and was confronted with the fact that there is no agnostic retrieval of computeds (ie, no looking for a computed by descriptors OTHER THAN the name). You have to know the name of the thing you are looking for, and then you are just presented with the value of the thing. There is no identification of "presence" (since computeds can't be deleted, they appear the same as a nullified value as they do as a non-existent value) There is no batch retrieval and mapping/reducing/processing There is no object in memory providing an interface of get/set, name, value, max, in one location Not to mention the whole thing runs in the browser of one of the connected players and sheet interaction has been forced into being asynchronous ... both of which invite (and produce) lag/latency. It's built from a "permission-play", "white-list" model, where your interaction with the sheet is only allowed via pre-scripted avenues, and the fact that the sheet breaks the UI contract is seen as a value add, protecting the sheet and its data from your grubby little paws, you absolute heathen. The technology needs to be abandoned, IMO. And any replacement needs to be built in a way that identifies the fundamental modalities of the Roll20 UI contract as project requirements from the beginning.

timmaugh said: Join the chorus. The technology needs to be abandoned, IMO. And any replacement needs to be built in a way that identifies the fundamental modalities of the Roll20 UI contract as project requirements from the beginning. Couldn't agree more Timmaugh.. Hopefully we see something different in the near future, otherwise I don't see much reason to continue using roll20 over other platforms. It's already hard enough to justify as is.