-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
#34 I also don't recommend doing this unless you heavily rely on this module and need it fixing asap. |
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. |
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. |
foundryvtt/foundryvtt#8069 |
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.) |
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. |
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: |
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" 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. |
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:
|
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. |
@GambetTV Should be fixed thanks to MiniGrief, if you update the module from my fork/reinstall it should be fixed :) |
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. |
@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. |
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? |
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 |
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.
The text was updated successfully, but these errors were encountered: