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

[Request] Resize Token Based on Bump-map

I would like a script that monitors tokens, and scales them according to where they are on the map, using a bump-mapping-type algorithm, and the token's "elevation" attribute.  A 2x2 map might use a data set like: {-1, 0,  1, 2} And scale the token with 0 elevation like: {50%, 75%, 100%, 125%} Whereas a token with 1 elevation would be: {75%, 100% 125%, 150%} My ultimate goal is to create pseudo-3d maps, and add a visual element to flying/underwater combat.
1440711820
The Aaron
Pro
API Scripter
The API is certainly capable of those manipulations.  I think you'll find that user interface is the hardest part. Questions: 1) based on your description, it sounds like each tile of the map would have some elevation factor (in your example, -1 in the top left, 0 in the top right, 1 in the lower left, 2 in the lower right).  How would you see yourself assigning those? 2) Can you give the algorithm you're using for your sizes? 3) Tokens that are now significantly larger than the tile they occupy, you would want their size based on the tile they are centered over, and would expect the tokens to remain centered over their tiles when they are resize and later moved? 4) when moving a token, you would want that token to be repositioned to be centered over the tile it snapped to before reapplying the algorithm, or the tile closest to the center when it's released?
This is a prototype of what I'm thinking of, as far as battle map goes.  This could have an corresponding bump map like {-20, -20; -15, -15; -10, -10; -5, -5} 1) based on your description, it sounds like each tile of the map would have some elevation factor (in your example, -1 in the top left, 0 in the top right, 1 in the lower left, 2 in the lower right). How would you see yourself assigning those? I would be okay with a 2d array, or even a 1d, and specify the numbers of rows and columns.  If I finish my Python map-drawer first, I'll share the datastructure I use, in case it can be easily adapted in JS.  With the diagram above, I listed it as a pseudo-Matlab, which I think would be okay too.  Basically, I'm not afraid of manually entering anything.  I'm also open to XML parsing or any other datastructure. 2) Can you give the algorithm you're using for your sizes? Sure thing.   A linear scale from 50%-125% from the array Min to Max+60. //With 60 possibly replaced by the Maximum of all tokens' elevation The equation looks something like: Scale = (BmpHeight + elevation) * 75% / (60 + Max - Min) + (125% / 75%) * (60 + Max - Min) / Max 3) Tokens that are now significantly larger than the tile they occupy, you would want their size based on the tile they are centered over, and would expect the tokens to remain centered over their tiles when they are resize and later moved? I hadn't thought of the logistics of this.  I think it would be best to calculate the token's location based on its center, and resize it keeping the center in place. 4) when moving a token, you would want that token to be repositioned to be centered over the tile it snapped to before reapplying the algorithm, or the tile closest to the center when it's released? Another thing I hadn't considered.  My intuition is to snap center to center... so the tile closest to center when released.
1440735209
The Aaron
Pro
API Scripter
JSON would be the easiest format to consume, particularly since it could just be dropped in as a javascript object.  Probably: [ [-20, -20], [-15, -15], [-10, -10], [-5, -5] ] Python has a library for JSON.  XML would be horrible to deal with. Another consideration, elevation.  You could store it in an attribute, but it might be nicer to store it in one of the bars.  That would mean you could adjust elevation on things that didn't have an attached character sheet (and mooks wouldn't all suddenly have the same elevation when you changed one.). With the grid on, your tokens are going to snap to the top left corner, then get repositioned by the API.  Depending on the maximum scale, basing on the closest to center might be less intuitive than desired.  Luckily, it's something you can fiddle with as you write it. =D