[Script] Spawn Default Token Thread 2

Original script thread closed for inactivity. I'm re-posting the introduction here, but see the original link for more examples and discussion: <a href="https://app.roll20.net/forum/post/9046603/anybody-wanna-beta-test-a-default-token-spawning-script-with-toys/?pageforid=9046603#post-9046603" rel="nofollow">https://app.roll20.net/forum/post/9046603/anybody-wanna-beta-test-a-default-token-spawning-script-with-toys/?pageforid=9046603#post-9046603</a> Re-posted below: So this started out as a simple script to help automate KeithCurtis' cool trick using rollable table tokens and !token-mod to generate spell effects, illustrated&nbsp; here , but kind of expanded from there. I first looked at King's excellent !Summon script, but it seemed like it did not support setting sides of rollable table tokens or some other features I was looking for, so I thought it would be a fun project. Kind of went down a rabbit hole with options, but it was a fun learning experience. Thought I would share in case others found a use for it or had any suggestions for new or existing features, or just had general feedback like "...but why?". Many thanks to TheAaron, timmaugh, GiGs, and others who helped me through a few technical roadblocks along the way! I'm sure it is a hot mess as I was learning stuff as I went, but it seems to work and was fun so I'm ok with that. Concept Like !Summon, !Spawn can be used for spell effects, monster summoning, cataclysmic terrain changes, or any similar type application.&nbsp; The general idea is to automatically spawn the default token for a given "character" with various options for token qty, location/arrangement, and certain token properties such as size, side (for rollable table tokens), light emission, and "represents" property. In addition, I wanted to be able to automatically call a character "Ability" after the spawn event. This last part has a few caveats, which I will address later in the post.&nbsp; Support my work on&nbsp; Patreon I've been asked by a few folks if they can provide support in appreciation for a script or other help. &nbsp;If you find yourself falling into that group, too, then thank you! If not, no worries - it's not why I do this. &nbsp;I just want everyone to have as much fun as possible playing the games that they love! Disclaimer: Patreon campaigns are not affiliated with Roll20. Contributions are entirely voluntary and Roll20 cannot provide support or refunds for contributions. Example: &nbsp;Click image to see Animated gif of a baddy raising 8 minions/mooks (appearing as random sides of a rollable table token) around each of two targets: &nbsp; Example 2: This example spawns four dancing lights with a rollable table token (GenericSpellAoE) in a burst two squares from the selected character. The token is set to emit dim light (LDL) as per the spell description. The character casting the spell has darkvision with a light multiplier of two, in case anybody is counting squares :) !Spawn {{ --name| GenericSpellAoE --qty| 4 --placement| burst 2 --offset| 0,0 --force| yes --size| 1,1 --side| 7 --order | toFront --light| 10,-5 }} Click for animated gif: YouTube Demo Video by Nick O! Wanted to thank Nick O. for the great demo video highlighting a few of the features of this script. Check it out&nbsp; here !&nbsp;&nbsp; Note: If you want to use the script for spawning the party on a new page as he details, I'd recommend something along the likes of that described&nbsp; here &nbsp;to avoid inadvertent alterations to your PC's linked bar values (hp, ac, etc.). His video was using a previous version (v0.11), and that particular application of the script revealed some strange behavior that prompted changes in v0.12. Thanks, Nick! Version History --v0.2&nbsp; fixes bug that prevented non rollable table tokens from spawning correctly --v0.3&nbsp; provides&nbsp; UDL support &nbsp;for the --light command. See updated command notes for differences in use of this command between LDL &amp; UDL --v0.4&nbsp; supports floating point&nbsp; (decimal) --size parameters &nbsp; for partial square token sizes --v0.5 &nbsp;added limited support for&nbsp; triggering FX&nbsp; at spawn origin points. See updated command notes. Currently no custom FX or those that require directional input. --v0.6 &nbsp;now compatible with the TheAaron's&nbsp; TokenNameNumber&nbsp; script (v0.5.12 or later). Spawned tokens whose default token has the text %%NUMBERED%% somewhere in the name will have a sequential number appended to their name. --v0.7 &nbsp;added new placement option&nbsp;&nbsp; --placement|cross # &nbsp;, which distributes spawned tokens similar to "burst,", but in a vertical &amp; horizontal reticle arrangement. # is radius (in squares) of the innermost spawned tokens relative to the origin token(s). --v0.8 &nbsp;added ability to override the token bar values.&nbsp; --bar1| &lt;current&gt; / &lt;max&gt; . Max is optional. If command is used, then the corresponding&nbsp;bar "link" will be removed, if present. Values for current &amp; max can be formulas using attributes and/or queries.&nbsp; e.g. --bar1| [[ @{charName|constitution}+10*?{Spell Level?|1} ]] --v0.9&nbsp; added new command&nbsp; --expand| #,#&nbsp; , which causes the token to spawn first as a point, and then expand to full size based on user configurable number of frames and delay between frames (determining frame rate). --v0.10&nbsp; bug fix for certain cases where the default token does not have layer information. Now explicitly sets the spawn layer to that of the origin token(s). Side benefit: can now spawn on non-object layers (e.g. GM layer). --v0.11&nbsp; Corrected error handling for cases when no character sheet is found or when the requested auto-trigger ability is not found.&nbsp; --v0.12 &nbsp;Added the " KeepLink " keyword to the --bar1, --bar2, etc commands to preserve the token-bar-to-character link for bar values when they override those of the default token. --v0.13 &nbsp;Bug fix to ensure default token light settings were being honored.&nbsp; --v0.13a &nbsp;Stealth update that now allows floating point numbers for the --offset parameter. Useful for spawning larger tokens that might otherwise end up a half square off from grid.&nbsp; --v0.14 &nbsp;Corrected Mook behavior and added selected/target deletion and/or animation options. See post for details. --v0.15 &nbsp; Added&nbsp; random placement &amp; delete-after-expand options, and removed the qty limit. See post for details --v0.16 &nbsp; Added --rotation command. Only numeric values or the text "rand", "random" ar allowed --v0.17 &nbsp; Added --layer command. User may now specify the layer in which token(s) will spawn. Default behavior is the same layer as selected token(s) --v0.18 &nbsp; Added --isDrawing command. Also, --size will now accept either X,Y parameter or a single # (will set X=Y=#). --v0.19 &nbsp; Added --tokenName command, allowing the spawned token to have a different name than the default token and/or character name.&nbsp; --v0.20 &nbsp; Added&nbsp;support for non-70px grid scales --v0.21 &nbsp; Fix bug introduced by v0.19 that had broken compatibility with TokenNameNumber&nbsp; --v0.22 &nbsp; Bug fix. When only one value is given for --bar override, the bar max will now also default to the value given&nbsp; --v0.23 &nbsp; Added the --tooltip &nbsp;command --v0.24 &nbsp; Added the&nbsp; --controlledby &nbsp;and&nbsp; --tokenProps &nbsp;commands --v0.25 &nbsp; Added optional text to --targets command&nbsp; Available on One-Click , or Get the code here: <a href="https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js" rel="nofollow">https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js</a> Instructions Case 1: Selected token is the basis for spawn origin To use, select one or more tokens on the map, and call the script with at minimum the name of the "character" to summon. The following will simply spawn 1 of the default character tokens in the center of each selected token. !Spawn --name|charName Case 2: Target token is the basis for spawn origin Initial token selection is still required (as it is used for some defaults), but you can optionally cause the tokens to spawn at targeted token(s), with a little trickery. Roll20 has a standing bug that if both selected and target tokens are passed to an api script, the selected tokens are not retained. To get around this, after the initial call, the script will generate a chat button to prompt for a number of targets and will call itself again with the now complete set of information. &nbsp;!Spawn --name|charName --targets|2 A&nbsp; complete description of commands &nbsp;is included below. Note: I put &lt; &gt; around each of the parameters for readability. Don't include &lt; &gt; for actual use. ! Spawn {{ -- name | &lt; charName &gt; //(REQUIRED) name of the character whose target we want to spawn -- targets | &lt; #, optional Text &gt; //Destination override. Instead of using selected token(s) as origin, use target token(s). If commas are to be included in Text, use replacement value %comma% -- qty | &lt; # &gt; // DEFAULT = 1 . How many tokens to spawn at each origin point. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//supports hardcoded and rollable table inline rolls such as [[ 1d6 ]] and [[ 1t[tableName] ]] -- offset | &lt; #,# &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //X,Y pos or neg shift in position of the spawn origin point(s) relative to the origin token(s), in number of SQUARES &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//DEFAULT = 0,0 // (NOTE: a POSITIVE Y offset means LOWER on the map) --placement| &lt; option &gt; //How to arrange the tokens relative to the origin point (+ offset). Options are: //' stack ' : (DEFAULT) All tokens will be stacked on top of each other //' row ' : A horizontal row of tokens //' column , col ' : A vertical column of tokens //' surround ' : A clockwise spiral placement around origin token, starting at top (NOTE: any supplied offset will be ignored) //' grid #' : A square grid with "#" tokens per row. Raster left to right //' burst #' : An expanding diagonal distribution of tokens starting "#" squares from the 4 origin token corners. Large qty will form an "X" pattern // 'cross #' = "evenly" distributed vert/horiz cross pattern, starting directly above origin by # squares. Large qty will form a "+" pattern // 'random,rand #' : randomly populates tokens within a (# by #) square grid -- size | &lt; #,# &gt; or &lt; # &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// DEFAULT = 1,1 (X,Y) - How many SQUARES wide and tall are the spawned tokens? If only one number is given, X &amp; Y are set to equal size -- side | &lt; # or rand &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// DEFAULT = 1 . Sets the side of a rollable table token. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// # : Sets the side of all spawned tokens to "#" &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// 'rand,random' : Each spawned token will be set to a random side -- order | &lt; option &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //The z-order of the token. (NOTE: a recent Roll20 "feature" will always put character tokens with sight above those without, so YMMV.) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// toFront,front,top,above &nbsp;&nbsp;: Spawn token moved to front &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// toBack,back,bottom,below : Spawn token moved to back -- light | &lt; #,# &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//Set light radius that all players can see. // For Legacy Dynamic Lighting (LDL): &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //First # is the total radius of the light (light_radius)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Second # is the start of dim light (light_dimradius) (so: 10,5 will be 10 ft of total light, with dim radius starting at 5ft) // For Updated Dynamic Lighting (UDL): //First # is the radius of bright light (bright_light_distance) //Second # is the additional radius of dim light (so: 10,5 will be 10ft of bright light + 5ft of dim light) -- mook | &lt; yes/true/1/no/false/0 &gt;&nbsp;&nbsp;&nbsp;&nbsp;// DEFAULT = false (any linked bar values are retained) &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //If set to true, bar links are removed -- force | &lt; yes/true/1/no/false/0 &gt;&nbsp;&nbsp;&nbsp; // DEFAULT = false . The origin point is by default relative to the geometric center of the origin token &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Origin tokens of larger than 1x1 may spawn tokens in between squares, which may be strange depending on the specific case &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //Set to true in order to force the token to spawn in a full square -- sheet | &lt; charName2 &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // DEFAULT = selected character . The character sheet in which to look for the supplied ability &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//useful if the ability exists on a "macro mule", etc. -- ability | &lt; abilityName &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//The ability to trigger after spawning occurs. With caveats as described below --fx| &lt; type-color &gt; //Trigger FX at each origin point. //Supported types are: bomb,bubbling,burn,burst,explode,glow,missile,nova,splatter //Supported colors are: acid,blood,charm,death,fire,frost,holy,magic,slime,smoke,water --bar1| &lt; currentVal/optionalMax optional "KeepLink"&gt; //overrides the token's bar1 current and max values. Max is optional. Default is to remove bar1_link. If "KeepLink" is appended, the bar1_link will be preserved --bar2| &lt; currentVal/optionalMax optional "KeepLink"&gt; //overrides the token's bar2 current and max values. Max is optional. Default is to remove bar2_link. If "KeepLink" is appended, the bar2_link will be preserved --bar3| &lt; currentVal/optionalMax optional "KeepLink"&gt; //overrides the token's bar3 current and max values. Max is optional. Default is to remove bar3_link. If "KeepLink" is appended, the bar3_link will be preserved -- expand| &lt; #frames, delay , optional yes/true/1 &gt; //Animates the token during spawn. Expands from size = 0 to max size. If third param =true, will delete spawned token after animation completes //#frames: how many frames the expansion animation will use. Start with something like 20 //#frames: how many frames the expansion animation will use. Start with something like 20 //delay: how many milliseconds between triggering each frame? Start with something like 50. Any less than 30 may appear instant --deleteSource| &lt; yes/true/1/no/false/0 &gt; //DEFAULT = false. Deletes the selected token(s) upon spawn --deleteTarget| &lt; yes/true/1/no/false/0 &gt; //DEFAULT = false. Deletes the target token(s) upon spawn --resizeSource| &lt; #,# &lt;optional #frames, #delay&gt; &gt; //DEFAULT = n/a. Animates the selected token(s) during spawn. //#,#: the new size of the selected token(s). If any dimension is set to 0, it will delete the token after animation //#frames: DEFAULT = 20. how many frames the animation will use. //delay: DEFAULT = 50. how many milliseconds between triggering each frame? Anything less than 30 may appear instant --resizeTarget| &lt; #,# &lt;optional #frames, #delay&gt; &gt; //DEFAULT = n/a. Animates the target token(s) during spawn. //#,#: the new size of the target token(s). If any dimension is set to 0, it will delete the token after animation //#frames: DEFAULT = 20. how many frames the animation will use. //delay: DEFAULT = 50. how many milliseconds between triggering each frame? Anything less than 30 may appear instant --rotation| &lt; #/random/rand &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//sets the angle of the spawned token during runtime --layer| &lt; object/token/map/gm &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;//user may specify the layer in which token(s) will spawn. Default behavior is same layer as selected tokens --isDrawing| &lt; yes/true/1/no/false/0 &gt; //DEFAULT = false. Sets the isdrawing property of spawned token --tokenName| &lt; some name &gt; //optional override for the token name - allows token name to be different than the character name --tooltip| &lt; some text &gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// adds a tooltip to the spawned token(s) --controlledby| &lt;optional +&gt; &lt;comma-delimited list of playerIDs or displayNames&gt; //adds or replaces the controlledby property of the CHARACTER SHEET defined by the --name command --tokenProps|&lt;prop1:val1,prop2:val2...&gt; //sets various token properties. Valid properties include: name,statusmarkers,bar1_value,bar1_max,bar2_value,bar2_max,bar3_value,bar3_max,top,left, width,height,rotation,layer,aura1_radius,aura1_color,aura2_radius,aura2_color,aura1_square, aura2_square,tint_color,light_radius,light_dimradius,light_angle,light_losangle,light_multiplier, light_otherplayers,light_hassight,flipv,fliph,bar1_link,bar2_link,bar3_link,represents,layer, isdrawing,name,gmnotes,showname,showplayers_name,showplayers_bar1,showplayers_bar2,showplayers_bar3, showplayers_aura1,showplayers_aura2,playersedit_name,playersedit_bar1,playersedit_bar2, playersedit_bar3,playersedit_aura1,playersedit_aura2,lastmove,tooltip,show_tooltip, adv_fow_view_distance,has_bright_light_vision,has_night_vision,night_vision_distance, emits_bright_light,bright_light_distance,emits_low_light,low_light_distance,has_limit_field_of_vision, limit_field_of_vision_center,limit_field_of_vision_total,has_limit_field_of_night_vision, limit_field_of_night_vision_center,limit_field_of_night_vision_total,has_directional_bright_light, directional_bright_light_center,directional_bright_light_total,has_directional_dim_light, directional_dim_light_center,directional_dim_light_total,bar_location,compact_bar, light_sensitivity_multiplier,night_vision_effect,lightColor }} The --placement option&nbsp; is the trickiest one to describe, so here is a reference chart to show how --placement and --offset relate to each other for multiple tokens. Note how the --offset command is ignored for the --placement|surround option. Here is a completely unrealistic example from a game mechanics standpoint, spawning 1d4+1 Dancing Lights or Flaming Spheres in a burst 1 pattern originating three squares below a target token, then triggering the "SpellTemplate" ability on the "Yelric" character sheet. !Spawn supports multi-line commands using the double bracket syntax. Also, will support case insensitive search and allows extra spaces between commands, parameters and delimiting characters ("--", "|", and ","), so the following will still work: !Spawn {{ --naMe | GenericSpellAoE --targeTs |1 --qty| [[ 1d4 + 1 ]] --offset | 0 , 3 --placement| buRst 1 -- size|1,1 --side| ?{Spell?|Dancing Lights,7 |Flaming Sphere,2} --order | toFront --light| 10,-5 --force|yes --sheet|YeLriC --ability|SpellteMplAte }} Caveats/Known Issues 1) Like with any other scripts that affect images, Roll20 limits api access to&nbsp; only images found in the user's personal art library . Annoying. So, if you have purchased Marketplace content, you will have to go through the arduous process of getting those images into your "My Library". Select token, press Z, right-click, save image locally, then re-upload to Roll20. 2) Also not currently accessible by the api are:&nbsp; Bar position &amp; bar styles . So, no compact bottom overlapping bars for your spawned mooks until Roll20 allows that to happen. 3) The&nbsp; Ability triggered after spawning &nbsp;is currently pretty temperamental. This is irritating because it was one of the main features I was looking for. The following seem to cause problems: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; a) When the ability contains a query, things break. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; b) When the ability is whispered, it just gets ignored (?!). I don't fully understand this. I have a cheesy workaround that kinda works but is not yet implemented, as it forces the whisper to the player that made the api call. This probably would be ok for 99% of cases, but I'd like it to be more generic. There is a forum thread&nbsp; here &nbsp;that discusses the issue. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; c) If the ability calls another ability or macro either directly or via chat buttons, things break. Chat buttons will be created, but will fail when clicked &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; NOTE: If anybody wants to wade through any of these Ability issues, it is found at the very bottom of the processCommands function. Search for the comment " automatic trigger of a supplied ability " to jump directly to that portion of the code. Links to more Examples with animated gifs: Example &nbsp;used in conjunction with another of my scripts (DLDark) to cast a cloudkill that heavily obscures (old thread) Example&nbsp; using spawn "animations" and fx (old thread) Example &nbsp;using bar override values (old thread) Examples &nbsp;using source token resize and/or deletion (current thread) Example &nbsp;use with the scriptcards api script to simulate random placement (current thread) Example with built-in support for random token placement and deleting the spawned token after animation&nbsp;(current thread) Example to change scenes for Theater of the Mind sessions (current thread) Examples &nbsp;for random placement and deleteafterexpand options Example for the 5e Conjure Animals Spell (requires other scripts, see "Option 2" of the link)

