No worries, Jean-Guy... The reference to libInline being required I think is a relic of the nascent days of the metascript-o-verse, before they big-banged themselves into many different scripts with different responsibilities. APILogic does not require libInline... I have corrected the documentation to that effect. ZeroFrame requires libInline, so we'll still want to get to the bottom of what is going on, but really quickly, a metascript primer: When your sandbox boots up, the various scripts you have installed are collected into a single, long js file... listed one after the other. When that file is together and run, functions that are built to be executed immediately are executed, from the top of the file to the bottom. Importantly, this includes event registrations - those functions that want to listen to a particular kind of event in the game: token changes, character changes, chat events, etc. So, from top down in your script deck (or, from your historically first script installed to your last), the scripts have a chance to register for events, forming a queue of scripts waiting to take action when that event occurs. Imagine those listening functions like workers on an assembly line. In the case of a chat event, the message comes down the assembly line, and the first worker gets a chance to act on the message... but then the message keeps going to the next worker, etc., in the order the workers registered. In the case of chat events, most standard functions (most of our workers) will do nothing to the message, because we structure our messages to trigger particular workers: TokenMod will act on messages intended for TokenMod; ChatSetAttr on ChatSetAttr messages; SmartAoE on SmartAoE... etc. These are standard scripts. Next, imagine that every worker on the left side of the assembly line are metascript workers. They're going to use a trick to register early (sooner to see the message as it comes down the assembly line). All of those workers walk forward (still in their same order) until they fill all of the first stations along the assembly line. Workers on the right side (our standard workers), move back (also maintaining their internal order) until the first standard worker is immediately after the last meta-worker. Metascript workers don't intend to own the message as it moves down the assembly line... they just look for work they need to do to it (like evaluating conditionals to change the command line, "virtually" selecting tokens, looking up game information not available through standard Roll20 syntax, etc.). This is great... it doesn't matter when you install your metascripts, they'll jump to the front of the queue and do their thing. But... ...their internal order is always the same: the order in which you install them. That means that, depending on how you install them, you could use one to drive a change that a second would react to, but not the reverse. For instance, Fetch returns data from the game. APILogic evaluates conditionals. Installing Fetch first would mean that you could use a Fetch construction inside a conditional... ie (pseudo-syntax): if (fetch: the token's top property) is greater than 200 then do ... this... But you could not use a conditional to choose which fetch construction to return...: @(selected.{&if a = b}attribute_1{&else}attribute_2{&end}) ...because the conditional wouldn't have the time to process by the time Fetch went to look for an attribute, meaning Fetch would be using all of that APILogic syntax as the name it was looking for. The same works in reverse if you instead install APILogic before Fetch... now the second case would work, but not the first. This is where ZeroFrame comes in. In the big-bang split of different functionalities from the original APILogic, ZeroFrame got roll management and metascript ordering. The metascripts will work without ZeroFrame, but they will always work in the order you install them... one to the next. With ZeroFrame, no matter the order you install them, it will... 1) run them in a default order that satisfies 90% of use cases, 2) loop over the installed scripts in case one meta-operation exposes a text construction that another metascript, higher in the order, would want to act on, 3) allow you to configure the metascripts in a different order for all messages, 4) allow you to configure the metascripts in a different order for a single message, and 5) allow you to "defer" individual text constructions (breaking up the pattern that might otherwise be detected) so that the construction isn't detected for 1 or more cycles of the ZeroFrame loop. A recent (beta) change to ZeroFrame also gives it the ability to "batch" up commands, allowing you to share die rolls between individual commands in a multi-command message, and to avoid a known Roll20 bug where random commands are sometimes dropped from a multi-command macro. That's probably more information about the metascripts than you probably need, but it explains why APILogic will work with or without ZeroFrame, and what the benefit is of having both installed. Regarding libInline... Can you share the scripts your game has installed? (A screen-shot will do, if there are a lot of them) I have the one-click version installed in my various test games, and they are working. If you want ZeroFrame, then when you install it from the one-click it will pull down libInline, as well. If the problem persists at that point, I would look at the scripts you have installed. There is a bug where each script requires a blank line at the bottom (so that things don't break with the lot of them are concatenated into that single large file I mentioned). Typically this affects scripts installed after that problematic script, so some might work and others might not. If you can't figure out which is causing the problem, have your gm shoot me an invite and promote me to GM, and I can try to figure it out.
