Your namespace is a way to limit your footprint to the global namespace to 1 total entry. Everything else that you code up, build as a function, etc, is going to be within that namespace. It can change the availability of functions, and it can change the way you call them. If your Warhammer function is in your namespace, "brickhouse", then pretty much everywhere within brickhouse you can call Warhammer as you do, now: Warhammer(...) ...but it would be unavailable to a function from OUTSIDE your brickhouse. If you only had a Warhammer function in the brickhouse namespace (and nothing in the global namespace), then a function from another namespace that tried to call Warhammer as we just did would throw an error. The only way for a function from another namespace (even the global namespace) to call your Warhammer function (built within your brickhouse namespace) would be if the brickhouse namespace exposed the function as part of its interface (I'll get to that in a minute). In that case, a exo-brickhouse function would have to invoke the Warhammer function more like this: brickhouse.Warhammer(...) Make sense? The trade-off of extra steps to arrive at the proper location of the function is paid for in terms of the protection of making sure that people intend to call YOUR Warhammer function, and when they do, they GET your Warhammer script. Here are the basics of carving out your own namespace (I'll use fat arrow syntax, but you can do the function invocation pattern, the way you did) const brickhouse = (() => { // this will be your namespace declaration; see note from last line for more info const handleInput = (msg) => { // this is where the api handle is evaluated; see registerEventHandlers function }; const registerEventHandlers = () => { // this establishes any event listeners we need (chat, graphic changes, handout changes, etc.) on('chat:message', handleInput); // declare handleInput as the function to run when a chat comes through }; on('ready',() => { // when ready, we need to add those event listeners registerEventHanders(); }; return { // public interface of the namespace; this is where you'd expose the internal functions, if necessary }; })(); // the parentheses turn this into an immediately invoked function expression (IIFE)
// giving you access to the return interface anytime you reference the namespace
So, with your code added in, it would look something like... const brickhouse = (() => { const handleInput = (msg) => { if (msg.type == "api" && msg.content.indexOf("!custommartial") == 0){ var args = msg.content.split(/\s+/); var weapon = args[1].toLowerCase(); var numberhands = Number(args[2]); var tokenid = msg.selected[0]._id; var token = getObj("graphic",tokenid); var charID = token.get("represents"); var tokenName = token.get("name"); switch(weapon){ case "warhammer": Warhammer(numberhands,tokenName); break; case "longsword": longSword(numberhands,tokenName); break; } } }; const Warhammer = (numberhands,tokenName) => { // ... Warhammer code here }; const longSword = (numberhands,tokenName) => { // ... longSword code here }; const registerEventHandlers = () => { on('chat:message', handleInput); }; on('ready',() => { registerEventHanders(); }; return { }; })(); Now that I've gone through that... a couple of thoughts. I said your Warhammer and Longsword functions could access the variables you've already determined by the use of a namespace. I was short-handing things a bit. They can use those variables directly if they are children of the handleInput function where the variables are derived/declared (so the declarations of warhammer and longsword happen WITHIN the handleInput function). Putting them outside, as I have, you would still have to pass the variables the way you are. (But you still get the other protections of the namespace model.) Putting them outside of the handleInput function also makes it more straightforward to expose them to an exo-brickhouse function. To expose a function (or object, or variable, etc.), put it in the returned object (between the {}). A good model to follow here is to have internally lowercase or camelCase function names, but use TitleCase for the exposed version: return { WarHammer: warHammer, LongSword: longSword }; I don't know that you will need to expose either function, but it's good to know how if you need to. One more point... your capitalization standard is a bit off... Warhammer is leading with a capital, while longSword is camelCase. OK, one more/more point. =D I find long if-blocks that could otherwise be exits to create too much whitespace in my code. You have to indent everything until that api check finishes. If you reverse your logic, you can exit the function at a failed 'if' statement, and move on if it passes: if (msg.type !== "api" || msg.content.indexOf("!custommartial") !== 0) return; Now, when you're back from vacay, let's settle the other problem you were having, too!