Version 0.10 (Bug fix) Thanks to Nick O. and The Aaron for discovering &nbsp; --v0.10&nbsp; bug fix for certain cases where the default token does not have layer information. Now explicitly sets the spawn layer to that of the origin token(s). Side benefit: can now spawn on non-object layers (e.g. GM layer).

I love this script, David! I'm trying to create a cloud of daggers effect, but am having some trouble. I've created a rollable table called magicWeapons and have added an image of a dagger from my library to that table. I've selected a token on the battle field and entered the following command. !Spawn{{ --name|magicWeapons --qty|8 --placement|surround --side|1 }} However, when I run this, the tokens don't appear, no messages appear in the chat window, and no errors appear in the API Output console. I'm able to summon monsters and PC tokens successfully, it's just the rollable table that seems to be giving me trouble. Does the token being summoned have to be attached to a character sheet?

Thanks, glad you are enjoying it! Yes, the script spawns the default token for a character sheet, which can include a rollable table token. What you have should work once you attach to a "magicWeapons" character sheet. I do the same for Spell Effect Templates.&nbsp; Also, I often make token action abilities on the spawned character sheet to handle the attacks/damage for the various sides of the rollable token.&nbsp; EDIT -- Looks like my error handling is not correctly returning a message to chat when no character sheet is found. I'll look into it.&nbsp; EDIT 2 -- corrected in v0.11. Updated Gist above&nbsp;

