Best way to get data into a script?

So, I've done some googling, but like many things with the API, a good answer is hard to find. What I want to do, is allow a DM to customize the random encounter script i've been writing in the following ways: - The number/names of the times that encounters happen (for instance, the base rules that I am building off of, has 6 phases of the day during which an encounter could happen), However, if the DM wants to have 3 phases, I want to try to support that. - Secondly, I want the DM to be able to use their own encounter types, and names of tables. The system this is based on has 6 encounter types, but only 3 tables of encounter prompts (hostile covers 3 separate escalation points) So far I've got two possible ideas for how this could work. One of which I'm 95% positive will work, but has it's drawbacks, a second one, i'm not so sure if it will work at all, and a third one, that while doable, is not my preferred approach, at all. Option 1: Almost positive i can do it: So, my first thought was to create a handout specifically for config, that would hold my existing information (as a guide for how it needs to be formatted) and basically do a format style within that document for the customization The downside I see to this is it forces a handout on the DM that may not be desired, or could be deleted, without knowing what it's there for. Option 2: Less Mess, but more Trouble? The second option, that I honestly have no idea would even work within the framework of roll20, is to create a separate API file, but instead of making it a .js, making it a .txt and importing/including or something similar in the main script. The down side to this is that the DM if they wanted to change it, would have to feel comfortable enough to edit a file within the API. The upside is, if they don't care to change it, there isn't an additional file on their table that they don't know about (although, they do need to copy 2 files to the table) Option 3: The blah Method So my least favorite method would be to have a config command, the the DM would need to enter in the options via chat. I dislike this as it can be prone to errors, and should anything happen to the API, the user would need to re-type the info. Using the other 2 methods, the DM might be more likely to have a local back up of their info. Option 4: The "I just thought of this and have no idea if it can be done" So, as I was typing this, I also thought that I could perhaps,have a macro popup to prompt the DM to enter the info, that would then call the config function in my script... So I turn to you fellow scripters, what seems to be the best way to get potential config info into the game?

All of these methods are in use, and you might want to look and see how each solved its issues. Tongues for instance, uses #1. Each language is read in from a handout Spellmaster uses #2. Lazy Calendar allows you to input as in #3, but also includes the ability to export and import a text file wholesale. Some have even used 5: Include the data within the script itself. The Shaped Script contains much of the SRD to ensure continued compatibility.

Thanks for calling out individual scripts that do each of them Keith. I'll take a look and see if any of the implementations strike my fancy or not

Keith makes a good point. For me with my use of Tongues, I just shoved all the handouts in a folder and I'm not even sure where I hid it anymore.  Still works though!  This is a simple enough solution that works well for relatively unstructured data.  Tongues invites players to share their custom languages and can be added easily with just a few clicks. Now, when I wrote SpellMaster, I didn't do that.  There were a few reasons. Size: SRD.js is enormous and would eat somewhere around 40% of state's data cap if I put it there.  It had to be in a resource file somewhere. Speed: SpellMaster is heavily focused on performance.  That's a lot of data to read, and in my experience with working on CashMaster, loading data from handouts is painfully slow at scale. Read-Almost-Only: No user of SpellMaster should ever alter the highly structured data of SRD.js by hand.  It's editable, but only by fully pasting in a replacement block exactly as ordained by the script. Obfuscation: SpellMaster is a powerful tool, but unfortunately one that could be used by bad actors to share some copyrighted material.  I wanted something a bit less direct than a text file in the game in a human-writable form.  If someone wants to use it for ill now, someone has to either have bought the spells themselves or written a parser to spit out a text file in the right format, in which case they have the skill set to have pirated in any event. As a side note, when I worked on CashMaster, shop data was stored in the NPC GM Notes as JSON.  Other than being slow, this worked well enough and was human-readable, but that also made it seemingly human-writable, and there were more than a few cases of people manually editing it only to break their shop and not knowing how to fix it.

I'd suggest going into a dark room, sitting down and chanting "Daddy needs a new pair of shoes"  and rolling dice.   Once that fails, and after seeing your other post about random encounters API.  Send all of that to the chat window with hyperlinks that contain commands and the data from your tables.  They get embedded into the hyperlink before you send all of it to the chat window.  GM selects one of them, sending a specific command back to the API.  The API parses the command and the extra data that you send, and the API then does whatever it needs to do.  And BTW, it is cute :).  Roll20AM has examples of embedded commands into chat and then receiving the results and parsing.  There's many that do similar things.  

Victor B. said: And now that I actually read what you wrote, add roll queries for the number and names of encounters.  Easy to do.  Enables Gm to set whatever they want.  Yes, you have to add code to the API to support the roll query.  For the second, roll queries again that specify whatever you want.  Base APIs stand pretty much as is with the addition of the roll query result and IF/THEN's to find what you are looking for.  Should be straight forward.  And my prior, though less enlightened approach, still stands.  Small changes This is what I was going to suggest. In fact, i seem to remember mentioning this, Aku, in an earlier thread about your random encounter script. Remember the function i gave you, to extract the contents of a table and turn it into a roll, where I made it usable with any table, you just needed to supply the name? For what you need, it is the simplest way, requiring almost no changes to the script IIRC.  (Hard to be certain without a link to the script, but I'm pretty sure the script would support it.)

I was getting a bit verbose and morose so I consolidated everything into one above.  I think he should send everything to chat with a hyperlink and embedded data and have the API parse the embedded data and then do whatever it does.  Roll queries is an easy way to do it.  Still an option.  

Rereading the OP, it looks like he needs (a) the names of the table, and (b) the number (and maybe name) of encounter intervals per day, and some associations between them (which tables to use, and when). There are two ways I see to go here (if I'm understanding correctly): The way Aku is thinking: provide a method to roll all encounters in a day, in which case you need some way to store configuration details (number rolls per day, which tables to use). in this case, using the state object might be the best and easiest way. You can display it in a handout, or in chat, or in multiple ways, but the state would be best for actual storage and use. Assume GMs dont want to roll all encounters at once, but roll them as needed, in which case you just need one argument: the table to roll on, and no need for config storage. That can be a simple query dropdown, so GMs can choose from a list of encounter tables, that they create themselves. Aku, if using the first approach, you need to figure out how you want to structure the data - what variables actually need to be stored. That's the hard bit. After that, it'll be fairly straightforward.

GiGs - You've got it right on the first one. Currently the end result is output to a handout with an HTML table. To provide further example, in my OP. I said how "hostile" has 3 categories, but only 1 table. Let's say a DM wants to expand that, so each type of hostile encounter has its own, unique table. Currently, without making significant changes to the script on an individual basis, I don't think this would be possible.

For your use case aku, I might recommend making a roll table naming scheme. For instance Encounterapi-categoryName-specificTable. Then the script can dynamically react to new tables being added and GM's don't have to learn a new interface.

Scott, So if I understand your suggestion correctly, you're saying to: - Read the base table (That I roll on to determine the encounter class, i.e. friendly, hostile) to determine the number possible encounter types, and - Set up a naming scheme to link each table they make to the the type of encounter they want it assigned to? such as RandomEncounter-Friendly-DaytimeFreindlyEncounters ?