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

[API] Structured Data Files

Let's say I have a json file that holds information that I want to use to perform both of the following tasks: 1) Run a command that creates an ability macro for a user. 2) Output the information in a structured format to chat. I know that both options above are possible, but my question is more about how to handle this large json file. The file in question is ~274 kilobytes currently, but this of course could get larger in the future. Where can or should this data be stored to be used as reference for the above script? If this is possible, are there any lightweight/efficient functions that would assist in interacting with json data? Thanks!
1422197238
The Aaron
Pro
API Scripter
JSON is designed to be light weight and easy to work with. If you are using it with a script, I would suggest you just use it as the Object Notation it is designed for and create a variable: var DataLookup = { foo: "bar", bar: 23, qux: { baz: 4 } }; Then you can just access it in scripts like any other object: sendChat('stuff', "the bar is: "+DataLookup.bar); There are some other tricks you can do to make the script more robust, but that's the gist of it.
1422198556
Ada L.
Marketplace Creator
Sheet Author
API Scripter
If you're trying to persist JSON generated by your script, normally you could use HTML 5's localStorage interface, but unfortunately the API doesn't allow it. An alternative that does work is to store the JSON as a property of an in-game object such as a token or handout or something. I know that this technique works because I use it to have tokens store references to other tokens in my marching order script. However, you'll lose this data if your sandbox crashes. Another way you could persist JSON data more reliably is by setting the stringified JSON data as the notes content of a handout. You could parse the handout's notes property to read your data when you need to interact with it and stringify the data to the handout's notes when you need to save it.
@Stephen - In this case the information is largely static, more common data that I want to read from to at minimum output on demand, and if possible use to generate macros for my players.
1422232541
Lithl
Pro
Sheet Author
API Scripter
Stephen L. said: If you're trying to persist JSON generated by your script, normally you could use HTML 5's localStorage interface, but unfortunately the API doesn't allow it. An alternative that does work is to store the JSON as a property of an in-game object such as a token or handout or something. I know that this technique works because I use it to have tokens store references to other tokens in my marching order script. However, you'll lose this data if your sandbox crashes. This is basically what the state object is for. All scripts have access to an object named state which persists its content between game sessions. State contains nothing unless something is put there, but it's recommended that you put all of your stuff into one object which your store as a single property of state, so that you can avoid collisions with other scripts making use of it. For example, instead of state = { foo: 1, bar: 2 } , use state.myscript = { foo: 1, bar: 2 } . That said, state is not intended to be a database, it is meant to store... state. If you've got static unchanging content, it would be better to just write it as variables in your script. They'll be reinitialized each new session, but that's hardly important, since they're not changing. (There was a Pathfinder script a while back, for example, that was storing practically half the rulebook in state, causing the API server to choke. I believe campaigns which take too long to synchronize state with the API server now have the API throttled.)