Version 0.11 (Updated error handling) --v0.11 Corrected error handling for cases when no character sheet is found or when the requested auto-trigger ability is not found.&nbsp;

Fantastic, thanks, David!

Ugh, looks like I accidentally dropped the .js extension on the latest version of the script (v0.11) that just got updated in the one click. SpawnDefaultToken is currently broken on one click until this is resolved, and will return this error when the sandbox spins up: No such file or directory @ rb_sysopen - /home/symbly/www/d20-app/apiscripts/Spawn Default Token/0.11/SpawnDefaultToken.js In the meantime, you can manually add the script from the following: <a href="https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js" rel="nofollow">https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js</a> &nbsp; UPDATE This issue was resolved and v0.11 should be working again via one-click

This script is spawning my party with less hp and changing their sheets to match that.

Hm, never thought about using it to spawn party members, but the principle is the same. It is spawning the default token for the relevant character sheet. It is likely that the default PC tokens have a bar1 value (or whatever bar you are using) that is lower than their current hp total (e.g. the default token was saved, then they leveled up). The script finds all the characteristics of the default token and applies it to the spawned token. If the bar is linked to the characters' hp (extremely likely), then the sheet will be updated accordingly, giving the unwanted effect you are describing. I verified that what you described will happen if the default token is outdated. So, if you want to continue using the script to spawn party members, you will have to update their default token first. Caveat: even if the characters' default token was saved upon leveling, their current hp might be lower due to damage, so spawning a damaged PC would have the reverse effect, and update the hp to the [higher] default token value.&nbsp; I'm curious, in what scenario are you using the script to spawn party members? It was not intended to be used as a pseudo-teleport script, but rather a means to spawn spell effects, summoned creatures, and the like.

