[Script] 5e Shaped Support Script

NEW THREAD: <a href="https://app.roll20.net/forum/post/3268053/5e-shape" rel="nofollow">https://app.roll20.net/forum/post/3268053/5e-shape</a>...

I discussed this with Lucian and this effort has my full support. I'll probably be involved, but with someone else taking the reigns it will definitely help me as my time is limited. Upgrading existing characters is entirely for sheetworkers to handle - don't do it in API please. As mentioned in PMs the import for spells and monsters is largely handled by the sheet - the scripts just need to put the info in the right spot.

This sounds awesome Lucian! &nbsp;Thank you! &nbsp;Don't risk the wrath of domestic management...&nbsp; I am not a hardcore coder like many here, but if there is anything I can do to help I would be happy to!

10.5) Import from Actoba's sheet....? &nbsp;=D

@Aaron Importing is part of the converting which should happen on sheetworkers. I'll accept pull requests though. :)

I do feel like I've got a better handle on Gulp now... Hmmm

Excitedly keeping track of this, not sure about moving over before everything is nice and movable.

FYI Lucian I'm going to swap ammo to be like the OGL sheet with ammo separately tracked from each individual item. We'll need the API to hook this together. Also I'd suggest we name this "companion" instead of "support".

Kryx said: FYI Lucian I'm going to swap ammo to be like the OGL sheet with ammo separately tracked from each individual item. We'll need the API to hook this together. Ok. Does that mean using an !ammo command in freeform on the attack to update an entry in the inventory? Or did you have something more "automatic" in mind? AFAICT the OGL sheet doesn't provide any support at all for ammo but I'm not familiar with any scripts that people may have created to support it. As you know, I personally have a preference for not embedding api commands in character attributes to support this kind of thing; I'd rather store some sort of more declarative linkage between the two fields, either as something in API state (not ideal, because it doesn't travel with the character object) or, for preference, in an attribute on the character itself. So I would probably want to do something like: Run API command with token selected API looks for ranged attacks (perhaps we could have a checkbox for "hasAmmo" on each attack?)&nbsp; API automatically creates an equipment entry for the attack API stores the ID of the equipment entry as a new attribute attached to the attack (If you were feeling nice) the sheet could output the equipment entry ID out when the attack is rolled, as a non-displayed field in the rollTemplate. But I know how you feel about that sort of thing ;-) API script can automatically respond to attack rolls based on the linkage information embedded in the attributes There could also be a manual "link ammo" command that could display a roll query containing a list of all attacks and another with equipment items and then link them up the pair you select. Or did you have something specific in mind?

RMcD said: Excitedly keeping track of this, not sure about moving over before everything is nice and movable. For the avoidance of doubt, this script &nbsp;will not &nbsp;upgrade characters from the old version of the shaped sheet to the new one. That functionality will be part of the sheet itself, using sheet worker scripts, once Kryx implements it - it's on his todo list.&nbsp; What the script will do is allow you to import characters/monsters from the MM text format and a JSON format (as was possible using the old script). It will also handle a few peripheral bits like ammo, automatic HP rolling for monsters, and any other convenience functions that help setting up characters with the sheet. That functionality is well on the way now, I have the parsing largely working, but I still have a few areas to complete and I want to do a lot of testing before I release it. I guess it might be another week or so.

See&nbsp; <a href="https://app.roll20.net/forum/post/3078601/5th-edit" rel="nofollow">https://app.roll20.net/forum/post/3078601/5th-edit</a>... for their new ammo tracking stuff. They have named resources and then in each attack specify which ammo resource to use. The script then searches for a resource by that name and reduces 1 from it. Fairly simple and works well. I just need to add some ammo fields.

Kryx said: See&nbsp; <a href="https://app.roll20.net/forum/post/3078601/5th-edit" rel="nofollow">https://app.roll20.net/forum/post/3078601/5th-edit</a>... for their new ammo tracking stuff. They have named resources and then in each attack specify which ammo resource to use. The script then searches for a resource by that name and reduces 1 from it. Fairly simple and works well. I just need to add some ammo fields. Oh cool, I hadn't seen that - have had been too buried in parser writing to follow the forums :-) Looks nice - more than I'd hoped for. Will get on it once you've added the ammo stuff to the sheet. Looks like I will have some catching up to do with spell slots etc as well - although I'm interested to see how they've done those, because it's actually fiendishly complicated to do it right once you take multiclassing into account!

Ya, multi-classing makes it very difficult. Ammo should be fairly nice - I'll just add them as fields below attacks (in the same box).

Kryx said: Ya, multi-classing makes it very difficult. I have some code in my old spellbook stuff that I think *nearly* gets it right. It makes some educated guesses about the most efficient way to cast things if you have both warlock and normal slots. One of the big problems is that to do it properly you need a "cast as ritual" button, and that itself might or might not be valid. I think the worst case is probably multiclassing two caster classes, one with ritual casting and one without, and then getting access to a spell with the ritual tag via the class without ritual casting. By my reading of the rules you shouldn't be allowed to cast that spell as a ritual even though you can do ritual casting, but coding for that requires being able to know where you got access to every spell (which in some cases might be from multiple classes). Urgh.

I think we should worry about happy paths first and then focus on more complex scenarios. We should design an opt-in auto remove spell slot based on spell usage and then worry about MCing with a Warlock at a later point.

