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
Calego
Calego3y ago
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.
Wasp
Wasp3y ago
Yeah, that's effectively what I'm doing
Calego
Calego3y ago
<#901108458944876584>
Wasp
Wasp3y ago
Deleted channel indeed 😄
Calego
Calego3y ago
^ thread on the mothership oh dang
Wasp
Wasp3y ago
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 machine
Calego
Calego3y ago
it's "Local vs Socket Hooks" in the #dev-support channel archived threads if you're interested, basically just atro saying what I said 😛
Wasp
Wasp3y ago
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?
Calego
Calego3y ago
what does the dropping of the item actually do? creates an embeddded document on the scene right?
Wasp
Wasp3y ago
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
Calego
Calego3y ago
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
Wasp
Wasp3y ago
I mean, there's still a "default" actor that all tokens refer back to
Calego
Calego3y ago
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
Wasp
Wasp3y ago
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
Calego
Calego3y ago
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')
Wasp
Wasp3y ago
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
Calego
Calego3y ago
i'm preachin to the choir, this is looking awesome @wasp vote
Leo The League Lion
@calego gave vote LeaguePoints™ to @wasp (#6 • 319)
Mana
Mana3y ago
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.
Wasp
Wasp3y ago
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