Thanks for the reply. Nick O who posted above has a YouTube video where it’s demonstrated as a novel way to bring your party onto a map without having to pull them out of the journal one by one. &nbsp;Does seem like it would be useful for that if we could get around the hp issue.

Ah, got it, thanks for the info. Interesting application that I had never thought of. Note there *is* the ability to override the bar values from those of the default token, but in doing so the script currently removes the bar link to the character attribute. The intent was to avoid screwing up the character's sheet statistics, although it inadvertently caused a similar issue in reverse for this application!&nbsp; From the command argument list above: --bar1| &lt; currentVal/optionalMax &gt; //overrides the token's bar1 current and max values. Max is optional. If overridden, bar1_link will be removed --bar2| &lt; currentVal/optionalMax &gt; //overrides the token's bar2 current and max values. Max is optional. If overridden, bar2_link will be removed --bar3| &lt; currentVal/optionalMax &gt; //overrides the token's bar3 current and max values. Max is optional. If overridden, bar3_link will be removed I will look into adding additional syntax to these commands to override the default values and still retain the links, but for the time being the --bar# commands above might be a somewhat imperfect option for you. Thanks again!

Thanks for this!

Version 0.12 - Additional options for token bar override commands With Nick O.'s recent youtube video regarding using the script to spawn the PCs onto new maps, it revealed behavior in Roll20's api-accessible json for default tokens which can cause the current and max hp to be incorrectly adjusted and synced to the character sheet via token bar links. I can't go into detail here (honestly still seems a little wonky to me), but have a workaround for those who wish to use the script in this manner. A little history: As I mentioned above, the previous --bar1, --bar2, etc. commands can override the default values stored in the default token json and apply them to the spawned token. However, when this was first implemented, it was for cases like the 5e fighter subclass Echo Knight which creates a duplicate of the character but with different hp &amp; AC. Previous versions of SpawnDefaultToken thus automatically removed the token-bar-to-character links from the spawned token in these cases so as to not incorrectly set the original character's attributes. What's new: v0.12 now introduces an additional keyword (" KeepLink ", not case sensitive) that can be placed after the --bar commands which will overwrite the bar values, but keep the token-bar-to-character links .&nbsp; So, in order to spawn a new copy of a PC that will preserve their current and maximum hp/ac/etc., you can now use syntax such as this, where /maxVal and the text "KeepLink" remain optional. --bar1|currentVal/maxVal KeepLink If "KeepLink" is omitted, the bar values will be automatically unlinked as normal, so it shouldn't break anyone's existing macros. Example Here's an example for a case where bar1 is linked to hp, bar2 is linked to ac, and bar3 is linked to temp hp. The existing character values are populated for the spawned token and the links for all three bar values are retained in this example. !Spawn {{ --name|CharName --offset|1,0 --bar1|@{CharName|hp}/@{CharName|hp|max} KeepLink --bar2|@{CharName|ac} KeepLink --bar3|@{CharName|hp_temp} KeepLink }} Note that other token properties such as status markers, vision, etc. will still use whatever was set the last time the default token was saved for the character. I don't know of an easy-to-use, flexible/dynamic, and reliable way to determine which version of the character token is being spawned, as there might be 20 different versions on different pages. Everything I can think of will probably end up taking more time than just dragging them out from the journal! A teleport script might be more appropriate for these cases. Until it is available on the one-click, here is the Gist for v0.12 <a href="https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js" rel="nofollow">https://github.com/djmoorehead/roll20-api-scripts/blob/master/Spawn%20Default%20Token/SpawnDefaultToken.js</a> I will wait and not push this out to tomorrow's update to give some time for review in case there are any unforseen issues that may arise.

