preUpdate
So for some reason ItemPF#_preUpdate changes aren't sticking.. what is PF1 doing that prevents this?
17 Replies
There shouldn't be anything that fundamentally prevents this. PreUpdate data is run after update, and relatively shortly before socket handoff, and thus should be after PF's working
For a test: can you manually throw what you want into a regular update, and check whether that sticks? Does preUpdate stick afterwards?
As per sys dev channel on the other server, it Should work, but for some reason it's not:
https://discord.com/channels/170995199584108546/670336275496042502/880417562809217087
You mean put what I want as item.update() call? I can try. I kinda purposefully made it not try to override the value in that case, but I guess I can remove that bit of code.
If the regular update doesn't stick, something's very fishy (if it's not in some object that is affected by regular .update handling)
Looks to be working fine
What happens now when the preUpdate code sets that to 120 or so?
(Just trying to figure out what's going on, whether the key is created or not, whether it's updated, etc.)
No change as before.
Does adding to the template affect anything?
That is something I wanted to avoid, but I'll try. Just a moment.
No effect
The code's here in case you want a peek https://gitlab.com/Furyspark/foundryvtt-pathfinder1/-/merge_requests/276/diffs
Though I don't think it helps
One sec, giving it a spin
I keep suspecting it needs to be an override on the item document rather than the item, but that seems silly.
This is interesting. The code works on my end
Well, *mostly that is. One buff's duration start didn't stick for some reason, despite the update data containing it and the options being the same as everywhere else. The response simply didn't include it though, i.e. everything was sent to the server correctly, but that part of the update data was disregarded by the server
I'm getting myself some tea, and then check what's going on there. Manually including the data in the update worked on that buff btw, and the preUpdate routine seems to stick now, too.
Odd. Tho I guess I've only been testing it with that singular spell buff. I have no idea how to debug that though (especially the part where it's not working for some items but is for others).
I played around with this a bit, and I haven't been able to reproduce the data not sticking except for that one initial buff 
Weird. Is it a problem with the buff itself then for some reason? That doesn't make much sense.
I'll probably take another look tomorrow, and maybe use another old world backup to see whether there's some pattern I didn't see yet. The fact alone that the data is part of the updates to the server, only to get dropped in the response makes me scratch my head though
Not spotting any difference in the workflow in foundry.js for it, and it looks identical with preUpdate hook, so I'm just utterly baffled where it's disappearing to.
I can not get this to work no matter how I try. Linked character or unlinked, new character or old, it just doesn't work. Updating it by hand first makes no difference for the preUpdate working.
Edit: Crud, I was on wrong branch now... it's what I get trying to solve multiple problems at the same time.
And now it's working with linked token at least...
Unlinked tokens not so much.
I guess I was testing with just unlinked tokens prior without realizing?
Yep,
Item#_preUpdate doesn't have any effect on token actor item updates
Changes to the individual item update data don't seem to ever get merged or affect the actorData.items data, so _preUpdate changes just vanish
I just tested this with 5e by adding the method to items, and everything's fine for real actors, but token actors don't see any effect whatsoever
The issue for this can now be found at https://gitlab.com/foundrynet/foundryvtt/-/issues/5861