Underscore usage

I read in the docs that you can use Underscorejs.  Does this include using underscore templates for pretty printed output?

Huh, hadn't known about that. It should work unless it's from a newer version of underscore and the sandbox hasn't been updated to it. EDIT: Yep, _.template works. Not sure I'll actually use this as template literals are easier for me to read and think in, but still interesting.

If you’re talking about _.template(), you can certainly use it. Look at ColorEmote for some examples. However, with the advent of Javascript ES6, you might find Template Literals a better time investment:&nbsp; <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals</a>

API has underscore 1.9.1. Tabletop has underscore 1.3.1.

By tabletop, you mean character sheets?

Nah, I meant on the actual VTT (like if you try bookmarklets or something) but the charactermancer and probably the character sheets use 1.8.3.

Can you use `.tmpl` files, or only inlined as in the ColorEmote example?&nbsp; Not very knowledgeable on the allowable file structures in roll20.&nbsp; I take it either way you are still limited by the html tags listed on&nbsp; <a href="https://wiki.roll20.net/API:Chat" rel="nofollow">https://wiki.roll20.net/API:Chat</a> ?

Shin said: Can you use `.tmpl` files, or only inlined as in the ColorEmote example?&nbsp; Not very knowledgeable on the allowable file structures in roll20.&nbsp; I take it either way you are still limited by the html tags listed on&nbsp; <a href="https://wiki.roll20.net/API:Chat" rel="nofollow">https://wiki.roll20.net/API:Chat</a> ? not familiar with .tmpl files, but everything has to be inline for API, you can't reference other files. You can reference data stored in a handout/other vtt object, but they still have to be in the same format as inline so there's no real difference there.

You can output pretty much any HTML you want.&nbsp; There are certain inline styles that will be filtered (mostly function style things). You can't use .tmpl files, but you can can certainly put the contents of such a file in a string and use that.&nbsp; Picture the API sandbox like a Node application where you can't use any require/import commands but can instead concatenate a bunch of files together and you won't be far off. =D

The Aaron said: You can output pretty much any HTML you want.&nbsp; There are certain inline styles that will be filtered (mostly function style things). You can't use .tmpl files, but you can can certainly put the contents of such a file in a string and use that.&nbsp; Picture the API sandbox like a Node application where you can't use any require/import commands but can instead concatenate a bunch of files together and you won't be far off. =D That's an awesome characterization. &nbsp;Incidentally, you can use require, there just aren't any modules on the path so you get undefined. &nbsp; I use that to allow code to detect where it is running, using the file system ('fs') when running under Node.js for testing, and use roll20 state instead when it is running in Roll20.

Has anyone looked at using something like `browserify` to pack a bunch of files together to make your roll20 script?

Yes I did. &nbsp; Then I went crazy and switched to compiling a tree of TypeScript classes into a single file. &nbsp;Then I went crazier and merged those modules into fewer modules to reduce the amount of export/import glue that makes the output unreadable. &nbsp;You can read about it the thread&nbsp;<a href="https://app.roll20.net/forum/post/6947128/typescript-anyone" rel="nofollow">https://app.roll20.net/forum/post/6947128/typescript-anyone</a>

About the specific question, Browserify and Webpack both are better for making unreadable minified scripts. &nbsp;Since customers want to read the scripts they install, this turned out to be the wrong direction in my opinion. &nbsp;You'd be better off just concatenating files yourself in a Makefile or something, unless you want to start compiling.

I hear you, in principal, but most of the scripts I've seen are undocumented and written in a spaghetti threaded fashion such that no one is likely to glean anything of great value by looking at the source. I actually wrote a little emulator this afternoon to do simple examinations locally. All of which is to say, I'm not sure it's a major consideration.&nbsp; Also the term "customers" implies a level of.. productization? that I don't feel in roll20, but, maybe I'm just ignorant/naive :). Has anyone bothered to run perf tests, btw?&nbsp; I imagine not.