David M. said: What's new: v0.12 now introduces an additional keyword (" KeepLink ", not case sensitive) that can be placed after the --bar commands which will overwrite the bar values, but keep the token-bar-to-character links .&nbsp; So, in order to spawn a new copy of a PC that will preserve their current and maximum hp/ac/etc., you can now use syntax such as this, where /maxVal and the text "KeepLink" remain optional. --bar1|currentVal/maxVal KeepLink If "KeepLink" is omitted, the bar values will be automatically unlinked as normal, so it shouldn't break anyone's existing macros. Quick question - is there a object-referencing API-script version of this so, hypothetically, if somebody had your default-token-spawning script and my Teleport script, Teleport could check for your JavaScript object, and if present, automatically attempt to spawn a player token in a cross-page teleport that it detected did not yet have a token?&nbsp;

Okay. so... here's a thought. Using Teleport or anything else as a trigger on an overland map for an "all players" token - the players are able to move the "party" token around, and if they want to visit a town, they plonk the token down, get a pop-up that says "visit town?" and if they click yes, the teleport script is fired for all active players, creating their tokens on the associated combat map of the town and moving all the players there at the same time... just thinking of a nearly autonomous movement system where players can alternate between in-town battlemaps and overland maps without the GM doing a lot of ribbon moving...&nbsp;

Pat said: Quick question - is there a object-referencing API-script version of this so, hypothetically, if somebody had your default-token-spawning script and my Teleport script, Teleport could check for your JavaScript object, and if present, automatically attempt to spawn a player token in a cross-page teleport that it detected did not yet have a token?&nbsp; Currently, no. However, Timmaugh has an interesting script that could make that easier to implement. I just haven't had a solid block of time to figure it all out.

David M. said: Pat said: Quick question - is there a object-referencing API-script version of this so, hypothetically, if somebody had your default-token-spawning script and my Teleport script, Teleport could check for your JavaScript object, and if present, automatically attempt to spawn a player token in a cross-page teleport that it detected did not yet have a token?&nbsp; Currently, no. However, Timmaugh has an interesting script that could make that easier to implement. I just haven't had a solid block of time to figure it all out. Oh I was thinking of a direct call - Teleport at the point it checks for an associated token has the playerID and the characterID elements - so if there was a way to call it and give it a location (the target teleport pad left and top) and page (the target teleport pad token id's page id)... I could pass all of that along to a public interface...&nbsp;

Right, Timmaugh's solution is a helper script of sorts. He worked with TheAaron to propose a way to kind of standardize the way that scripts call other scripts and "avoid bloat in the State object". Check out the link in my previous post for more details.&nbsp;

