Sizing for a Single Hex Grid Map Token

Hi - I probably am trying to do something a bit oddball, so I hope you won't mind my asking a techical question on how to implement it. What I would like is individual hex tokens for creating terrain based maps. So I want one token that covers an exact hex grid (H). I actually have that. my PNG file is quite small, and as I followed the Roll20 instructions on creating map elements at 140x140 per hex and placed my hex in the center it works fine. Except for one thing. Because the size overlaps about halfway across the surrounding hexes, when I go to select it, if there are other map tokens next to it, then it become very difficult to actually select the one I am trying to move. Conversely, and originally, I created tokens that are the actual size of one hex grid. These are much easier to grab and move. However, nothing I could do would get them to fit to fill one hex grid to its edges, but instead leave a space around the edges of the token. It looks pretty poor by comparison. Here are two pictures of what I'm working on: Exhibit A Exhibit B Does anyone know if there is a way to get both effects in one token? I want it to fill the hex to the boarders as it does on the right side of the drawing, but be small enough to grab easily when I need to move pieces around on the map. Is that possible to do, either by aligning the image in a certain way, or having the borders of the transparancy of the png a certain width, or anything along those lines? Thanks in advance.

Just a note: whenever possible you should use JPG rather than PNG. A map full of PNGs like this may cause performance delays. To remedy this I suggest constructing your map outside of Roll20 and saving it as a JPG. Regarding filling the hex to the borders, I suggest creating images with as little padding as possible. When you import the image into Roll20 you can resize it to the hex size by holding down the alt key and adjusting the image to the proper size. Then use the "Set Dimensions" tool to find the size and set any subsequent images to that size (also via "Set Dimensions"). Unfortunately, there is no way at this time to avoid the 'larger than hex' images if you want the image to fill the hex. To deal with the problem of overlapping images I suggest working on a separate layer (such as token or GM layers) and then move each piece to the map layer when it is positioned correctly.

Ok that's cool. But when you say "performance delays", do you mean it will bog down your server, or do you mean it will get choked in the pipe to the client machine? If the latter, then I won't mind. But if its going to bog down your server if I create png based tiles for my terrain then I'll find an alternate solution. I don't want to be causing you guys headaches. It is not horrible to work with as is, it's just that you have to futz around with selecting the individual hexes to select the one you want if it is in a crowd of hexes. As for creating one big map and importing it as a JPG, that kind of defeats the entire purpose of my intention, which is the ability to allow me to design the maps on the fly in Roll20 by moving the terrain pieces into place. That would make my use of Roll20 a lot more flexible for what I want to use it for. It also would defeat my next goal which will be to assign terrain hexes a movement value and use the API to determine what the movement usage is per piece. But that's for another day. Right now I'll be happy if I can pain the maps the way I want. Thanks.

Performance delays such as one of your players has a slower computer and when moving around the map things are laggy or jumpy. PNGs take a lot of processing power. This is on the client's end of things, not the server end. Regarding constructing it outside of Roll20, you can periodically recreate sections outside of Roll20 and then import those sections in order to reduce the number of PNG images. Of course, if you or your players never notice a performance problem then it shouldn't matter. :) If you need further help let me know.

Thanks Gauss... as long as you're ok with my using the PNG for terrains I'll continue to do so. I just wanted to make sure it didn't bog you down. The PNGs are convenient as they let me build my maps on the fly, which is something I want to be able to do, in the style that I like - ie - terrain that covers an entire hex. The niddly part of having trouble selecting individual map pieces is only a problem when I'm changing the location of pieces once they've been laid down next to each other. And it's not that huge of a big deal. Just an annoyance I thought I might be able to work around ... but I'm ok with it as is. At some point, though I may want to bother to package this up for others as I think I may have stumbled upon a very cool and interesting way of using Roll20. Being able to create these kind of terrain maps inside of Roll20 is something that other people may find as convenient as I do. If it should be the case, and I can package this up, I hope that we can figure out how to make the pieces a little more convenient to work with (ie - figure out a way to resolve the issue regarding the wide borders of each piece overlaying other pieces and making it hard to select the one you are trying to move). Or - if not, that's ok. I have a feeling others will take the same attitude about it I have - which is "oh well, it's still cool enough to make it worth my while - even if it's kind of a pain in the rump in this regard". Anyway, thanks. I hope to have something to package in the not too distant future. Will be testing and getting feedback for a while first, of course.

It is not up to the Roll20 staff which image formats you use. I was just letting you know that there is usually a point where PNGs bog down a user's system. As your PNG tile maps get larger your players may report slow scrolling and response times.