Token Effect widgets (PF/3.5)

[Ken L]

A long time ago prior to the 3.0 update, I had an extension that replaced the condition token widgets from 12x12 to 24x24 icons and and the width adjusted appropriately. Since then I've been running Shadowrun which lacks this functionality so I never really bothered. Returning to PF and pushing my grid units to 50x50 as opposed to 30x30 has made my widgets appear microscopic.

This makes it a problem, putting in 50x50 icons to have the effect widgets 'appear' to be larger on a 50x50 token is such a hacky solution.

1. How does FG scale them, and what is the ratio between bitmap widgets and the tokens they're attached to?
2. Where can one adjust this ratio if it is in fact a ratio?
3. Can it be toggled such that it is always absolute irregardless of grid or token scale (but not zoom for obvious reasons)?

[damned]

Hi Ken L I dont have the answers to your questions but if this is in an existing campaign can you try releasing token scale and checking what happens?

[Ken L]

Releasing the scale will pull it out of the grid to the original image size. Re-enabling token scale will now have the icons behave absolutely oddly enough... There's some very strange logic going on here as I suspect it was holding on to an old grid scale value perhaps.

[damned]

You can rescale them again after you release the scale. There are some quirks/issues with the widgets and scaling. Releasing scaling often solves the issue in the short term. There are a couple of threads on the issue and Im not sure its one that will be fixed.

[Ken L]

Now here's a hilarious follow up.

So we all know the cheesy windows95 bobbing of the effect widgets and health indicatiors when rotating...
https://i.imgur.com/Qc7Rt2w.gif
As to why that is, I suppose that will forever be a mystery related to the widget setPosition call.

So I figured let's make the anchor the center point rather than bottom left with an adjusted offset. Now due to the center anchor, and the widget properties of being contained within the parent, it'll show fewer effect widgets, a small trade off....
https://i.imgur.com/fKqjUwq.gif
But due to the negative offset and the the wonky parent containment, we get some mystery behavior with scaling.

I feel like there's some 'splaining that needs to be had around the widget black box container logic.

All changes are made in 'manager_token2.lua' in the 3.5E ruleset.


The following isn't terribly a large leap, For the maintainer, there's an equivalent line also changed for 'mark hover' so I'm omitting it for bevity, same with the TOKEN_EFFECT_WIDTH.


w.setPosition("bottomleft", TOKEN_EFFECT_OFFSETX + ((TOKEN_EFFECT_WIDTH + TOKEN_EFFECT_MARGIN) * (i - 1)), TOKEN_EFFECT_OFFSETY);




w.setPosition("center", math.floor(0-(wToken/2) + TOKEN_EFFECT_OFFSETX + ((TOKEN_EFFECT_WIDTH + TOKEN_EFFECT_MARGIN) * (i - 1))), math.floor((hToken/2) + TOKEN_EFFECT_OFFSETY));


This is a problem with the container logic it appears as it manifests that booping behavior in the base vanilla 3.5E.

[Moon Wizard]

Realistically, we're not working on any of the token and image code at this point, because it's all being completely replaced for the FGU project.

I would have to rebuild the model of what is going on, but there were many limitations around the widgets of tokens relating to sizing, since there were so many sizes and scales to consider (widget pixel size, token pixel size, map pixel size, token size ratio, token-to-map scale, token-to-widget scale, ...) The widgets were only designed to support decorations on window controls, but we co-opted to use for tokens. So, there are several limits to the way they work.

Just wanted to provide some background.

Regards,
JPG

[Ken L]

Here's hoping that the widget container structure is better in unity.