v11 Support?

[GambetTV]

Any chance mhilbrunner or someone else might update for v11? I checked out mhilbrunner's v10 fork for v11 and it's definitely broke.

[MiniGrief]

Temporary fix with little testing done. Use this version: https://github.com/mhilbrunner/token-hud-wildcard

Change line 28 of main.js to const prototypeData = token._source;

[GambetTV]

Seems to work. I also talked to the Token Variant Art guy and he said he'll add the ability to scale your tokens with the scaleX tags of this module, which will mean anyone still sticking with this for that functionality might be able to go to that module. It has way more functionality than I need it to, but if it at least does the same thing this one does and gets updated consistently that's going to be a life saver. This is my most vital module, and it has been awful cobbling together fixes since v8 or 9.

[MiniGrief]

Seems to work. I also talked to the Token Variant Art guy and he said he'll add the ability to scale your tokens with the scaleX tags of this module, which will mean anyone still sticking with this for that functionality might be able to go to that module. It has way more functionality than I need it to, but if it at least does the same thing this one does and gets updated consistently that's going to be a life saver. This is my most vital module, and it has been awful cobbling together fixes since v8 or 9.

Yeah, is likely better to just switch to that if it works fine for your use case. Personally, I find the extra functionality too much for what I need so I prefer to keep fixing this haha.

[GambetTV]

I very much agree!

[mhilbrunner]

@MiniGrief @GambetTV Updated my fork to include the fix, should now work on v11 :)

[GambetTV]

It works, although with 2 caveats that weren't present in v10. The first is that it no longer seems to remember what the prototype token's scale is set to, and so unless you have 100% of your tokens marked with a scale tag in their filename, anytime you swap to one that doesn't, it will maintain its current scale. For instance, let's say my prototype token is set to Scale 1, and I have 2 images, one is named Bob1.png, and the other is named Bob2scale2.2.png. When I swap to Bob2, it's going to increase it's scale to 2.2, which is good. But when I swap back to Bob1.png, it's going to maintain the 2.2 scale, because it's no longer looking at the prototype token in these cases like it used to.

The second issue is that when a token increases/decreases its scale when swapping between images, it animates it, which can look quite goofy.

Other than that, it seems good to go! Thank y'all!

[MiniGrief]

It works, although with 2 caveats that weren't present in v10. The first is that it no longer seems to remember what the prototype token's scale is set to, and so unless you have 100% of your tokens marked with a scale tag in their filename, anytime you swap to one that doesn't, it will maintain its current scale. For instance, let's say my prototype token is set to Scale 1, and I have 2 images, one is named Bob1.png, and the other is named Bob2scale2.2.png. When I swap to Bob2, it's going to increase it's scale to 2.2, which is good. But when I swap back to Bob1.png, it's going to maintain the 2.2 scale, because it's no longer looking at the prototype token in these cases like it used to.

The second issue is that when a token increases/decreases its scale when swapping between images, it animates it, which can look quite goofy.

Other than that, it seems good to go! Thank y'all!

I didn't catch those issues as I never use scaling. If I get some free time, I might look at fixing it but can't promise anything.

[MiniGrief]

@GambetTV I think I managed to fix these. Same as before with very little testing done so might be something that goes wrong.

Change line 28 to const prototypeData = token.delta.syntheticActor.prototypeToken;

Change line 151 to updateTarget.update(updateInfo, {animate: false});

@mhilbrunner Might want to update your fork again if this ends up being fine. But also keep in mind these changes will break v10 support so might want to mention that in the README.

[devteamplus]

I find that if you select anything other than the first four image options, it makes the token disappear.

[MiniGrief]

I find that if you select anything other than the first four image options, it makes the token disappear.

I can't reproduce it, do you have any errors in your console (F12) when it happens?

[GambetTV]

@MiniGrief Sorry it took so long to get back to you on this, but your fixes seem to work!

[mhilbrunner]

@MiniGrief @GambetTV (and everyone else): I incorporated the latest batch of changes posted above finally, and also fixed a few others. I pushed a new release and also officially took over the abandoned module page for now: https://foundryvtt.com/packages/token-hud-wildcard

So you all should once again be able to just install and update it via the Foundry module manager. Please ping me for any issues.

(Note that whether or not to animate the size change has become a module setting)

[GambetTV]

@mhilbrunner This is great! And it seems to work great too, so thank you very much for this.

I notice that on your page there's no option to open an issue ticket. Is that intentional? I only ask because while a few of us might know to come back here to do it, anyone new who installs the module might not understand what's going on.

[devteamplus]

I just updated to the latest version of the module. It works basically. However, when I use the "hud" to select a new animation (even if it's the same one that is set to the drop default), my framerate is cut in half, and all other animations are slowed down by, at least, half. I tried this in a brand-new scene that is basically blank, with the exception of two animated tokens. As soon as I pick one and make a selection from the hub, the FPS drops to half of what it was, and the other token animation slows by, at least, half.

[mhilbrunner]

@GambetTV Thanks for noticing, I originally disabled Issues when it was just a fork... re-enabled, should be able to open issues now!

@devteamplus I never tested this with animated tokens, will see if I can reproduce that. Are you using .webms or something else?

[devteamplus]

@devteamplus I never tested this with animated tokens, will see if I can reproduce that. Are you using .webms or something else?

Yes... using 'webm' animations from Gorgon.

[devteamplus]

Also, is there any way to "lighten" the display of the "hud" items? Some are so dark that they're impossible to see..

[MiniGrief]

I just updated to the latest version of the module. It works basically. However, when I use the "hud" to select a new animation (even if it's the same one that is set to the drop default), my framerate is cut in half, and all other animations are slowed down by, at least, half. I tried this in a brand-new scene that is basically blank, with the exception of two animated tokens. As soon as I pick one and make a selection from the hub, the FPS drops to half of what it was, and the other token animation slows by, at least, half.

If I had to guess, it might be due to autoplaying all the webms at the same time. Removing autoplay on line 12 of hud.html might sort it. I don't have any webms to test this with as I don't use animated tokens so I could be wrong.

Also, is there any way to "lighten" the display of the "hud" items? Some are so dark that they're impossible to see..

Try look in the settings for image opacity. It should be set to 50% by default.

[devteamplus]

If I had to guess, it might be due to autoplaying all the webms at the same time. Removing autoplay on line 12 of hud.html might sort it. I don't have any webms to test this with as I don't use animated tokens so I could be wrong.

Done - and that seems to have worked to stop the reduction in FPS

Try look in the settings for image opacity. It should be set to 50% by default.

Set it to 100% and it's the same - no change.