Some games are experiencing issues with Firebase. For a more information and a potential workaround, follow our Twitter.
Advertisement Create a free account

Combining Multiple API functionalities

Hello, I've recently discovered the glory of using the API to enhance my game and make my job as a GM a lot easier. However, I like it to be even easier if I can. So far I'm using many Scripts for my game, and I'd like to combine their functionality to make it more seamless. Let me start by listing the Scripts I want to combine in terms of functions: TokenMod Summon Monster Bump 5e Companion Script TokenNameNumber So, what I'm looking to do is set this up so that when I summon a set of monsters using Summon Monster, which allows for group summoning, each will be affected by TokenNameNumber. Then as they spawn, Token Mod would automatically implement the random face (as it's a Rollable Table Token), it would automatically be Bumped to the GM layer, and the 5e Companion Script would roll random HP for the monsters. Token Mod would do other things as well, but the important thing is starting the process. After I learn how to do this, I can figure out how to implement the rest of the Token Mod commands.
Sheet Author
Maybe you could use Kastion's [Script] !delay script to handle this...
That is an awesome script of which I may very well implement myself, but not what I was looking for. Essentially I just feel I need to go into the TokenNameNumber script and modify it to make the TokenMod calls I want. However, I'm not entirely sure how to make calls to other scripts. I know programming and js isn't much different than what I know, but I'm not sure if there are any compatibility issues doing so or if the API even allows calls to other scripts. And if it does allow it, I'm not sure how to do so.
The Aaron
Forum Champion
API Scripter
The API is Event Driven.  Every script gets executed precisely one time, during which it must register for events with functions that will be called when they occur.  This works great for doing things when users do things. API commands in chat (!summon FooBar-Bazqux) cause a chat:message  event, which is processed by whatever function scripts have registered.   Where this breaks down is when it isn't a User doing something.  API scripts don't cause most events to be spawned.  (This was likely to prevent infinite loops.)  That means that when the Summon script gets its command and creates new graphic objects, there aren't the add:graphic  events spawning to tell other scripts the new graphics exist, as there would be if you drag things into the table as a User. There are several ways around this: Polling -- you could write an API script that just looks to see if there are more graphic tokens than it was previously aware of, and takes actions based on that fact.  This is almost always the wrong solution, but might be the only solution available in some situations. Direct Coupling -- you could write your API script to call out to the functions of other API scripts and directly cause them to do things.  This is only the right choice in very tight knit collections of scripts that you expect to be installed together.  Generally, this would only go one direction, as you'd have one script relying on the existence of some base script.  Often a script that provides some specific behavior and relies on a script that provides a generic library of functionality.  The down side of this is the tight coupling between scripts, and the direction of dependence. In the specific -> general dependency of a client depending on a library, this isn't a big deal.  When you start talking about two specific scripts, then it starts to be a problem because they need to know about something that is out of the scope of their intent. The Observer Pattern -- this is what I use in my scripts.  It's basically the same as the event model in miniature. TokenMod is a good example of something that is Observable, and Bump is a good example of an Observer.  An Observable script provides a function which other scripts can call which takes a function to be called when some event occurs.  In the case of TokenMod, the function is called ObserveTokenChange() and is passed a function to be called when TokenMod changes a token.  (You can find the functionality on line 722-731, the data structure on line 615, the notify event on line 2271, and the exported interface on line 2479.)  On the other side of the equation, Bump observes GroupInitiative so that it can take tokens that are invisible and exchange them for their GM Layer equivalents. (This happens on line 578-580, note the check for if the other script is actually installed.) The above is basically a survey of what techniques are available.   The nitty-gritty details are a bit harder to deal with.  Here's basically what you've got above: Summon creates [Tokens] TokenNameNumber numbers [Tokens] TokenMod manipulates [Tokens] Bump manipulates [Tokens] 5e Companion manipulates [Tokens] To get that to work, you'll need the bottom 4 to react to the event that the first one creates.  That's going to require modifying pretty much all of them, even with !delay.  They expect to operate on selected tokens (TokenMod, Bump), or on token creation events (TokenNameNumber, 5e Companion).  None of them are really set up to be activated by other scripts.
Thank you very much! This helps a lot. I'll examine the lines you pointed out to determine the method of interaction with other scripts and try to work this out for myself. The end of what you said was essentially what I was considering doing. The method of actually doing it was what was escaping me. I'm not very familiar with interaction between scripting languages as most of my programming experience comes from C++ and some of Java.
The Aaron
Forum Champion
API Scripter
No worries!  I’m a C++ man myself. =D
I'm still pretty new to javascript but could you pass a variable with that function?  I'm trying to have a script pass dice rolls to Power Cards.
The Aaron
Forum Champion
API Scripter
Michael, you can definitely pass information about, but it will depend on how you are invoking the other script as to what information you can pass it and how you do it.  Generally speaking, if you are calling it code-to-code and are in control of both sides of the communication, you can pass it whatever you like.
I don't know if it would work with power cards, but I was trying to come up with a quick and easy way to do something similar for only showing the crit damage when a crit score was hit in a custom macro. I found the script "Extended Expressions" to suit my own needs for this.
Thanks I'll check it out