David M. said: Right, Timmaugh's solution is a helper script of sorts. He worked with TheAaron to propose a way to kind of standardize the way that scripts call other scripts and "avoid bloat in the State object". Check out the link in my previous post for more details.&nbsp; No, I know - the point being I don't want to have to use the msg interface, and instead skip to a direct check&nbsp; if(createdefaulttoken){ and if true, a function call on the object createdefaulttoken.createtoken(characterid,pageid,xyobj); to avoid the delay of going back through the chat interface - and hand over exactly what the function needs. That's different than a chat api call, or providing an object to hand over - just calling a function.&nbsp;

YouTube Demo Video by Nick O! Wanted to thank Nick O. for the great demo video highlighting a few of the features of this script. Check it out here !&nbsp;&nbsp; Note: If you want to use the script for spawning the party on a new page as he details, I'd recommend something along the likes of the following to avoid inadvertent alterations to your PC's linked bar values (hp, ac, etc.) as described above&nbsp; here . His video was using a previous version (v0.11), and that particular application of the script revealed some strange behavior that prompted changes in v0.12.&nbsp; Remove or modify the bar value commands as needed: !Spawn {{ --name|CharName --offset|1,0 --bar1|@{CharName|hp}/@{CharName|hp|max} KeepLink --bar2|@{CharName|ac} KeepLink --bar3|@{CharName|hp_temp} KeepLink }} Thanks, Nick!

David M. said: YouTube Demo Video by Nick O! Wanted to thank Nick O. for the great demo video highlighting a few of the features of this script. Check it out here !&nbsp;&nbsp; Thanks, Nick! My pleasure!

Pat said: No, I know - the point being I don't want to have to use the msg interface, and instead skip to a direct check&nbsp; if(createdefaulttoken){ and if true, a function call on the object createdefaulttoken.createtoken(characterid,pageid,xyobj); to avoid the delay of going back through the chat interface - and hand over exactly what the function needs. That's different than a chat api call, or providing an object to hand over - just calling a function.&nbsp; Gotcha. I haven't exposed a function in that way before (only picked up js a few months ago). From looking at some other scripts, it looks like I could just add a return value to the script, something like return { &nbsp; &nbsp; // public interface &nbsp; &nbsp; SpawnDefault: spawnTokenAtXY }; A couple of things, though. The function that currently does the dirty work is called asynchronously, as it is potentially called many times in a nested loop for multiple origin tokens and multiple quantities spawned per origin. I had all kinds of timing-related problems when not async. Do you know if that would cause a problem when exposed? Also, the function currently takes 25 parameters(!), so there's that. The perils of feature bloat ;) Line 137 of version 0.12: &nbsp;async function spawnTokenAtXY (who, tokenJSON, pageID, spawnLayer, spawnX, spawnY, currentSideNew, sizeX, sizeY, zOrder, lightRad, lightDim, mook, UDL, bar1Val, bar1Max, bar1Link, bar2Val, bar2Max, bar2Link, bar3Val, bar3Max, bar3Link, expandIterations, expandDelay) { parameters: who tokenJSON pageID spawnLayer spawnX spawnY currentSideNew sizeX sizeY zOrder lightRad lightDim mook UDL bar1Val bar1Max bar1Link bar2Val bar2Max bar2Link bar3Val bar3Max bar3Link expandIterations expandDelay

I'm very glad I checked in here! I had abandoned King's old Summon script for precisely the reason you state above. Summoning PCs was always problematical. I mostly wanted to have the ability to bring the party to a map in one fell swoop. This sounds like just what I need, now.

Great, Keith!

Hello! I recently found this useful API, to summon creatures with summoning spells and abilities. But when i tried to summon using bottons, it didn't work to summon a random amount of monsters. For example, if I set --qty|[[1d4+1]] in this botton: [Dog](!Spawn --name|Celestial Dog --targets|1 --qty|[[1d4+1]] --placement|surround --size|1,1 --side|1 --order|toFront --expand|5,50) It always summons only 1 dog. I'd like to know if there's any way to do it without making the abilities one by one.

Daniel, you seem to be running into a limitation of Roll20 chat menu buttons. When I look at the actual text being sent to the api after clicking the button, the value for the qty parameter is a text string e.g. "Rolling 1d4+1 = (4)+1'&gt;5", instead of just the number rolled. When the script performs a parseInt on the qty, it will only return the first number in the string ("1" in this case). The good news is that you can still use a chat menu to organize your summoning spells. The bad news is that you will need to make several abilities. Solution Instead of putting the text of the api calls directly into the command button, create a set of abilities on your character sheet: one for each creature type your want to summon, and one forward-facing master ability that creates the chat menu and references the individual abilities. Simple Example Sub-ability 1: " SummonDog " - just a worker ability (don't make this one visible to macro bar or token action)&nbsp; !Spawn --name|Celestial Dog --targets|1 --qty|[[1d4+1]] --placement|surround --size|1,1 --side|1 --order|toFront --expand|5,50 Master ability: " SummonMenu " - this is your forward-facing ability (make this one a token action or "Show in macro bar") &amp;{template:default} {{name=Choose a creature to summon}} {{Choose=[Dog](~SummonDog)}} You can add additional sub-abilities and expand your SummonMenu as needed, and use the template of your choice. I just used the default template in the example above.

David M. said: Daniel, you seem to be running into a limitation of Roll20 chat menu buttons. When I look at the actual text being sent to the api after clicking the button, the value for the qty parameter is a text string e.g. "Rolling 1d4+1 = (4)+1'&gt;5", instead of just the number rolled. When the script performs a parseInt on the qty, it will only return the first number in the string ("1" in this case). The good news is that you can still use a chat menu to organize your summoning spells. The bad news is that you will need to make several abilities. Solution Instead of putting the text of the api calls directly into the command button, create a set of abilities on your character sheet: one for each creature type your want to summon, and one forward-facing master ability that creates the chat menu and references the individual abilities. Simple Example Sub-ability 1: " SummonDog " - just a worker ability (don't make this one visible to macro bar or token action)&nbsp; !Spawn --name|Celestial Dog --targets|1 --qty|[[1d4+1]] --placement|surround --size|1,1 --side|1 --order|toFront --expand|5,50 Master ability: " SummonMenu " - this is your forward-facing ability (make this one a token action or "Show in macro bar") &amp;{template:default} {{name=Choose a creature to summon}} {{Choose=[Dog](~SummonDog)}} You can add additional sub-abilities and expand your SummonMenu as needed, and use the template of your choice. I just used the default template in the example above. ohhh!!!! thanks for answer me! I will do that!

Has Version 0.12 been pushed to One click? The KeepLinks does not seem to work with the one click install. The 0.12 from github does work as intended though.&nbsp; Edit I see you were holding off I missed that:)

Mark, it should be on one-click next Tuesday!

Sounds good.&nbsp; Yep edited to remove that and put that in the proper thread. Probably should not post late at night..lol Thanks David

Wrong thread? Sounds like you are referring to the Teleport script? Pat (the Teleport author) was commenting on their script here a while ago (regarding possible synergy with !Spawn), so I can understand the mix-up ;)

Hey David, youtube commenter here from Nick's Video. I tried adding the "light command" to the script but the vision STILL keeps coming up as -999ft for every token. Even token I grab from other sources. No idea how to fix

If you drag a token from the journal manually and open the light settings, what do you see? Also, it shouldn't matter, but are you using UDL or LDL? EDIT - The script just copies all of the token settings from the default token for the character in question, unless otherwise explicitly overriden by the player calling the script (and then only for certain properties like bar values or emitted light - not vision). If the default token has -999ft, then so will the spawned token.&nbsp;

David M. said: If you drag a token from the journal manually and open the light settings, what do you see? Also, it shouldn't matter, but are you using UDL or LDL? EDIT - The script just copies all of the token settings from the default token for the character in question, unless otherwise explicitly overriden by the player calling the script (and then only for certain properties like bar values or emitted light - not vision). If the default token has -999ft, then so will the spawned token.&nbsp; David , I ran into this to. It appears that on spawned tokens its not respecting the values of the default token thats tied to the character sheet.&nbsp; Example: Normal token dragged from Journal it has darkvision to 60ft using LDL. Example Spawned token- It sets the token -999 -999 for light and dim radius and check the box for all players see light.&nbsp; Note I can use the --light| parameter and it will set the fields but for creatures that have darkvision or in the cause of using it like Nick O example this can be problem as some will only have light multiplier for low light and should not have all tokens see light checked.

Posting second image here again for some reason the first image was ok, the second not so much.

Blerg, I can now reproduce this behavior. It always worked before, but it seems like the JSON for the defaulttoken no longer has any light settings in it (except night_vision_tint). I wonder if something got hosed during all of lighting updates the Devs have been making. The script grabs the default token and spawns an exact copy of it. Since it doesn't currently exist in the default token JSON string, it doesn't exist in the spawned copy. I'll start a thread on the bug report forum and see if I can get to the bottom of this. Thanks, guys. EDIT - here is the link to the bug thread if you want to follow. EDIT 2 - NM, I was confused by what I was seeing. Good news is I found the problem and made a patch!&nbsp; &nbsp;

Version 0.13 - Bug fix for light settings Thanks to Brannon and Mark for pointing out a problem with light settings. I believe it has been corrected. The new version can be found here or through the Github link in the first post.&nbsp; Note: when testing in UDL using Ctrl-L, there is still the quirk of the UDL emitted light isn't "visible" to the sighted token until the light-emitting token is moved. Should work as expected if you "re-join as player"&nbsp; If this all checks out, I will put in a pull request to get v0.13 into the one-click on Tuesday.

I can confirm Version 0.13 is respecting the token light settings. now for LDL. I have not personally tested with UDL yet.

Can confirm it's working for me, too! Is the script supposed to be able to get a token's default size as well? I tried spawning a token with default size 2*2 sq and it was spawned as 1*1 sq (using --size|2,2 worked fine).

Persephone said: Can confirm it's working for me, too! Is the script supposed to be able to get a token's default size as well? I tried spawning a token with default size 2*2 sq and it was spawned as 1*1 sq (using --size|2,2 worked fine). I believe the script default to 1x1 size if you do not specify. any size at all. Otherwise I have seen the script report back that its expecting formart --size|#,#. I have not tested the 2*2 format in the literal sense but my guess would be that unless you express it as --size|#.# it will spawn as 1x1.&nbsp;

David,&nbsp; I have&nbsp; suggestion that might be of use to some. With Nick O example spawning tokens of varying size's&nbsp; can be problemmatic if the spawned token is larger than token it was spawned from.&nbsp; Example, you have party of 5, all but 1 is a single 1x1 token. Those align perfectly. The&nbsp; 5th token is actually 4x4 and no matter where you place the offset it centered geometrically from the originating token, even if you use --force|yes its not snapped to grid.. Is it possible to get it to snap to the nearest grid based on a parameter such as --snapto|Top, Right, Left, Bottom and have aligned to the grid from the nearest offset of the geometric center of the spawning token?

Glad to hear it is working for you guys! 1) Wanted to confirm Mark's comments about the default size being 1x1&nbsp; 2) Regarding fitting to grid for odd combinations of source and spawned token sizes: Every time something like this changes, it is a ton of math due to all of the different spawn placement options. As a quick solution, I just put out a hot fix (v0.13a - same GitHub link) that reads the offset distances in as a floating point number instead of an integer. So, you can now spawn tokens with centers that are half squares away to ensure they arrive fully in a square, e.g: !Spawn {{ --name|Big Bubba -- offset|2.5,0.5 --size|4,4 }}

