Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Script] Muler v2.0 - Use rollable tables as mules, and make modified rolls against them

1668452902

Edited 1668455217
timmaugh
Pro
API Scripter
Muler v2.0 (beta release) FILE LOCATION:   My Personal Repo  (beta) - 1-click version will update after beta DEPENDENCIES :  Muler  needs  libTable  ( beta release in my repo  pending 1-click submission). ABSTRACT: Muler  is a metascript that gives you the ability to store/recall variables in an ad hoc basis, letting you reuse information from one macro to the next. Any number of mules can be loaded into a given message, exposing the variables to retrieval and/or setting. New in v2.0, Muler will also let you mule-in rollable tables, giving you more flexibility for rolling against a table in such a way that you can use modifiers. As a metascript, you can use it in a message/command line intended for another script. Upgrade This is an upgrade on the Muler script, and most of what was said in  the initial forum post  about it still holds, including syntax, timing, and meta-toolbox tie in. That said, there are some important new features, and a couple of edge-case behavior changes to be aware of. The biggest change is by far the ability to mule-in rollable tables and roll against them with modified inline rolls, so be sure to check out the Rollable Table Mules section. What's New If you're not familiar with the script, how it does what it does, or what purpose it serves, you might want to start with the original thread (above). For those who do know or have used Muler, here are the new fixes and features: FIXES A player need not be explicitly named in the controlledby property of a mule character; Muler will now respect the "all" designation to make the mules on a given character available to every player. FEATURES {&mule...}  statements are no longer required, so long as at least 1  get  or  set  statement is fully qualified... ie,  get.character.mule.var  or  get.table.tablename.var ... those will load those mules/tables into the message to make available the variables contained within. If you have one of these FQ references, other references can be short-handed:  get.var  (var-only example) or  get.mulename.var  (example of mule + var). The FQ reference need not be the first muler statement encountered in the macro; the script will look for fully-qualified statements as a part of looking for mules to load, then proceed to filling  get/set  requests. Muler will now let you mule your rollable tables, so you can roll a modified roll against them. For a table-variable, you can return the name, avatar/url, or image/html (basically wrapping the URL is a basic <img src="..."> tag) A table entry can be retrieved via the name, or by an open-ended index (to allow the rolling against): get.table.MaleNames.[[1d20-1d12]].value (where .value is a ZeroFrame construction) get.MaleNames.Henry?image Using Your Rollable Tables as Mules Loading the Mule Mule your rollable table by including a {&mule...} statement or a fully qualified get statement that references the table. For rollable tables, the "character" portion of the syntax should read "table" (case insensitive, though the table name IS case-sensitive): {&mule table.Surnames} get.table.ShopWares-Baubles.Crystal get.table.ShopWares-Baubles.`Jeweled Orb` get.table.ShopWares-Baubles.[[1d20]].value Any of these would make the table entries associated with that table available as variables to return. If such a statement is detected in the command line, other  get  statements referencing variables on that same mule need not be fully qualified: get.ShopWares-Baubles.Scepter get.Scepter?image get.3?name Note that  get   statements that refer only to a variable from a rollable table must include the  which  syntax (the question mark --  ? ), explained below. Getting a Variable From a Rollable Table Mule Variables loaded from rollable tables are slightly different from other mules in that they can be access by either their index or their name (the content of the rollable table entry). They are also different in that you can return any of the entry's name, avatar/url, or image/html. Take, for example, this entry: Referencing By Name The name of that entry is "Scepter", therefore you could reference it like this: get.table.Shopwares-Baubles.Scepter ...or, if that formation was going to abut other text in your command line (like a punctuation mark), you could choose to end the  get  statement, like this: get.table.Shopwares-Baubles.Scepter/get If the Shopwares-Baubles table had been already referenced in a mule-statement or a fully-qualified  get  or  set  statement, then these shorter versions would return the same information: get.Shopwares-Baubles.Scepter get.Scepter?name Referencing By Index Muler turns the relative weights of table entries into an open-ended index. "Open-ended" means that any number will return a value from the table, even if the number is below 0 or greater than the total weight of all items on the table. Muler accomplishes this by assigning all values up to and including the weight of the first item in the table to that first item, then incrementing all indexes to the last item based on each item's weight, and finally by assigning all numbers above the last figured index to the last item in the table. This might be better understood by seeing it: TABLE NAME: ExampleTable TABLE ENTRIES  |  WEIGHT  |   MULE INDEX ============================================   A        | 2 | <=2   B | 1 | 3   C | 1 | 4   D | 3 | 5-7   E | 2 | 8-9   F | 1 | 10 G | 1 | >=11 Given that table, the following would be valid ways to refer by index to entry 'D' (with the same caveats regarding when/if you have to use the fully qualified version versus one of the shorter versions): get.table.ExampleTable.5 get.ExampleTable.5 get.5?name But since item 'D' is represented by a range of indices, you could replace the 5 with a 6 or a 7. You could even use an inline roll (see  Rolling Against a Muled Table , below). Getting the Right Data - the  which  Selector Use the which selector (the ?) to tell Muler which piece of data you want to return: the name, the avatar/url, or the image/html. The which selector can be used with any get statement formation, but it must be used with any get statement that only includes the variable name. get.table.Shopwares-Baubles.Scepter?image get.Shopwares-Baubles.Scepter?html get.Shopwares-Baubles.[[1d10]].value?name get.10?name Use either  avatar  or  url  to get the url of the image used as the avatar for that rollable table entry. Use either  image  or  html  to get the url of the avatar packaged up in an <img> html tag. If no  which  selector is supplied but Muler knows you are referring to a table, it will return the name data (e.g., "name" is the default for table mules). Rolling For a Value We have been able to roll against a rollable table with standard Roll20 syntax like: [[ 1t[TableName] ]] However, that formation rolls against the whole of the table, with pre-established weights to each of the entries. Rolling against the table with a  modified  roll (giving an artificial minimum or maximum to what could be returned) was impossible without creating another table. Muler solves this problem by creating the open-ended indices, turning the entries into variables to be read just like any other mule. Using the "by reference" syntax (described just above), you can supply an inline roll that accomplishes the appropriate math, then use ZeroFrame (another metascript) to extract the value from the roll. EXAMPLE : Imagine a rollable table called "MechanicalInjuries" made up of 20 entries of equal weight (1) that describe injuries characters could suffer from traveling over rigorous terrain. Once the character satisfied the mechanic of having incurred an injury, the player should roll a d20 against the table, but modify their roll downward for their current level of Exhaustion (lower entries on the table are more serious injuries, so a higher exhaustion should result in more grievous injuries). The rule describes a roll like this: [[1d20 - @{selected|exhaustion}]] So you can use that in a get statement referencing that table as: get.table.MechanicalInjuries.[[1d20 - @{selected|exhaustion}]].value ...where the  .value  portion of the syntax is coming from ZeroFrame. No matter if that inline roll would deliver a negative result or a result over 20 (for a system where the Exhaustion attribute could be a negative number), Muler would return the appropriate result from the table. Setting a Value to a Table Entry At this time, you cannot use a set statement to set a rollable table entry's data. Edge Case Behaviors Previously, if a variable for a get statement could not be found, the get statement would be left in the command line of the message to be potentially detected in the next metascript loop cycle (if you had ZeroFrame installed). That is, if there was no variable named "Cleetus" in the "Moolio" mule when Muler saw this get statement: get.Moolio.Cleetus ... then the entire construction would be left in the message against the possibility that future metascript work would either expose the mule or add a variable of the appropriate name. The new behavior for this situation is that Muler will replace all get statements it finds when it finds them , returning a zero-character, empty string if the variable cannot be found at that time. Mules are loaded prior to any retrieval operations made against them (or any setting operations, for that matter), so just make sure you have a mule statement or a fully qualified get / set statement at least in the same loop-pass as the retrieval, and this will not be a problem.
1668452920
timmaugh
Pro
API Scripter
Reserved for future info/examples.