Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Foundry v10 Support? #33

Open
GambetTV opened this issue Sep 1, 2022 · 19 comments
Open

Foundry v10 Support? #33

GambetTV opened this issue Sep 1, 2022 · 19 comments

Comments

@GambetTV
Copy link

GambetTV commented Sep 1, 2022

Now that Version 10 of Foundry has been fully released, is any support planned for it? I had heard that the issues that cropped up with v9 (such as players not being able to change their own tokens) have been fixed in this version. Seems like a great time to come back to it.

@MiniGrief
Copy link

MiniGrief commented Sep 4, 2022

#34
Not an ideal fix, but something you can do temporarily is take the main.js from here and replace the main.js in your already installed version of the module. It will still show as unknown compatibility but should at least get it working.

I also don't recommend doing this unless you heavily rely on this module and need it fixing asap.

@GambetTV
Copy link
Author

GambetTV commented Sep 5, 2022

Unfortunately this doesn't really work. When I change the Image Path to a folder and signal for it to be a wildcard, such as Wildcard/Bob/* I get five major errors talking about Model Validation Errors, and it doesn't save the change. And the result isn't a token that can have its image changed.

Appreciate the effort though! This is probably the most vital module to my campaigns, and as much as I want to upgrade to v10 I don't think I'll be able to until this one gets fixed.

@MiniGrief
Copy link

That's just a bug with V10 currently. Tokens which already had their wildcards set should work, but new ones won't until Foundry updates to patch that. Something to do with a validation check oversight mxzf said in the Foundry discord.

@MiniGrief
Copy link

foundryvtt/foundryvtt#8069
This is the issue if you want to keep track of progress for patching it. I assume it'll be in the next stable release.

@MiniGrief
Copy link

MiniGrief commented Sep 9, 2022

Foundry released an update and from a quick test, seems to have fixed this issue. Give it a try and if it fixed it, you should probably mark this as closed. (Or at least let people who read this know that specific issue was related to Foundry, not this.)

@weepingminotaur
Copy link

Any update on when Token HUD Wildcard will be v10 ready?

@MiniGrief
Copy link

Any update on when Token HUD Wildcard will be v10 ready?

I submitted a pull request to make it compatible but the author seems to have abandoned the module. You can do what I suggested in my first reply to get the module functional on v10.

@weepingminotaur
Copy link

Any update on when Token HUD Wildcard will be v10 ready?

I submitted a pull request to make it compatible but the author seems to have abandoned the module. You can do what I suggested in my first reply to get the module functional on v10.

Thanks for letting me know. I might just switch to Token Variant Art when I upgrade to v10.

@mhilbrunner
Copy link

I applied the above fix by MiniGrief and also fixed the default image feature in my fork. Seems to work fine, besides some deprecation warnings in console. I published a release as a temporary workaround until this original repository is updated, if someone wants to install it, use this manifest:
https://raw.githubusercontent.com/mhilbrunner/token-hud-wildcard/master/module.json
Alternatively, download a .zip from the release page.
Thanks to MiniGrief for doing most of the work, and to javieros105 for the module.

@GambetTV
Copy link
Author

mhilbrunner, your fork has largely fixed the compatibility issues for v10, thank you very much for that! I am noticing a new bug is cropping up though, which is some kind of issue with using different scaleX suffixes in image file names. If I have a token with a default scale of 1, all images with no filename references to scale should automatically be sized at 1. This does happen. However, if one of my images uses say, scale1.5 and I switch to that, it scales correctly to 1.5, but when I go back to the original image with no suffix at all, it keeps the scale at 1, instead of reverting it back to the default. Is this anything you can take a look at and try to fix?

@MiniGrief
Copy link

MiniGrief commented Nov 19, 2022

mhilbrunner, your fork has largely fixed the compatibility issues for v10, thank you very much for that! I am noticing a new bug is cropping up though, which is some kind of issue with using different scaleX suffixes in image file names. If I have a token with a default scale of 1, all images with no filename references to scale should automatically be sized at 1. This does happen. However, if one of my images uses say, scale1.5 and I switch to that, it scales correctly to 1.5, but when I go back to the original image with no suffix at all, it keeps the scale at 1, instead of reverting it back to the default. Is this anything you can take a look at and try to fix?