The shaped script (and shaped sheet) are build with Browserify(or possibly Webpack). &nbsp;

I believe the emulator project is called 'Mock20' but I don't know what its level of life is :). &nbsp; You could look for that and resurrect/contribute.

Shin said: I hear you, in principal, but most of the scripts I've seen are undocumented and written in a spaghetti threaded fashion such that no one is likely to glean anything of great value by looking at the source. I actually wrote a little emulator this afternoon to do simple examinations locally. All of which is to say, I'm not sure it's a major consideration.&nbsp; Also the term "customers" implies a level of.. productization? that I don't feel in roll20, but, maybe I'm just ignorant/naive :). Has anyone bothered to run perf tests, btw?&nbsp; I imagine not. Disclaimer: &nbsp;It is late and I am feeling philosophical. &nbsp;Also, I don't remember which of these points I have already discussed with you. &nbsp;&lt;Rant&gt; I am very excited to hear your opinion about undocumented spaghetti scripts. &nbsp;I have 4177 lines of TypeScript code and 521 lines of comments. &nbsp;So still a pretty shitty ratio but they are very nice comments. &nbsp;Come to the dark side and join me in TypeScript -&gt; JavaScript -&gt; Roll20 plugins land. Like I mentioned in the other thread, I had also not expected anyone to read my code, so I started out with 52 (?) modules compiled to one output file and a tiny AMD loader at the end that starts them all. &nbsp; This was pretty much free because TSC can compile to a single output file and if you set your module type to AMD the module code is not THAT ugly. &nbsp; That was the model I used and still use for my 'complete' mode scripts that are self-contained. &nbsp; Then we had that long discussion about how some people kind of want to read their scripts and make sure they don't muck up their campaign data and such. &nbsp; I believed it and went to the trouble of machine-merging typescript modules to make a single module per file. &nbsp;It took several days to get the output to look right. &nbsp;At least this also made it feasible to split my code into a giant library script and small plugins. I don't know how real this concern is. &nbsp;If you do feel like delivering a "product" then I feel it should be ok that you can't read the code very easily. &nbsp;If it has a UI and decent error reporting to where people don't HAVE to read it, then so be it. &nbsp;It's not like anyone reads BeyondImporter (**shudder**) or the scripts that are embedded in the Character Sheets. &nbsp;If some people have security concerns that you could screw up their D&amp;D game, then perhaps they don't have to use your free product? Then there are some people who like to work quite "raw" and use TokenMod to basically put code right in their macros. &nbsp;Those folks will probably also read the scripts they use. &nbsp;I don't feel that's a "product and customer" relationship, more like open source hacking. &nbsp; &nbsp;Not sure if those situations can ever be integrated. &lt;/Rant&gt;

I prefer being able to read the code. I remember people in the past (e.g. Brian, who was responsible for most of the commits to the css wizardry wiki among many other things) arguing that roll20 scripts should be more &nbsp; commented than scripting elsewhere. Because most people coding in roll20 aren't professional coders, and need help :) We often need to figure out how to write code for our own purposes, and having readable code written by other people to study is a&nbsp; big help. Of course, if its a big project, like tokenmod, chatsetattr, and powercards, it's silly to expect them to be extensively commented. Those are more than just scripts, they are full-featured applications, in a way. But for smaller single-purpose scripts, that it's reasonable to think newbies would be able to study and learn, it's nice to add a few informative comments to help those learning. I think Ammos last 2 paragraphs really does describe two kinds of users and projects common to roll20.

Well, as a neophyte to roll20 scripting &amp; api, I don't know that I have the perspective to make any strong statements.&nbsp; My knee jerk belief, however, is that having separate files on a github in a normal, documented &amp; commented format, which you then package up via some build/pack mechanism to make your deliverable seems perfectly reasonable.&nbsp; I haven't had much issue with perf in roll20 to be honest, but if one was worried about such things I don't see how it would not be improved by packing your API scripts.&nbsp; The idea that the scripts you install are not legible doesn't seem bad to me; you can always grab the github source and build the final file yourself if you're worried something hinky might have been done.&nbsp; As for learning, separate, well-documented files are much easier to dissect anyway, especially if you have multiple monitors, etc.&nbsp;&nbsp; And, of course, being me, I'd jsdoc them and auto-generate the documentation from the code.&nbsp; In fact, that's what I'm doing on this project, even though I don't know that it will ever see the light of day as it were :).&nbsp;&nbsp;