Kryx said: I think we should worry about happy paths first and then focus on more complex scenarios. We should design an opt-in auto remove spell slot based on spell usage and then worry about MCing with a Warlock at a later point. Sure. I think ritual casting is an important use case though - detect magic, comprehend languages get used quite a lot. From a purely UI perspective, probably the simplest solution would be to have "ritual" as an option in the spell level query dropdown. But that would break all of the roll queries :-( I guess you could just say for the moment that the suggested usage is not to use the spell rolls at all for ritual casting or adjust your spell slots back up again manually. Personally I mainly use the spell output in combat, and forgoing it for the odd ritual probably isn't that big a deal.

Queries can only contain 1 thing so that option is out.

Kryx said: Queries can only contain 1 thing so that option is out. Well "ritual" is mutually exclusive with the casting level (rituals are always cast at the default level) so in theory you could have the options as 1,2,3,4,5,6,7,8,9,ritual without losing any information, but obviously it would be hard/impossible to make the roll queries that depend on the casting level handle that. I guess maybe you could give "ritual" a value of 0 or 10 or something, and then *maybe* you could make the roll expressions deal with it? Might not be possible though, haven't thought through the details...

That's a great point. I can set the default casting to ritual for spells with ritual tagged. That'll work. Roll queries already base on level so I can just adjust them for ritual as well.

Lucian, Are you just editing the files privately, issuing pull requests to Kryx's github for the scripts, or is there a repository because I can't find it? Thanks

Benevolent Tyrant said: Lucian, Are you just editing the files privately, issuing pull requests to Kryx's github for the scripts, or is there a repository because I can't find it? Thanks Hi, there will be a new script in the main API repository, but I haven't sent a pull request yet. My fork on github is at&nbsp; <a href="https://github.com/symposion/roll20-api-scripts/tr" rel="nofollow">https://github.com/symposion/roll20-api-scripts/tr</a>... but what's up there doesn't work at the moment. As I said, I think it will be about a week before there's anything that's fit for people to use. Cheers,

Lucian H. said: RMcD said: Excitedly keeping track of this, not sure about moving over before everything is nice and movable. For the avoidance of doubt, this script &nbsp;will not &nbsp;upgrade characters from the old version of the shaped sheet to the new one. That functionality will be part of the sheet itself, using sheet worker scripts, once Kryx implements it - it's on his todo list.&nbsp; What the script will do is allow you to import characters/monsters from the MM text format and a JSON format (as was possible using the old script). It will also handle a few peripheral bits like ammo, automatic HP rolling for monsters, and any other convenience functions that help setting up characters with the sheet. That functionality is well on the way now, I have the parsing largely working, but I still have a few areas to complete and I want to do a lot of testing before I release it. I guess it might be another week or so. Oh well I misunderstood the first part I thought the moving from the other character sheet was going to be covered by this. So you won't need API at all to switch over from the old sheet to this one is that what you're saying? Or that it'll be a separate API script? Will this companion script import spells, in a certain format, as Mark's previous scripts did? The linking bars and tokens to a created character sheet with one command was very handy.

RMcD said: Oh well I misunderstood the first part I thought the moving from the other character sheet was going to be covered by this. So you won't need API at all to switch over from the old sheet to this one is that what you're saying? Or that it'll be a separate API script? It will be handled internally by the sheet, you won't need the API at all. Follow the main sheet thread on the character sheets forum for updates on this. Will this companion script import spells, in a certain format, as Mark's previous scripts did? Yes, it will. The first choice for most people will probably be drag and drop from the compendium, but obviously the SRD is limited and there's always custom stuff (until Roll20 make custom compendia). The linking bars and tokens to a created character sheet with one command was very handy. This functionality will still work with stuff imported from the MM text format as before (paste into GM notes and then run an import command). In addition I will include something that lets you fix up bars/tokens for sheets that have been imported from the compendium. I notice that the OGL sheet does tokens/HP rolling the other way round to the way the old scripts used to do it. Rather than auto-rolling HP when you drop a character from the journal, it generates a character token on the GM layer when you roll HP. I think probably I feel that the auto-roll HP approach is more natural - it means that all characters are placed in the same way - but I'd be interested to see if others prefer the OGL approach.

The OGL approach seems unintuitive to be the default, but I wouldn't mind if it worked in additional to the drag option.

On smaller maps I guess I could see it being useful... however in larger maps, having things appear in the upper left corner as you roll for them will definitely be inconvienient&nbsp;

Hi All, Just a quick update. I got taken down a bit of a rabbit hole with this one - the coding purist in me ended up deciding that the only correct way of reimplementing the MM import functionality was to write a generic validating parser for freeform text that accepted a JSON format specification. It turns out that this is actually not that easy, particularly for someone with limited parser-writing experience :-)&nbsp; Anyway, it seems to be working now, but the result is that I'm a bit behind where I wanted to be. I want to spend some time building a big library of test data to make sure that I've covered as many of the bases as possible, and have it all run automatically as part of the build system. The basics are there already but I need to juggle everything around, especially now that Roll20 have published their .... interesting... specification for the one-click scripts. If anyone would like to help out to speed things along, one really useful thing you could do is to PM one or two monster/NPC statblocks that you believe *should* import correctly - perhaps something you've used before with the old script - the more complicated the better. Please note that these statblocks need to follow the terminology and basic layout of the 5e MM; the parser is *reasonably* tolerant of changes (hopefully more so than the old one) but of necessity it relies on some things - particularly the names of the attributes ("armor class", "hit points", "senses", etc), and the capitalisation of trait and action names (which is the only way to identify them reliably) If real life doesn't get in the way, I still hope to have something ready for use later this week, but it may be a little rough around the edges at first. Cheers, Lucian

<a href="https://app.roll20.net/forum/permalink/3107072/" rel="nofollow">https://app.roll20.net/forum/permalink/3107072/</a> Following from this discussion I was wondering with this Companion Script it would be possible to have a toggle for blind rolls or something similar.

It's not possible here or there. That's what I'm trying to say. API can't block normal rolls from going through which is the only way it would work.

Well you said it was only possible with the API on that thread. However could the&nbsp;API script make any click on the character sheet not be a normal roll but a blind roll. Alternatively if you trust your players you could have an API script that spams the chat with dots so that it goes off screen though it'd be annoying for the GM too.