David M. said: Glad to hear it is working for you guys! 1) Wanted to confirm Mark's comments about the default size being 1x1&nbsp; 2) Regarding fitting to grid for odd combinations of source and spawned token sizes: Every time something like this changes, it is a ton of math due to all of the different spawn placement options. As a quick solution, I just put out a hot fix (v0.13a - same GitHub link) that reads the offset distances in as a floating point number instead of an integer. So, you can now spawn tokens with centers that are half squares away to ensure they arrive fully in a square, e.g: !Spawn {{ --name|Big Bubba -- offset|2.5,0.5 --size|4,4 }} David that works perfectly !!! Thanks for all the hard work you put in.&nbsp;

Update on one-click progress: Despite my pull request being approved 8+ days ago, the new version didn't make it into the one-click yesterday (for 3 of my scripts, actually). I'm going to put in a Help Desk request to try to figure out what went wrong. I probably did something stupid. In the meantime, you can do a manual install to get the latest version live in your game. Disable the one-click version Go&nbsp; here &nbsp;and copy the code for the v0.13a Go to your scripts and click New Script Paste code in the window and rename Click Save Script and you should be good to go! When one-click is updated, just delete the manual script and re-enable the one-click version.

Hey guys! Not sure if any of you have checked out the Scriptcards script yet (the successor to Powercards), but GM Goss and Kurt J have come up with a cool scriptcard application that highlights the synergy of the two scripts. This link shows how to create a solution for pulling multiple creatures out of a D&amp;D "Bag of Tricks" (Magic item- you pull an token from a bag and it forms into a random beast). The scriptcard queries for the number of times to pull (up to 3 in this example), and loops through, calling the Spawn script multiple times (one for each random creature) and adjusting the offset command argument appropriately. This is a fairly advanced example of scriptcards, so don't let that intimidate you! There is another example a little farther up that might be a little easier to follow if you're new to scriptcards, but it may spawn some tokens on top of each other. Anyway, just wanted to share because I thought it was really cool!&nbsp;

