Cantrip Charges 🧵
Cantrip Charges 🧵
39 Replies
@manaflower Just to check, as I've not followed the charges MR that closely:
item.system.uses.autoDeductChargesCost should be "0" for cantrips, and persisted in their data, right?Yes.
With added
tAnd having the data filled in via template is not necessary, since the default charge formula uses that value when available, but provides the usual default of
"1"Yeah.
It could be just empty string in the template.json
I didn't add it there simply because filling the data in was unnecessary.
Yeah, I'd be fine with not adding it to the template to avoid unnecessary bloat
It gets added to the items tho because the input field is in the sheets, but it avoids the initial entry at least.
Might be interesting to prevent such default values from being added, but I'm not sure I'm worried enough about this to tack it onto this milestone 😄
It's better to edit the compendium entries and leave it at that.
I just checked the pack extraction, and the field is removed because it's not part of the template. Instead of adding it there however, I opted to except the field from pruning for now.
As long as it's not unnecessarily added to other spells through migrations or sheet actions, that should work. Can't say I'm totally happy with this though.
They shouldn't. Unless there's old data, which should be equivalent with the "0" formula.
The migrations currently also clean away that old data, so it shouldn't linger.
Aye, that was mostly speaking about future slip-ups. Right now, everything looks 👌
@manaflower Thanks for the script and the MR btw!
@ethaks gave 
LeaguePoints™ to @manaflower (#15 • 201)
LeaguePoints™ to @manaflower (#15 • 201)No problem. The cantrip issue has been an annoyance for me for a long time now, so I kinda had to.
Not sure whether I broke something, but when I run the migration from your MR on the compendium contents, the check fails because that field is
""
Oh, wait, might've been the wrong field. Let me check again 😄If that field is empty string, it's just corrupt data at that point. And it matching or not doesn't matter much at that point.
Yeah, misread the name
Anyways, for the spell
Scoop (level 0/Cantrip; random example, same for all cantrips), the field item.system.actions[0].uses.autoDeductCharges does not exist in the current pack data, so is never added.
From a quick glance, it looks like that action data field is deleted in _migrateItemActionChargesCost, and that migration was already appliedYeah, it matters mostly for people with such data still in their world in actors, tokens or items directory.
After reverting the previous migration and re-running the current one, I get and for a cantrip. Does that look right?
The boolean should be gone.
It is no longer used for anything.
And the action autodeductchargescost should be empty string by default for everything, even after migration.
It being "1" is especially wrong for cantrips.
Hmm, in that case it looks like the current migration, when applied to pack data as it was before the spell cost MR, produces unwanted results
The migration doesn't set it to "1" ever, it only changes it to empty string.
With that data actually, it should be deleting the boolean and setting the "1" to ""
It's like the migration isn't happening as such?
At least not fully
I honestly don't see a reason for the migration to be failing.
Ah, I think I see the issue
Changes to
updateData["system.actions"] in the item migration are ignored in favour of specialised migrations from migrateItemActionData IIRCOh, yeah, that will trash the action update.
But that means some other action updates are being trashed by it also.
That I can check when done with this issue 😫
So, after running migrations, I now get
action.uses.autoDeductChargesCost: "" and item.uses.autoDeducChargesCost: "0" for a cantrip
No autoDeductCharges boolean in the action, no autoDeductCharges in the item
Does that finally look right? 😄Yep.
All other autodeduchargecost formulas should be empty strings in the included compendiums (with the actions they provide, maybe someday in the future they'll have more variety).
Hmm, some non-cantrip spells seem to have
item.system.uses.autoDeductChargesCost: "0", tooThat should happen only if they had autoDeductCharges set to false, or it's some lingering old bad data?
Looks like some spells did indeed have
preparation.autoDeductCharges: falseThat will cause some annoyances for users who have those spells, but there's no good solution to fix it for them (automatically).
Example Abeyance from before the spell cost MR: https://gitlab.com/foundryvtt_pathfinder1e/foundryvtt-pathfinder1/-/blob/25585cfe3d31b1d703f8d5442e918c3500d218cf/packs/spells/abeyance.json
Yep, that's just bad data.
Well, it's also an issue for the system, as the compendium provides spells with bad data right now, right?
The compendium needs to be fixed, yes. But the migration can't fix the spells for users who've already added them to actors or the like, as that fix might break them more.
Mostly due to homebrew or something.
Yeah, for spells in worlds it's too late to automatically fix them
Since my brain's already fried: Is it safe to delete
item.system.uses.autoDeductChargesCost for non-level-0 spells?For the bundled spells, yes.
Pushed my changes into your MR. All spells were changed due to
system.flags being pruned according to the template, but here's Acid Splash: https://gitlab.com/foundryvtt_pathfinder1e/foundryvtt-pathfinder1/-/blob/25cfef936e70bc4a4831a508e4b9eb03059a4b16/packs/spells/acid-splash.json as standalone file, https://gitlab.com/foundryvtt_pathfinder1e/foundryvtt-pathfinder1/-/merge_requests/867/diffs#5968d4f21283eea9dd77a2b690bb60ac0c1ab208 as diffThat might be undoing some compendium updates.
Looks good for the cantrip, but range.value is changing in some places back to number.
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
It stopped being an issue only because autoDeductCharges handling broke completely.