I like everything you are saying, Shin. &nbsp; And yes, of course I use jsdoc format but only so that documentation pops up when you hover over the code in the IDE (vscode). &nbsp; I don't actually emit the doc, because there is nobody to read it and it is sporadic at best. &nbsp; I do, however, have my plugins automatically emit a list of their commands and format at build time, to update user documentation fragments for the !commands. &nbsp; There are assembled into this &nbsp; <a href="https://derammo.github.io/der20/" rel="nofollow">https://derammo.github.io/der20/</a>. &nbsp; &nbsp;Yeah, a lot of it isn't filled in, but then again I have no customers. &nbsp; There are a lot of things you can do. &nbsp;I think at this point all we are saying is that you can approach roll20 scripts as a software engineering project (and then those things that you do naturally happen) or as a quick scripting task (which is what was clearly envisioned by the folks who made this API and web site.) &nbsp; You can see the latter in the tiny examples and kinds of examples in the roll20 api docs, which basically try to show neophytes how to use the API, sort of like those web sites that teach CSS by example. &nbsp;And this is great. &nbsp; More people writing code. &nbsp;For other people (like me,) it is more fun to consider this like any other open source project. &nbsp;And then suddenly you have a 169 line Makefile. Both are valid as long as people are having fun. &nbsp; When you are ready (or even better, before you are ready,) please share your repo. &nbsp;I look forward to seeing your work.

PS: regarding authority/perspective from experience, I have none. &nbsp; I started using TypeScript on October 17, and started my Roll20 framework on October 18. &nbsp;Maybe that's why all my stuff looks like it was written by someone who doesn't like script languages.

Well, you can use github to post the docs for your project.&nbsp; With custom jsdoc tags, and a custom template, you can document your commands in your sources, generate that documentation and have it hosted along with your github project.&nbsp; You can link to it externally and send people there for detailed explanations of how and what things do.&nbsp; If you make use of jsdoc access tokens you can effectively maintain two sets of docs--technical for other developers/modders, and "consumer"-based describing basically what each command/event/etc. your script provides.

Well yeah, the URL I posted above is hosted on github. &nbsp; I did this thing separately because I had a different objective. &nbsp;With the scripting I did, if you add a command to a script while you are coding along and then do a build, it will notice a new command that doesn't have help text and emit and empty help fragment file for that command. &nbsp;This happens because you added or changed the command path, without you having to be aware. &nbsp;When you go to commit, you will notice a new untracked file, basically saying "hey you added a command, how about you fill in this doc file." &nbsp; Anyway, I ended up never documenting the commands though (most of the files are still empty) because there aren't any people using it.

That's pretty fancy :).&nbsp; I'd have been tempted to try to pull the command information out of jsdoc's AST to auto-generate your help files, possibly with an augmentation pattern to composite with a separate markdown write up if available.&nbsp; Maybe also a report like jshint or an lcov but for documentation coverage, but again, depends on how much "professional" effort one wants to put into such a thing.&nbsp; At the moment, I'm just doing basic stuff--enough to be maintainable.

Yeah if I was a JS person, I might have gone that route... but I am old and just write 15 lines of code to create the JSON I want directly in my plugin. &nbsp;Basically it starts up every plugin during build time in a special mode to print out the command tree and then I feed that to another JS program that does the updating. &nbsp;Your approach is more formal, but I don't know any of the steps involved so I would spend all my time learning things I am never going to use again. &nbsp;On second thought, I do that a lot. &nbsp;Maybe I missed out on some fun :)