hook conventions
Regarding hooks, is the convention that all
pre... hooks are executed on the machine that initiated the action? Ie, if a user updated an actor, it would call preUpdateActor only on their machine, and then updateActor on everyone elses?20 Replies
This is an interesting topic with a deceptively simple answer:
"All Hooks are only run client side"
It just so happens that the Document lifecycle hooks happen in response to a Server message telling the client to update its understanding of a document.
So for modules making their own hooks, the recommendation is to make the API consumer of the Hook implement its own socket if the hook is supposed to trigger something on other clients.
Yeah, that's effectively what I'm doing
<#901108458944876584>
Deleted channel indeed 😄
^ thread on the mothership
oh dang
pre hooks are called on the initiating machine, in this case, when a user drops an item onto a pile, preDropItem is called on their machineit's "Local vs Socket Hooks" in the #dev-support channel archived threads if you're interested, basically just atro saying what I said 😛
then
dropItem is called on all users via a socket as each connected users should be able to observe said event
Cool 😄
But is what I'm doing seem sane?what does the dropping of the item actually do? creates an embeddded document on the scene right?
Depends - if dropped on an existing pile, it transfer the item from actor to actor, otherwise it creates a new pile token before transferring
I'm trying to stay in the bounds of Foundry's existing document models as to make it as easy to maintain and as extensible as possible
is this powered by unlinked tokens? I'll be honest those still scare me and I haven't looked into much for how they work
I mean, there's still a "default" actor that all tokens refer back to
What you're saying seems sane though, I'm not sure what sorts of things another module might want to do with these hooks, that's somethign that helps me think about how a hook structure should work
but the tokens aren't linked to that specific actor in the sense that they share the same inventory
It's just a basic character actor, nothing fancy. If later down the line people want to create system specific sheets that enable it to look different, that's a whole different thing
But I want to make it as system agnostic as possible while staying in the bounds of Foundry's patterns
Thanks for the insight
I dig it!
Ahh, is this meant to be system agnostic?
if so, and this is off topic, remember that systems define their own actor types/data models so 'character' might not exist in a given system (nor might 'inventory')
Yeah, it's just using whatever actor model is defined as default
and using the default item document ownership as defined by the actor base class
As ya can see, you're even able to define your own transferable attributes from piles:
https://discordapp.com/channels/732325252788387980/734095524822777976/927333289977585724
So that currencies may be able to be picked up
i'm preachin to the choir, this is looking awesome @wasp 
@calego gave LeaguePoints™ to @wasp (#6 • 319)
LeaguePoints™ to @wasp (#6 • 319)I don't believe any of the drop hooks fire on all clients. They're all only on the initiating client's side. The rest of the users get whatever that results in (usually actor.update() hook chain)
Otherwise you'd get drop hook firing and then all clients as result of it calling update actor on and try to add the same item on all clients, which is quite wrong.
Oh, I'm not talking about the generic drop hook
I'm talking about item pile's hooks, which ride off of the client drop hook