zlainsama/OfflineSkins#57

It would be better if 3D Skin Layers mod provide an API package that accomplish this without hard dependency.

I can look into this. But I'm not too interested in supporting OfflineSkins(or other compareable mods), since their main(and imo only) usecase is playing without having bought minecraft, which is against TOS. I did a few changes that are not yet on CurseForge, that probably might fix this from my end already, but working OfflineSkins is more a side effect than the intended goal.

Good, I don't support it too. I had the need of caching skins when I had really bad internet quite few years ago.
I don't need it since then, but I kept maintaining the mod for those who need it just because I published it.

Give it a try with this build https://github.com/tr7zw/3d-Skin-Layers/actions/runs/2180295740 . While implementing animated skins as a donor reward, I had to improve the skin resolution beyond the Vanilla implementations. Worst case it now pulls the skin from the GPU and caches it internally.

Both artifacts worked, but when a HD Skin was provided through OfflineSkins, JVM crashed.

WIll HttpTextureAccessor change? I can provide an instance of that when 3D Skin Layers is present.
It would be better if I can pre-populate that cache from my end so that it can fail properly if HD Skin was used.

Ah crap I forgot about hd skins. Yea I'll have to rework that part.

I think for now I'll just nuke the GPU parsing part due to HD skins. So it will support HttpTextureAccessor and DynamicTexture(HTTP is the only one used by vanilla mc, Dynamic by the new donor feature). Maybe SimpleTexture if that's required some time later for better mod compatibility. If OfflineSkins just load as HttpTextures like vanilla skins, that should be fine.

Providing a vanilla HttpTexture would require writing the skin file once more onto the storage device.
Because of that, I will provide a special texture instance that implements HttpTextureAccessor, which will return a processed NativeImage instance when getImage is called, if 3D Skin Layers mod is present.
Is this alright to you?

The skin should already be written to the local skin cache? Otherwise, if you downloaded it in some other way, you can just use DynamicTexture. Implementing custom Texture classes won't work.

Oh, okay.
I will move to use DynamicTexture.
This solves a lot things... why didn't I know this class before.

Later today I'll do a release of the 1.18-skins branch to test the waters of the donor feature(does my backend handle the requests/is there an issue with other mods), and that release contains the support for the DynamicTexture.

After looking through my mod's fabric branch commits, there was an compatibility issue with justmap mod, which was resolved with switching to SimpleTexture/ResourceTexture.

Edit: I will just write the file onto the storage device, and use the HttpTexture then.
Edit2: They didn't update their mod for quite some time, and I prefer DynamicTexture.
Edit3: There are updated forks of justmap... HttpTexture?HttpTextureAccessor?SimpleTexture?
Edit4: Nvm, I got it working with HttpTexture and without writing onto storage device.
Edit5: Released a new version of OfflineSkins for both Forge and Fabric, they should be compatible with 3D Skin Layers now.

👍