Token vs Widget question

[SilentRuin]

I've been beating the free extension Death Indicators back and forth on how to handle people with different tokens vs the blood splat images in that extension. Just finished changing it again. I have used both the getImageSize() and getSize() off of the token (portrait of PC/NPC) to scale the bit map widget for the blood splat images (via setSize() ) and while I don't really see issues in my side I have had people prove to me they have problems - which I can then duplicate with their tokens.

Currently I have the token.getSize() * 2.25 defining the height and width of the widget - but even thought that works in all the current cases I know about - I can't feel that I'm doing this imprecisely.

There must be some sort of logic to use to get a token size and then scale a widget based on that size. I'm just not understanding what that method is. For sure getScale() doesn't work with either scenario as the tokens all come back with different scales it appears which have nothing to do with widget size.

Anyway - any help appreciated. Here is the chunk of code I keep switching back and forth on.

	local tokenCT = CombatManager.getTokenFromCT(nodeCT);
...
	local wDeathIndicator = tokenCT.findWidget("deathindicator");
...
		local nWidth, nHeight = tokenCT.getSize();
		wDeathIndicator = tokenCT.addBitmapWidget();
		-- get true token image size and use 2.25 size of that. 
		wDeathIndicator.setSize(nWidth * 2.25, nHeight * 2.25);
...

[Moon Wizard]

It's different between FGC and FGU. FGC uses a size-relative ratio to the token size to draw widgets; whereas FGU uses a grid-relative size percentage (10x10 = 10% of a grid width x 10% of a grid height). The grid relative sizing was a change made in FGU, because sizing widgets was hard to do in FGC exactly because there were too many variables. For FGC, I would suggest looking at the code that draws the effect icons to get ideas.

Regards,
JPG

[Kelrugem]

Yes, as Moon Wizard wrote the size of a widget is differently used in FGC and FGU. Moreover, I have a similar extension for 3.5e/PF1, adding wound and save overlays, so, I had to look at that, too. You can test with debugging that the tokenCT.getSize() actually returns the pixels (I have the same method of getting tokenCT). You can test that by just taking one token and debug the width and height on different maps with different resolutions. But, since FGU interprets these numbers as percentages of the grid sizes, you need always the same number on every map to make your widget consistent. For example, a widget covering precisely one square of the grid should have the width=height=100, always, on any map in FGU. Because getSize gives you the pixel size in your case though, which is different in general when comparing different maps, you get different results.

Hence, my suggestion is the following code (Initially I load the width and height still as you do, but that is just for compatibility with FGC; in FGC that approach is better) (I erased all other parts of the code, just a snippet of course, normally there is some if tokenCT, too, etc. )

local tokenCT = CombatManager.getTokenFromCT(nodeCT);
local wToken, hToken = tokenCT.getSize();
if UtilityManager.isClientFGU() then
    local nDU = GameSystem.getDistanceUnitsPerGrid();
    local nSpace = math.ceil(DB.getValue(nodeCT, "space", nDU) / nDU)*100;
    wToken = nSpace;
    hToken = nSpace;
end

So, the idea is just to use the space variable of tokens as defined in the CT, the 100 in that formula is for converting it to the percentage unit (hence, change the 100 to whatever relative size you want it to be) That is saver and persistent unit and, thence, easier to handle. Surely still possible with getSize, maybe by using a relative ratio with the overal image size or something like that, but before you mess with that it may be just easier just to use the space variable in the CT

[SilentRuin]

Yes, as Moon Wizard wrote the size of a widget is differently used in FGC and FGU. Moreover, I have a similar extension for 3.5e/PF1, adding wound and save overlays, so, I had to look at that, too. You can test with debugging that the tokenCT.getSize() actually returns the pixels (I have the same method of getting tokenCT). You can test that by just taking one token and debug the width and height on different maps with different resolutions. But, since FGU interprets these numbers as percentages of the grid sizes, you need always the same number on every map to make your widget consistent. For example, a widget covering precisely one square of the grid should have the width=height=100, always, on any map in FGU. Because getSize gives you the pixel size in your case though, which is different in general when comparing different maps, you get different results.

Hence, my suggestion is the following code (Initially I load the width and height still as you do, but that is just for compatibility with FGC; in FGC that approach is better) (I erased all other parts of the code, just a snippet of course, normally there is some if tokenCT, too, etc. )

