There'd be a bit of restructuring to do, but not too much work, especially if you didn't want it to be user-friendly. It's a hard problem for a few reasons: how do you pick which one?
There aren't really good methods of getting and returning that amount of data. It's actually easier if all you want to do is move characters between campaigns, because you can use something like base64 encoding for the transfer.
Well I'm not javascript programmer thats for sure, but what about folder access via the API? Maybe if you create an "export" folder right off the campaign root and move what you wanted into there for a quick and painless export solution? You could also paste what you wanted to import into an "Import folder" Other option maybe a dual script?
One that pulls all the names, and you put that into another script that asks based on the names what you want to export.. How do you pick? The script exports the character attached to the token that ran the macro 'export me'.
I just can't imagine how the import side would work. Making changes to a number of abilities at the same time is a frustrating and annoying process, as I've complained before. It's the only time I miss Gametable. I think I can make you a solution Let's see what tomorrow brings. The Aaron said: I think I can make you a solution The 4th night in a row Many things are possible. It is, however, an extremely less than satisfactory work around.
I'll give it a try this weekend, using this script. That will give me a chance to figure out how to accurately copy the PCs from Actual to Sandbox. I'll copy the whole campaign over to Test, first, because I see this all going horribly horribly wrong somewhere along the line. Isn't there some way to use character IDs such that a single journal could be imported?
The import side of it is easy: the script imports whatever JSON you give it, so you can just only copy the parts that you want or only generate the parts you want, using the trick mentioned above or some other modification to the script. It's now the weekend and I'm able to test this out. Family distracted and headphones on! The transmogrifier is surprisingly easy to use. However, I've run into a minor annoyance. In the journal, the ability is formatted:! Is this possible?
I'm betting not, but a girl can hope! I think. Now, for importing When I try to import the resulting string, I keep getting Your scripts are currently disabled due to an error that was detected. Please make appropriate changes to your scripts and click the "Save Script" button and we'll attempt to start running them again. More info See the API documentation for more info. I'm left with a journal that is not an exact backup of the original. It didn't retain the controlling player, the tags, the avatar, nor the default token.
Likely something such as '! Unfortunately, a lot of that isn't possible in the current state of the API. The error message you got is due to the fact that tokens and avatars can only use images from a Roll20 library, not from the web. Default token is read-only, and the API has no access to tags I'm pretty sure there's a suggestion at least for the latter in the suggestions forum. If you're just wanting to manage a characters abilities I assume this is in pursuit of improving the character macro management system you mentioned in some other thread , something more purpose-built may be better for you.
I've been tossing around the idea of making a handouts-based filesystem-analogue, which would help with something like this making it easier for a script to dump to and load from a handout, so it can all be done from within the game. Maybe I'll put in some work on that this weekend and use this as a test case for it. The Aaron's doing something similar. This script works great for moving character journals between campaigns, and doesn't need any tweaks for that use-case. I don't want anyone thinking it's a failed script.
I just need a screwdriver instead of a hammer. And I'm dreading the slow, laborous, ability by ability copy-select-delete-paste-save process. Which is why they haven't been updated in so long You must Login to your Roll20 Account to post a reply. In order for graphics to be readable and crisp for print, the image resolution - the DPI Dots per inch has to be kept rather high. The standard minimum resolution for a printed image is roughly DPI. Image resolution is meaningless to how an image displays on the screen.
The deciding factor of how an image displays on screen is determined by the dimensions of the image. If you want images to run smoothly in Roll20, keep image resolution low. Anywhere between the DPI range should be adequate for your game images.
Note: Due to the way that images are parsed by Roll20, the ". Make sure JPG files use the extension ". No re-save is necessary, just edit the name. For animations, the mp4 files will be more available, but converting mp4 to webm will reduce the time it takes to put files on Roll The GIF file type is handy if you want just a simple aliased cutout image for token objects, with or with animation.
PNGs can also work for token objects or images requiring transparency, but animated PNG files are not supported. As PNGs are more flexible than GIFs, sometimes they will have a larger file size for what looks to the eye like the same image. If your software controls it, you may be able to change your image from "full color" or "rgb" to "palette" or "indexed". The latter only has a limited number usually of colors, and is the only format that GIF supports.
Most PNG files you create will be rgb, saving more data per pixel than GIF, and thus being bigger-- but also preserving more image integrity. When a GM hands out documents to their players around a physical table, often the item is written or printed on portrait-oriented paper. On a tablet, a person can simply flip the screen whether a graphic is either Portrait or Landscape. When you want to create handouts or splash screens for use in Roll20, keep in mind that the average user often is working on a widescreen monitor with fixed screen resolution not to be confused with image resolution.
Regarding screen resolution, get an idea of what your players are using. Are they working at desktop stations? Find a happy medium of screen resolution and work your graphic sizing around that, so no one will have to play with their zoom settings so they can view your images. Websites like w3schools. Token images, due to their small size, are probably best suited for PNG formats if you want transparency for best quality.
The reason for doing this is that an image when dropped onto a gridded tabletop will warp the dimensions of the image to best sit inside a single grid unit. This process might dramatically change the proportions of your image.
For instance, if you're using tokens that fill a 1 x 1, 2 x 2 or 3 x 3 unit space, you'll want to make sure that the final dimensions of the image are the same for both height and width. If you have an oblong token, you'll want to make sure that the final dimension's of either the width or height is exactly double or perhaps triple of the other.
Solution: This is normally due to file size of any given image in a game. It gets worse after adding actual data. A more practical comparison for an actual map is 92k png , kb gif , kb jpg. After completing the map, I convert it to 1-bit indexed color. Oh yeah, I am using DSL. Try to make as much use of the available screen space. This normally means designing items that are wider than they are tall to best fit on a widescreen monitor. Solution: Sounds like your image you are using for your token didn't have enough padding.
For example, a creature that you want to take up a 2x1 grid area, make sure one dimension of the image is padded out to be exactly double of the other. Visit our FAQ! Character Vault.
0コメント