@RMcD - What Kryx is trying to say is that rolls on the sheet cannot be intercepted and "replaced" with blind rolls. &nbsp;If you wanted blind rolls, they would have to be initiated completely from the API side. For example, a typical roll button on the shaped-sheet produces a roll like this (Greataxe on a character named "Barbarian"): @{Barbarian|output_option} &{template:5e-shaped} {{character_name=@{Barbarian|character_name}}} @{Barbarian|show_character_name} {{title=Greataxe}} {{action=1}} {{reach=5 ft}} {{range=}} {{roll_toggle=1}} {{vs_ac=1}} {{roll1=[[d20cs&gt;20@{Barbarian|d20_mod} + 6[proficient] + 4[Str]]]}} @{Barbarian|roll_setting}cs&gt;20@{Barbarian|d20_mod} + 6[proficient] + 4[Str]]]}} {{targetAC=@{Barbarian|attacks_vs_target_ac}}} {{targetName=@{Barbarian|attacks_vs_target_name}}} 0 {{damage=[[1d12[damage] + 4[Str] + 0[global melee damage bonus]]]}} {{damage_type=slashing}} {{crit_damage=[[0d0 + 1d12 + [crit damage]]]}} 0 {{uses=}} {{uses_max=}} @{Barbarian|attacher_attack} @{Barbarian|hide_gm_info} 0 By the time this roll button is pressed it is immediately parsed and the results are there, it can't be stopped before the actual roll. What this means is that everywhere in there where you see actual roll syntax, this would have to be replaced on the sheet by a custom built API command , so that the roll itself is initiated by the API. &nbsp;This is a massive effort adding significant complexity to an already very complex sheet, not to mention the time setup to build the custom API command, which is not a trivial task given the complexity of the rolls. This is obviously a concern for you, and I will admit it was a concern for me at one point. &nbsp;While playing Pathfinder a bit over a year ago, I had created a custom sheet that replaced all of the rolls with Powercards (which can do blind rolls) as this was one of the main issues. &nbsp;It took me a long time to do this and I wasn't worried about maintaining another set of rolls for non-api users... Long story short... I realized that meta-gamers will simply meta-game, yes it can be annoying, but you know what... I don't reward the behavior. &nbsp;Instead I started rewarding people who roleplayed their results effectively by giving inspiration, or making cool things happen when they roleplayed their failures properly. &nbsp;If an individual doesn't change and still meta-games in a way that is disruptive, I have a frank conversation with them... if they continue, then I ask them to leave the game (with an appropriate warning). If this is functionality that you truly desire, then I suggest either making a custom sheet and API command for your game. &nbsp;Alternatively, Powercards are an awesome way to do what you want to do, but you will still need a custom sheet to at least replace the rolls that you want as blind rolls with Powercards. &nbsp;It is a tremendous amount of work though for an infrequently required use case that is really centered around bad behavior of certain players.

Great explanation.

