[extension] Spell Tokens Extension

Quote:

---

Originally Posted by Weissrolf

This answer confused me, because I saw a different/better behavior. Then I did some tests and saw the behavior you described, but only for player tokens, while NPC tokens were not clickable. Then I noticed that the "Extra selection mode" seems to be broken in that it always resets the (N)PC token back instead of the spell token.

Then I cracked it: If any overlay is applied to any token via an extension (like "Has initiative" or "Wound overlay") then these tokens can directly be grabbed and moved underneath a spell token. The only drawback is that even player tokens get covered after being moved unless the spell token is clicked again. This works for both players and GMs, locked or unlocked.

As a consequence I edited "Wound overlays" to overlay a transparent PNG for the "Healthy" wound status:
https://i.imgur.com/jtr7CxE.gif

---

I dont see the (N)PC issue, when i have a spell token over a (n)pc on drag it always returns the spell token if you drag the stack or just the spell token if you drag select away from the (n)pc.

But you find on the overlay is interesting... if we can make that work then we need to not worry about the stack order in these cases, and only deal with keeping things like spirit guardians 'with' the (n)pc when it moves... which might then be better as an 'addbitmap' overlay as I'm sure most users will be ok with it not rotating.

Quote:

---

Originally Posted by Weissrolf

This answer confused me, because I saw a different/better behavior. Then I did some tests and saw the behavior you described, but only for player tokens, while NPC tokens were not clickable. Then I noticed that the "Extra selection mode" seems to be broken in that it always resets the (N)PC token back instead of the spell token.

Then I cracked it: If any overlay is applied to any token via an extension (like "Has initiative" or "Wound overlay") then these tokens can directly be grabbed and moved underneath a spell token. The only drawback is that even player tokens get covered after being moved unless the spell token is clicked again. This works for both players and GMs, locked or unlocked.

As a consequence I edited "Wound overlays" to overlay a transparent PNG for the "Healthy" wound status:
https://i.imgur.com/jtr7CxE.gif

---

Ive had a quick look at 'wounds overlay', and i can see its adding a bitmap but does not seem to be doing anything else. I dont understand why this would cause the token to be on top of draw stack over the spell tokens. And I dont see why this is any different to the already health 'dot'/'effects' bitmaps that are setup without the extension, why are these not causing the same draw stack order.

I'll keep looking, maybe its related to the widget.bringToFront() functions... so I might be able to add a blank spell token bitmap to the spell tokens and use the widget.setToBack to try and keep the spell tokens at the back..

If you have any thoughts on this let me know.

Yeah, that widget.bringToFront() smiled at me as well. Curiously this leads to PC tokens being send to behind the spell token, which they normally would be in front of. But with semi-transparent spell-tokens this is less of a problem (no horse-riding, though) as long as (N)PC tokens can simply be grabbed the way they can with the bitmap trick.

Watch out when you create your blank token bitmap. I first tried a bitmap where I deleted everything from the light wound overlay and it did not work. Then I tried deleting everything but a single pixel and FGU would not display it at all. Then I simply set the (single) layer transparency of the light wound overlay to 0%, saved it as new file and this one works.

Quote:

---

Originally Posted by bratch9

See attached for the location, but you have to unpack unity resource packages to get to the directory structure, and to make a change you would have to re-pack the required resource unit package.

---

Which software do you use to extract and repackage the files? I found AssetsStudio and AssetsBundleExtractor, but the first can only export and the latter works with some "raw" format.

Quote:

---

Originally Posted by Weissrolf

Which software do you use to extract and repackage the files? I found AssetsStudio and AssetsBundleExtractor, but the first can only export and the latter works with some "raw" format.

---

I did not repackage it, I only unpacked it. I only wanted to confirm it was in the asset pack and that I have not missed it in the rule set data side.

I think tool talk of this nature is not something for the forums, I'm sure FG mod/dev might take an issue.

-pete

Quote:

---

Originally Posted by Weissrolf

Yeah, that widget.bringToFront() smiled at me as well. Curiously this leads to PC tokens being send to behind the spell token, which they normally would be in front of. But with semi-transparent spell-tokens this is less of a problem (no horse-riding, though) as long as (N)PC tokens can simply be grabbed the way they can with the bitmap trick.