David - what would you think about a --controlledby| option that would allow you to set the token's controlleby property for mooks? Maybe it could take a playerid (or a token/character ID and do the lookups to get the controlling player) and, if the --mook|yes is set update the controlledby for the spawned tokens? This would allow things like the Bag of Tricks to assign control of the spanwed tokens to the person who pulled them out of the bag.

That's a good idea, Kurt. The script already has the calling player's id for the purpose of whispering error messages. Do you think there would be a case where the calling player *wouldn't* want control, or think I should I just always default it that way? Maybe if the GM spawns the token for a player, I suppose? I might be able to work on this late tonight or tomorrow.&nbsp;

In the process of looking into this, I realized that I was treating mooks incorrectly! The script currently removes the represents property of the token, when it should instead be removing the token bar links to character attributes. This will be corrected in the next version. Kurt, thinking about this some more: when the token represents a character, controlledby is based on character sheet settings. If I add to the control list of the sheet, that sheet will have the modified settings until removed manually or via api. So if I summon a Dire Wolf from the Bag of Tricks, all other Dire Wolves will also be controlled by the player until control is removed. I could keep the "incorrect" mook treatment (removal of the represents property) and change the token controlledby, but then the player wouldn't be able to use the sheet's token actions or make attacks/checks directly from the npc sheet. I could keep represents, and write to State to track the tokenID of the spawned creature and remove the player from controlledby when the token is deleted, but that is potentially problematic for most cases where the summoned token is supposed to always be set up with player control. So, this would probably require yet another command (e.g. --removeControlOnDelete or something) to only do this when wanted. I'm wondering if this is all going to cause more headaches and confusion for folks as they figure out what the right combination of settings would be for the specific application. For my players currently, I create renamed copies of potentially summoned creatures (e.g. impPlayer) and assign control appropriately, then just have them spawn the copy. This seems like the safest process given the reasons above.&nbsp; Thoughts?

David M. said: In the process of looking into this, I realized that I was treating mooks incorrectly! The script currently removes the represents property of the token, when it should instead be removing the token bar links to character attributes. This will be corrected in the next version. Kurt, thinking about this some more: when the token represents a character, controlledby is based on character sheet settings. If I add to the control list of the sheet, that sheet will have the modified settings until removed manually or via api. So if I summon a Dire Wolf from the Bag of Tricks, all other Dire Wolves will also be controlled by the player until control is removed. I could keep the "incorrect" mook treatment (removal of the represents property) and change the token controlledby, but then the player wouldn't be able to use the sheet's token actions or make attacks/checks directly from the npc sheet. I could keep represents, and write to State to track the tokenID of the spawned creature and remove the player from controlledby when the token is deleted, but that is potentially problematic for most cases where the summoned token is supposed to always be set up with player control. So, this would probably require yet another command (e.g. --removeControlOnDelete or something) to only do this when wanted. I'm wondering if this is all going to cause more headaches and confusion for folks as they figure out what the right combination of settings would be for the specific application. For my players currently, I create renamed copies of potentially summoned creatures (e.g. impPlayer) and assign control appropriately, then just have them spawn the copy. This seems like the safest process given the reasons above.&nbsp; Thoughts? That makes sense (the alternative characters). That would even work for things like spell effects with a character controlled by All Players so they can move it around.

Hey David M. Loving this script, have found an amazing amount of uses for it! Thank you so much. I have been using the new Combat Master script, not sure if your familiar but this API is immense. I would like to link !spawn and !cm in a really clever way. *See below thread*. What is possible as a result is the !spawn of Area of Effect markers ect automatically when you add spell conditions to a token via Combat Master and would be INCREDIBLE for speed of gameplay in combat, having conditions added and AOE markers spawning for those spells simultaneously, all with the press of one button. Please let me know if this is possible. Thank you! Abazigal Pro Persephone said: Abazigal said: Hi all, I'm having some troubles understanding how the syntax of the api box when you add or remove a condition. Upon applying the condition/spell, such as Banish I want TokenMod to send the Combat Master 'target' of the spell to the GM Layer, as if they have dissapeared from existance, and to re-appear on the token layer upon the clearing of that condition. How do I EXACTLY write that INTO that box, to have it do that {{ }} included? I'm struggling to find any guide or post on this in all the threads. For TokenMod commands, you'll first need to set up substitutions for player ID and token ID in the Macros &amp; API config menu (might as well set up character ID and character name subs while you're at it), then use those substitutions in the command like this: {{!token-mod {{--api-as &lt;PIDsub&gt;}} {{--ids &lt;TIDsub&gt;}} {{--set layer|gmlayer}} }} Insert your substitutions in place of &lt;PIDsub&gt; and &lt;TIDsub&gt;. The double curly braces {{ }} are there as buffers, and get stripped away after entering it, so they're supposed to be missing from the final display like in your screenshot. _______________________________________________________________________________________ Amazing Persephone , thank you, that is working now!!! Ok, I have something else you could tighten up for me pleaseeeee. I have set up all AOE markers as characters with default tokens set relating to the spell AOE, as you do... I want the 'Add API' function of CombatMaster to !Spawn to spawn this 'character' AOE template upon applying the condition, lets call it spirit guardians, which dumps the 'character', the spell AOE marker onto the player. Like this; This is my current syntax, however it is failing to do what it should. What am I missing? {{!Spawn {{--name|Spirit Guardians}} {{--size|7,7}} {{--order |toBack}} &nbsp; {{--expand|10,8}} }} Thanks Persephone _______________________________________________________________________________________ Persephone Pro @Abazigal, the Spawn script requires a token to be selected and when script commands are sent through the API as CM does, that info isn't carried through. That's what the substitutions are for, but Spawn doesn't have a way to specify the origin point token by ID, it just assumes you have one selected when your run the command. You could request that functionality be added to the Spawn script in its main thread. If works like TokenMod, it might also need a new parameter for specifying player ID. _______________________________________________________________________________________