I think I was able to reproduce what you mean and if it's what I think it is then it's not a bug. If you provide no scale, the module is just going to assume you want to keep it at the same scale as it can't possibly know what you intended it to be otherwise. If you specify scale1 on the original image then it should scale back down to 1 as usual.

Here's an example using the names "character_scale1_.png" and "character_scale2_.png"
https://www.youtube.com/watch?v=aplypgz2SLQ

Forgot to record it but I did also test one without a scale too and it kept the scale exactly at what it was set to previously by other scaled images, which is the intended outcome.

@GambetTV
Copy link
Author

So I get that's how it seems to be now. But back in v8 and v9, it would use the Prototype Token's default scale for all images that didn't have a scale specified. So if the prototype token's scale was 1.2, and I had two images, Bob.png and Bob_scale1_.png, Switching from the first to the second image would resize it to Scale 1, and going back to the first would automatically scale it back to 1.2 even though nothing was specified. It would simply default to the prototype.

Looking through the code mhillbrunner's fork uses, it seems like he commented out a part of the code that would cause it to revert back. the code is:

const dimensions = getTokenDimensions(parent, defaultValue); let updateInfo = { img: defaultValue, ...dimensions };

@MiniGrief
Copy link

MiniGrief commented Nov 20, 2022

So I get that's how it seems to be now. But back in v8 and v9, it would use the Prototype Token's default scale for all images that didn't have a scale specified. So if the prototype token's scale was 1.2, and I had two images, Bob.png and Bob_scale1_.png, Switching from the first to the second image would resize it to Scale 1, and going back to the first would automatically scale it back to 1.2 even though nothing was specified. It would simply default to the prototype.

Looking through the code mhillbrunner's fork uses, it seems like he commented out a part of the code that would cause it to revert back. the code is:

const dimensions = getTokenDimensions(parent, defaultValue); let updateInfo = { img: defaultValue, ...dimensions };

The commented out section is inside a hook for preCreateToken so that won't have done that. I think a quick fix for that would be changing 'prototypeData.scale' on line 33 to 'prototypeData.texture.scaleX'. Don't want to add it to any pull requests since not sure if it's intended behaviour, but you should be able to modify your main.js to include that change.

Edit: On second look, it seems like it was intended so I'll include it in an existing pull request I have on mhilbrunner's fork.

@mhilbrunner
Copy link

mhilbrunner commented Nov 25, 2022

@GambetTV Should be fixed thanks to MiniGrief, if you update the module from my fork/reinstall it should be fixed :)

@chrisk123999
Copy link

While using this "updated" version, the default token setting doesn't appear to work while the module "Token Mold" is active. Both of these modules make use of the "preCreateToken" hook. Any chance this could be looked into as Token Mold is a very commonly used module.

@mhilbrunner
Copy link

@chrisk123999 I currently don't have time to look into that and don't use Token Mold myself. If someone can provide a fix, I'm happy to test and include that in the fork.

@rdefendi
Copy link

rdefendi commented Jan 6, 2023

I can second this. I'm not a programmer, but token mold breaks this module completely with the temporary fix in place. It just places the default svg token for all characters.

@MiniGrief
Copy link

While using this "updated" version, the default token setting doesn't appear to work while the module "Token Mold" is active. Both of these modules make use of the "preCreateToken" hook. Any chance this could be looked into as Token Mold is a very commonly used module.

I can second this. I'm not a programmer, but token mold breaks this module completely with the temporary fix in place. It just places the default svg token for all characters.

I would attempt to fix this, but I can't reproduce it. Having both the fork from @mhilbrunner and Token Mold activated doesn't cause anything to break for me. Could you provide a list of every module you have active and what specific Foundry version you're using so I can try reproduce it?

@TheNekoMomo
Copy link

I have made my own add-on based off this one and it has all the same features and is updated for the latest version, if you want to check it out its Momos-Token-Changer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants