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?

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

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 machine

it'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)

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