Thanks for this work, Trenloe! I used the original extension but kept forgetting what layer I was on! I might go ahead and re-try to use this again. Its a great extension to begin with and this addition will put it over the top for me! I purchased the spell tokens so I agree with LordEntrails. Its a great time to try it again!
The other issue i have is that when i put token in the fisrt bottom layer the token names appears correctly but when i put them in the upper layer they dont appear.
Attachment 15782
Attachment 15783
What is the easiest way to move token between layers?
In the current version you need to delete the token and re-add it to the correct layer.Quote:
Originally Posted by bnickelsen
Trenloe - does this version fix the issues with token rotation on the client side?Quote:
Originally Posted by Trenloe
Also, there is a bug where a double grid appears when the image is zoomed all the way out. If you zoom in 1 notch, the problem goes away. It doesn't look like this version addresses that problem. For example, if you apply the grid to the bottom, then switch to the top while zoomed all the way out, you will see that the grid is misaligned vs. the map grid on the top layer (but what is happening is that there is actually another set of gridlines that is offset from the main ones -- see attached image. The other attached image is after zooming in 1 notch, where the problem vanishes. Anyway - the grids on all layers do not properly align when zoomed out.
There seems to be a misunderstanding of the implications of FG image size and FG resources used, and how the layer extension works. I'll address each item below:
Image file size is purely an implication when transferring (sharing) images to players. FG's old network stack is not very efficient (and single threaded) so the larger the file FG has to transfer the longer it takes and the more it "chokes" up the GM instance of FG.Quote:
Originally Posted by HoloGnome
When FG opens an image it stores all of the pixel information in memory. The more pixels there are in an image the more memory FG will use when the image is opened. The number of pixels has nothing to do with the file size/JPG quality but the resolution of the image. Original file size does not directly impact this.
This is incorrect. The layer extension only uses an image file on the bottom layer, so the image file is only transferred once to each client when initially shared.Quote:
Originally Posted by HoloGnome
Correct - file size does impact transfer to clients. Incorrect - the file size does not necessarily directly impact FG memory management proportionally (i.e. a 1MB file doesn't necessarily take twice as much memory in FG as a 0.5MB file). See my comments above regarding number of pixels.Quote:
Originally Posted by HoloGnome
What the layer extension does impact is local memory used - FG has to create three image controls in memory, all of the same dimension (pixel size) as the original image, and even if these are blank (invisible) pixels they will be taking up memory. Essentially, an image opened with three layers will occupy three times as much memory as the same image opened with 1 layer. Adding a mask will also take up memory.
OK - I was assuming that the transfer was also 3x because of the significant image transfer slow-downs I see when using the extension, but maybe those are due to internal FG issues. I am aware of 3x the memory and, again, thought that was because of 3x the transfer. So, when I need to use the Layers extension, I have aggressively reduced map size (usually to < 200K). Sorry for any unintentional confusion on the image transfer. I have had better luck with smaller file sizes.
Hang on - from what you say, maybe my slow transfers were because I pre-masked the images. If a mask exists prior to sharing the image will it be transferred 3x or will it be cloned locally after the transfer?
Image size in memory has to be a combination of dimension and pixel depth. 1-bit < 8-bit < 24-bit, etc. Are you saying that FG creates max bit-depth bitmaps for all images regardless of the source image bit depth?
There's only one mask - on the bottom layer. The other layers don't have masks.Quote:
Originally Posted by HoloGnome
I don't know what FG uses for colour depth in memory. From what I see the original image colour depth makes no difference to FG memory use .Quote:
Originally Posted by HoloGnome
Ah, right - yes only one mask. I did know that at one point. :) On bit depth, maybe all images are max depth.
Any thoughts on the misaligned grid issues? See above images.
The new version purely adds token shadows on the lower levels, nothing else - no bug fixes, etc.. Info here: https://www.fantasygrounds.com/forum...l=1#post288715Quote:
Originally Posted by HoloGnome