This isn't inside a function that's only called sometimes right?
This isn't inside a function that's only called sometimes right?
ZTry using
console.warn as the hook function.ZTo test it, it should spit out all the arguments, and it will be easier to find in the console.
CShouldn't be!
CThat didn't work
CIt makes sense if core suppresses(?) hook logs. I feel like that's something I've run into before
ZIf that doesn't work, I don't think thr hook is getting called.
ZLemme see if I can repro.
Coh shit this might be a gulp issue?
Z?
Cone of my js files isn't getting emitted from the new ts
Z(You on 0.7 or 0.8?)
Cthe one that registers hooks
C0.8
ZTry registering the hook in the console.
Cyeah fuck gulp lol
Coh yep that'll do it
ZZLooks like the logging is the first thing it does, so that should log any hook that is
called.ZBut I could swear there was an issue of the opposite being true.
ZBut it's possible that was in the past.,
CThis is a pretty open ended question but I'll try to overview what you're after:
First you're going to need a Hook which you can tap into to inject an element onto the page. A good candidates is "ready".
Then you'll need to actually inject your element, imo a button is best, and register a listener to control the interaction. With jquery something like this:
The last step is going to be actually doing something. You'll need to keep a reference to whatever Application you want to open and close somewhere that the listener code can use it.
First you're going to need a Hook which you can tap into to inject an element onto the page. A good candidates is "ready".
Then you'll need to actually inject your element, imo a button is best, and register a listener to control the interaction. With jquery something like this:
$(".my-button").on("click", () => doSomething())The last step is going to be actually doing something. You'll need to keep a reference to whatever Application you want to open and close somewhere that the listener code can use it.
BHere's some example code for how I add a button to the tiles control list in one of my projects:
(the button calls
Hooking on "getSceneControlButtons" and then adding your button to where you want it in the argument that hook gives you is the way to do this.
Toggling an application on and off is doable - you would want a function which:
if the application is not open, creates it and renders it.
If the application is open, finds it and calls the .close() method to close it (with enough checks to make sure you're actually closing the application you care about)
(the button calls
flattenTilePrompt() when clicked). Hooking on "getSceneControlButtons" and then adding your button to where you want it in the argument that hook gives you is the way to do this.
Toggling an application on and off is doable - you would want a function which:
if the application is not open, creates it and renders it.
If the application is open, finds it and calls the .close() method to close it (with enough checks to make sure you're actually closing the application you care about)
CI'll leave you with @badideasbureau ;)
B(mine is if you want it in the scene control buttons. Calego's is more general if you want a button somewhere else on the screen, e.g. in the chat pane)
CRight, that's a good point to make a distinction of
BOK, so do you roughly understand what the code I posted above is doing, or do you want me to explain it in a bit more detail?
BAlright. I'm pretty much the other way around (I'm reasonably familiar with the Foundry API at this point, but my js fundamentals are shonky), so sorry if I end up explaining something JS standard as if it's a new thing
BOK, so, Foundry communicates between a lot of its parts with hooks. The way to access these is
A fairly common approach for hooks in Foundry is for the hook to pass an argument which is the thing being created by the function that throws the hook, and allow the callback functions to modify that argument. This is what's happening here - the "getSceneControlButtons" hook passes an argument of
Hooks.on("hookName", callback), which will call callback whenever the hookName hook is thrown out by part of the code. The hook will pass arguments, which are generally used to go "hey, I'm doing this, and this is the data I'm doing it with".A fairly common approach for hooks in Foundry is for the hook to pass an argument which is the thing being created by the function that throws the hook, and allow the callback functions to modify that argument. This is what's happening here - the "getSceneControlButtons" hook passes an argument of
buttons, which is an array of each of the scene tools.
BSo what my code is doing is a) checking that the "tiles" tool group exists (in case a module has screwed with it), and then if it does it pushes a new button into its tools array, with an onClick callback to do what I want it to do.
BI think once you have the application open, it should stay open even if you change scenes, so I don't think the location of the button will matter there.
BSure - you just push it into the array directly, AFAIK