Watch out when you create your blank token bitmap. I first tried a bitmap where I deleted everything from the light wound overlay and it did not work. Then I tried deleting everything but a single pixel and FGU would not display it at all. Then I simply set the (single) layer transparency of the light wound overlay to 0%, saved it as new file and this one works.

---

The bring to front is not the cause of this 'solution', it work the same with send to back the (n)pc tokens are selected on top of the spell tokens even when drawn under the spell token.

It also looks like a 'bug' in FG because I would not expect the mouse selection code to be out of sync with the draw order... most people would expect visual order for selection. ( So it might get 'fixed' at some point. )

It looks more like the fact that the widget bitmap is deleted on every update, which is not the case in the rule set for health bar/dot/effect which update the bitmap details not re-create them..

I'm looking further into it to see if I can get to a minimal something to add to my extension, as I'd like to remove lots of selection code in the extension and get things like locked tokens working etc..

-pete

Quote:

---

Originally Posted by bratch9

The bring to front is not the cause of this 'solution', it work the same with send to back the (n)pc tokens are selected on top of the spell tokens even when drawn under the spell token.

It also looks like a 'bug' in FG because I would not expect the mouse selection code to be out of sync with the draw order... most people would expect visual order for selection. ( So it might get 'fixed' at some point. )

It looks more like the fact that the widget bitmap is deleted on every update, which is not the case in the rule set for health bar/dot/effect which update the bitmap details not re-create them..

I'm looking further into it to see if I can get to a minimal something to add to my extension, as I'd like to remove lots of selection code in the extension and get things like locked tokens working etc..

-pete

---

So what is happening is that bitmap widgets live above all the graphics from what I can see. So while the 'wounds overlay' shows this up for you, you can drag the (n)pc token that is under a spell token with any of the bitmap widgets like the 'effects' or 'health'. They are small but they do work. As the wounds overlay covers the bulk area of the (n)pc token this is what you are dragging... ( not the token... but the token gets dragged with it sort of. )

I'm going to look to see if I can add a transparent token over the combat tracker tokens when the combat tracker adds all the other bitmap layers, so it will only be done once when the token is added to the map. But not on my spell tokens add.

But thanks for the find on this one, I has assumed bitmap images on a token were processed at the token level.

Quote:

---

Originally Posted by bratch9

I did not repackage it, I only unpacked it. I only wanted to confirm it was in the asset pack and that I have not missed it in the rule set data side.

I think tool talk of this nature is not something for the forums, I'm sure FG mod/dev might take an issue.

---

I can replace them directly within the package now, but obviously that only works until the next update. So allowing to theme the selection rings would be a better option.

Here I just quickly got rid of the background texture within and around the circle. Makes things more visible already.
https://i.imgur.com/LkWwZyy.png

Quote:

---

Originally Posted by Weissrolf

I can replace them directly within the package now, but obviously that only works until the next update. So allowing to theme the selection rings would be a better option.

Here I just quickly got rid of the background texture within and around the circle. Makes things more visible already.
https://i.imgur.com/LkWwZyy.png

---

That does look nice. ( If you increased the resolution would it still work, at that size its staring to show pixels due to the spell token large size.. )

Maybe you could start a thread and ask FG mod/dev if it is ok to talk about the tools you used to do that, or if they are willing (maybe wish-list it ) to allow theme access for us to be able to replace these/and other things ?

I'm sure some users would be happy to hand update the game if it could be automated with a few installed tools. ( And lost on an version update, the pack resources are not updated on every update. )

Just not sure on the legality of doing a resource pack change like this.

-pete

Quote:

---

Originally Posted by Weissrolf

I can replace them directly within the package now, but obviously that only works until the next update. So allowing to theme the selection rings would be a better option.

Here I just quickly got rid of the background texture within and around the circle. Makes things more visible already.
https://i.imgur.com/LkWwZyy.png

---

Ive pushed a build for forge approval with an invisiable bitmap on combat tracker tokens.

So look out for that update later, when i can make it live..

This should help the selection process and allow me to remove a chunk of 'fixes' to work around the selection issues. And with selection working better the token lock is working and cursor keys for movement etc...

Now I will have to strip out a bunch of code, and get things like spirit guardian spell tokens 'sticking' with the (n)pc token when they move. Then I can get back to doing the 'select target' on a key press while you drag the spell token about.

-pete