Ah right I see, I was thinking you could just put a simple command that registers any click on the character sheet and quickly switches the entity rolling it to the GM or something similar.&nbsp; Well as I said it's not like I have a problem with my players just that as good roleplayers as they are and as good at ignoring the fact they rolled a 1 and listening to me when I say the person is lying (on say an insight check) you can't stop the human brain from being changed by the information it is presented even a perfect actor cannot replicate their true emotions as people cannot simulate themselves that well. So I thought it would be an interesting experiment if it could be done fairly easily.&nbsp; Since it's not possible without considerable effort then it's likely not worth it unless the GM would roll it all but I think even in blind rolls people like making their own rolls too much (I do occasionally use the functionality of switching the character sheet to GM only and rolling myself for saves the player shouldn't be aware of).

I've posted the latest script to my GitHub because I'm going away for a week or so and I know people want to try it out. It's still a WIP so use is very much at your own risk for the time being, but hopefully it will be useful to a few people. I'll tidy things up and fix up problems when I'm back at the beginning of April. I'll try and keep an eye out for serious problems in the meantime, but no promises... Details in the OP above.

Hey thanks heaps for your work on this. I'm just having a tool around and having some trouble getting the spells/monsters JSON files working - I've just copied in the old ones. However, it looks like the new support script looks for "FifthSpells" whereas the old one used "fifthSpells". If I try to change the sentence case of either the script itself or the monsters/spells scripts I get this error: "/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:1 orts, require, module, __filename, __dirname) { function g(a){throw a;}var j=v ^ TypeError: Cannot call method 'toLowerCase' of undefined at evalmachine. :1977:38 at Function._.each._.forEach (/home/symbly/www/d20-api-server/sandcastle/node_modules/underscore/underscore.js:158:9) at Object.module.exports.addEntities (evalmachine. :1976:7) at Sandbox. (evalmachine. :736:18) at eval (" Any thoughts?&nbsp;

Tim said: Hey thanks heaps for your work on this. I'm just having a tool around and having some trouble getting the spells/monsters JSON files working - I've just copied in the old ones. However, it looks like the new support script looks for "FifthSpells" whereas the old one used "fifthSpells". If I try to change the sentence case of either the script itself or the monsters/spells scripts I get this error: "/home/symbly/www/d20-api-server/node_modules/firebase/lib/firebase-node.js:1 orts, require, module, __filename, __dirname) { function g(a){throw a;}var j=v ^ TypeError: Cannot call method 'toLowerCase' of undefined at evalmachine.:1977:38 at Function._.each._.forEach (/home/symbly/www/d20-api-server/sandcastle/node_modules/underscore/underscore.js:158:9) at Object.module.exports.addEntities (evalmachine.:1976:7) at Sandbox. (evalmachine.:736:18) at eval (" Any thoughts?&nbsp; Hey, I probably should have left the casing the same - I might change it back when I get a moment to avoid confusing people. What it sounds like from the error is that you have a spell in your json which is missing the name property. I should probably handle this more gracefully (on the TODO list now) but in the meantime, your best bet is probably to go and look for the most recently updated version of the spells JSON data, which should get you round this problem.

Sorry all, I've realised that although the monster JSON import functionality is finished, I never got round to updating the existing data to the new format that Kryx and I agreed on (closer to the compendium format). The perils of rushing something out before a deadline. I will try and fix this urgently next time I have time available, but in the meantime this feature won't work. If anyone with JS experience is feeling enthusiastic, the format sample is in the resources directory of my github - it should be relatively simple to write a converter from the old format if you want to get things working before I get round to it Sorry for the confusion!

I get an error when trying to define a variable "FifthSpells", whereas it seems to work with "fifthSpells". I don't know why, but I manually changed the script to use fifthSpells instead and now it works. I'll test it to see what happens.

Camelcase is the appropriate choice for javascript vars as it isn't a class. :)

So the monster importer doesnt work? :( Awe.

I'm also having issues using the new spells JSON file in your Github Lucian. I'm getting the same error as Tim, and naming the variable FifthSpells or fifthSpells is making relatively little difference.

Hey Lucian, thanks for your awesome work! I'm just here to say I'm having a problem with the spell import function, and to ask if I'm doing something incorrect. I'm using the spell JSON and your latest import script. The variable is fifthSpells. This should be working, right? I type:&nbsp; !shaped-import-spell --Fireball And I get the error message: (From ShapedScripts):&nbsp;An error occurred: Unrecognised or poorly formed option [$$$] ShapedScripts:&nbsp;Fireball Does the same for monster import and statblock import. EDIT: I realize you mentioned this isn't working yet anyway.

As Lucian updated, the monsters import will not work with the current json format that was previously used, so until that is done, not much can be done. For those that want to test with spells, basically the file as it exists today will not work, but you can get it to work. &nbsp;In order to get it to work start with a script that looks like this: FifthSpells = ; Then copy everything in included in the square brackets in the old script. &nbsp;Meaning previously the format was: fifthSpells = { spells:[.....huge blob of data......]}; You copy only the first square bracket through the last square bracket and put it in the my first example to make it look like: FifthSpells = [.....huge blob of data......]; If you do this wrong it will fail. I found the best way to verify that you have the "[.....huge blob of data......]" correct is to use&nbsp; <a href="http://jsonlint.com/" rel="nofollow">http://jsonlint.com/</a> . &nbsp;Once your "[.....huge blob of data......]" shows up as a valid JSON, then you can copy that into the script.

Does the same for monster import and statblock import. EDIT: I realize you mentioned this isn't working yet anyway. Actually the statblock import works very well for properly formatted data, it's important to note though that if things are out of order (as they can be) or very poorly copied out, it will fail. &nbsp;But cleaning up statblocks and importing them is working very well at this point with only a few minor things.

Hey guys, Apologies for the various problems with the JSON import. I did it in a hurry and forgot that Kryx had a distribution version of the monsters/spells that put the JSON into a javascript object variable which had the array of data nested inside another object. I will try and fix it quickly now to work with the original format as it stood. Lucian

Kryx - I found it!! &nbsp; Lucian - I know you are busy doing the JSON import but wanted to know&nbsp;&nbsp;- is there any way to decrease ammo more than 1? And if not right now - it would be great if you could have the ammo name -2 or Ammo Name -5 and it would decrease it by that amount. &nbsp;If no amount was listed it would just decrease by 1. Just a suggestion to add some flexibility. &nbsp; Everything works great (besides importing which I haven't tried)

Kryx said: Camelcase is the appropriate choice for javascript vars as it isn't a class. :) Yeah yeah. :-) I'm changing it back. Stupid global variable nonsense - why can't we have proper modules dammit?

Black Falcon said: Kryx - I found it!! &nbsp; Lucian - I know you are busy doing the JSON import but wanted to know&nbsp;&nbsp;- is there any way to decrease ammo more than 1? And if not right now - it would be great if you could have the ammo name -2 or Ammo Name -5 and it would decrease it by that amount. &nbsp;If no amount was listed it would just decrease by 1. There's currently no way to decrease by more than one. I don't especially like the idea of hacking something into the name, and the sheet would have to support this as well - the initial reduction that you see in the roll template output is actually done by the sheet, and then the script takes care of persisting this permanently to the character attributes. Kryx, what do you think of having an additional field for each ammo item which specifies how many are used at a time? Failing that, I could make it a configuration option for the script with some sort of chat-window UI and persist it in the API state, but that would be lost on transmogrification/ API state loss + also the initial output would be wrong because it would still only be decrementing by 1. I guess we could do what we talked about for death saves and split the ammo display off for API users so the output is solely determined by the API using the roll template pieces, but that seems a slightly tortuous workaround in this case.

Lucian, you said you will include this eventually, but just to make sure: something that would be very useful to include would be defaults for all the configuration options on the settings page of the sheet (output options, roll options, and the stuff under 'Hide NPC info'). Sadly my JS-fu is nonexistent, otherwise I would just write a script that sets all of my favourite defaults myself...

Lucian H. said: Kryx, what do you think of having an additional field for each ammo item which specifies how many are used at a time? Failing that, I could make it a configuration option for the script with some sort of chat-window UI and persist it in the API state, but that would be lost on transmogrification/ API state loss + also the initial output would be wrong because it would still only be decrementing by 1. I guess we could do what we talked about for death saves and split the ammo display off for API users so the output is solely determined by the API using the roll template pieces, but that seems a slightly tortuous workaround in this case. Not such a huge fan as the amount of work isn't small and there is no use case for doing so by default. If we remove the output from the roll template and return it via script that would help alleviate the issue, but that would also suck for non-Pro users (the biggest user base). I'm inclined to focus our efforts elsewhere. There will always be houserules or crazy custom magic items. We can eventually add more functionality here, but in the short term I think we should focus on core features that nearly everyone uses.

Sorry if this adds to the difficulty. &nbsp;Aaron's ammo API has the option of adding a +/- after ammo (I think he just parses it), so I didn't think it would be a big deal. &nbsp;It would have been helpful in a couple of my campaigns where one attack involves multiple pieces of ammo. Thanks for considering.

What is the use case for using multiple pieces of ammo?