local tokenCT = CombatManager.getTokenFromCT(nodeCT);
local wToken, hToken = tokenCT.getSize();
if UtilityManager.isClientFGU() then
    local nDU = GameSystem.getDistanceUnitsPerGrid();
    local nSpace = math.ceil(DB.getValue(nodeCT, "space", nDU) / nDU)*100;
    wToken = nSpace;
    hToken = nSpace;
end

So, the idea is just to use the space variable of tokens as defined in the CT, the 100 in that formula is for converting it to the percentage unit (hence, change the 100 to whatever relative size you want it to be) That is saver and persistent unit and, thence, easier to handle. Surely still possible with getSize, maybe by using a relative ratio with the overal image size or something like that, but before you mess with that it may be just easier just to use the space variable in the CT

Yeah I looked at the updateEffectsHelper (assuming that is what moon wizard was talking about) and they just hardcoded sizes for the FGU side of things (cheated like I am). But I'm going to experiment with your solution as I literally hate arbitrarily hardcoding sizing with an utter guess.

I'll reply here how it turns out.

[SilentRuin]

Yes, as Moon Wizard wrote the size of a widget is differently used in FGC and FGU. Moreover, I have a similar extension for 3.5e/PF1, adding wound and save overlays, so, I had to look at that, too. You can test with debugging that the tokenCT.getSize() actually returns the pixels (I have the same method of getting tokenCT). You can test that by just taking one token and debug the width and height on different maps with different resolutions. But, since FGU interprets these numbers as percentages of the grid sizes, you need always the same number on every map to make your widget consistent. For example, a widget covering precisely one square of the grid should have the width=height=100, always, on any map in FGU. Because getSize gives you the pixel size in your case though, which is different in general when comparing different maps, you get different results.

Hence, my suggestion is the following code (Initially I load the width and height still as you do, but that is just for compatibility with FGC; in FGC that approach is better) (I erased all other parts of the code, just a snippet of course, normally there is some if tokenCT, too, etc. )

local tokenCT = CombatManager.getTokenFromCT(nodeCT);
local wToken, hToken = tokenCT.getSize();
if UtilityManager.isClientFGU() then
    local nDU = GameSystem.getDistanceUnitsPerGrid();
    local nSpace = math.ceil(DB.getValue(nodeCT, "space", nDU) / nDU)*100;
    wToken = nSpace;
    hToken = nSpace;
end

So, the idea is just to use the space variable of tokens as defined in the CT, the 100 in that formula is for converting it to the percentage unit (hence, change the 100 to whatever relative size you want it to be) That is saver and persistent unit and, thence, easier to handle. Surely still possible with getSize, maybe by using a relative ratio with the overal image size or something like that, but before you mess with that it may be just easier just to use the space variable in the CT

Yeah I looked at the updateEffectsHelper (assuming that is what moon wizard was talking about) and they just hardcoded sizes for the FGU side of things (cheated like I am). But I'm going to experiment with your solution as I literally hate arbitrarily hardcoding sizing with an utter guess.

I'll reply here how it turns out.

Those changes seem to be fine but the difference between what you did - and my cheat 2.25 value - is that when you actually make the token larger (like I do if I have them on a really large map) the bloodsplat will be large proportionally also. In your way they stay the original size (don't resize).

I suppose there is a way to take scaling into account but it messed up the sizes radically when I experimented previously - so until someone reports another sizing issue I'll probably stick with that made up ratio (which worked for the NPC's from MM etc. and the created by hand ones that gave the previous person troubles).

I still think yours is "correct" way to do it - and will do it at some point if I want to mess with the scaling of the tokens (SHIFT MOUSE WHEEL) - but for now I'll let it sit and simmer. If nobody has any problems I'll just slowly fade into the background and hope nobody notices the 2.25 * height/width kludge.

[though if someone is using this FGU version of death indicator in FGC I may have to revisit - even though I explicitly say it is for FGU)

[Kelrugem]

Those changes seem to be fine but the difference between what you did - and my cheat 2.25 value - is that when you actually make the token larger (like I do if I have them on a really large map) the bloodsplat will be large proportionally also. In your way they stay the original size (don't resize).

I suppose there is a way to take scaling into account but it messed up the sizes radically when I experimented previously - so until someone reports another sizing issue I'll probably stick with that made up ratio (which worked for the NPC's from MM etc. and the created by hand ones that gave the previous person troubles).

I still think yours is "correct" way to do it - and will do it at some point if I want to mess with the scaling of the tokens (SHIFT MOUSE WHEEL) - but for now I'll let it sit and simmer. If nobody has any problems I'll just slowly fade into the background and hope nobody notices the 2.25 * height/width kludge.

[though if someone is using this FGU version of death indicator in FGC I may have to revisit - even though I explicitly say it is for FGU)

So, you want to have blood size covering the token as shown on the map? You can change the 100 to any other sizing you basically want; my formula's value only changes when you change the space variable in the CT, the actual token size shown on the map does not change it. So you could then just adjust the size number in the CT, I mean (normally the tokens sizes on a map are in alignment to the size number in the CT; when I want to make them larger, I normally adjust the size variable in the CT, but maybe not everyone is doing it like that )

[Kelrugem]

I just tried and that may work, it takes the actual token size into account:

local wToken, hToken = tokenCT.getSize();
local vImage = ImageManager.getImageControl(tokenCT, true);
local gridlength = vImage.getGridSize();
wToken = (wToken/gridlength)*100;
hToken = (hToken/gridlength)*100;

However, when you change the token size while there is already a blood overlay on it, then you may want to add some UpdateHandler to update the overlay stuff, too Hope that works better (also here: adjust the 100 to whatever relative size you want it to be, in percentage )

EDIT: Only tested on square grids

[SilentRuin]

I just tried and that may work, it takes the actual token size into account:

local wToken, hToken = tokenCT.getSize();
local vImage = ImageManager.getImageControl(tokenCT, true);
local gridlength = vImage.getGridSize();
wToken = (wToken/gridlength)*100;
hToken = (hToken/gridlength)*100;

However, when you change the token size while there is already a blood overlay on it, then you may want to add some UpdateHandler to update the overlay stuff, too Hope that works better (also here: adjust the 100 to whatever relative size you want it to be, in percentage )

EDIT: Only tested on square grids

Yeah don't want the overhead of another handler just for this. I tried printing out everything I know about the token and the bloodsplat image but the only thing I can print out about a widget is the getSize() value which will be 0 before I can place it. I know every bloodsplat image is 100x123px (which there appears to be no call to retrieve that information). I tried two maps - one had gridlength of 30 and the other one had a gridlength of 32. The getSize() for the tokens varied wildly depending on the token and the getImageSize() for the token varied only in terms of medium/large/etc. The scale was outright confusing because I think its really not a raw scale being applied but a calculated scale tailored to the particular token being applied.

Point being - the "2.25 * token height/width" works consistently across my maps and across SHIFT mouse wheel token enlargements. But I've yet to figure a way to calculate that number from all the token data I've printed out in my logs. And of course suspect there will be some way to screw it up (maybe if any of the splat images are ever different from 100X123 Px). Gist being - it makes no sense to me which I do not like. However, it works better than any other solution (as yours would require some sort of handler to compensate for token size changes on the fly).

So for now - till it proves a problem (once again somewhere) - I'm going to leave it with the kludge factor of 2.25.

[Kelrugem]

Yeah don't want the overhead of another handler just for this. I tried printing out everything I know about the token and the bloodsplat image but the only thing I can print out about a widget is the getSize() value which will be 0 before I can place it. I know every bloodsplat image is 100x123px (which there appears to be no call to retrieve that information). I tried two maps - one had gridlength of 30 and the other one had a gridlength of 32. The getSize() for the tokens varied wildly depending on the token and the getImageSize() for the token varied only in terms of medium/large/etc. The scale was outright confusing because I think its really not a raw scale being applied but a calculated scale tailored to the particular token being applied.

Point being - the "2.25 * token height/width" works consistently across my maps and across SHIFT mouse wheel token enlargements. But I've yet to figure a way to calculate that number from all the token data I've printed out in my logs. And of course suspect there will be some way to screw it up (maybe if any of the splat images are ever different from 100X123 Px). Gist being - it makes no sense to me which I do not like. However, it works better than any other solution (as yours would require some sort of handler to compensate for token size changes on the fly).

So for now - till it proves a problem (once again somewhere) - I'm going to leave it with the kludge factor of 2.25.

Yeah, the getSize depends on token image size which can depend on the image resolution (because of the automatical sizing of tokens)

But yes, too messy to mess with when one also wants something dynamic; then the "kludge factor" or the "CT size number formula" approach (which is basically also just some kludging ) is way easier Overlays shall just depict certain states to help to quickly see the state, and that is certainly the case And when someone changes the sizes manually for some reason, then they can just update the wound number (and the CT size number in my case) to force an update of the wound overlay with respect to sizing