I write a program for compress VAR files, can I upload it to the hub?

[Han_01]

Hi everyone.
so..... i've write a Python program ,Some VAR take up a lot of disk space , so I need compress this. It’s simple, basically its just compressed the image。

After running, it will search the json file to find the texture, then convert the format of these textures to jpg or png format. and modify the texture path of the json file.

it can compress the file to 1/8 of its original size, very very little loss in image quality.

But I have a concern, does this procedure violates the license? Because this obviously involves modifying the work of others, I want to help people who have the same difficulties as me.
So can I upload it to the hub?

I have poor English, sorry for that.

Thanks!

 

[atani]

The program likely doesn't violate anything because changes are made to the user's files, not in any hub content.
As long as it's stated what it does, users are responsible for understanding its purpose. It would also help to include a translation of the python comments shown in the screenshots to english.

 

[Han_01]

The program likely doesn't violate anything because changes are made to the user's files, not in any hub content.
As long as it's stated what it does, users are responsible for understanding its purpose. It would also help to include a translation of the python comments shown in the screenshots to english.

Oh, Thank you! ! that's really good.

i'll translation the comments, and package code file as .exe file.

 

[atani]

Oh, Thank you! ! that's really good.

i'll translation the comments, and package code file as .exe file.

I'm not sure you can upload exe files, or they might have to be checked first. Don't know.
Better to ask a moderator using the Support tab on top.

 

[Han_01]

I'm not sure you can upload exe files, or they might have to be checked first. Don't know.
Better to ask a moderator using the Support tab on top.

ok, i get it, Thanks!

 

[AshAuryn]

ok, i get it, Thanks!

This is unlikely to be approved. Please open a support ticket.

 

[Sally Whitemane]

The funny thing is, I build the complete opposite of what nunkihanyu does:
I sacrificed texture size by using only DXT (VAM 1 standard, basically the cache is + metadata) and BC7 texture compression in a modified VAM version. Ripped out the original texture loader (and more) and replaced it. There is no support for "filthy peasant" JPG / PNG image formats.

pro:
-much faster loading times, no conversion process (cache generation) needed when a texture loads the first time
-no cache needed, texture loads directly because it's an actual texture format supported by the GPU
-higher quality BC7 texture compression possible (using it for high res skins)

con:
-larger file size for all textures
-while textures could technically have a better quality, they obviously aren't if the source is a low quality lossy compressed JPG
-no quick "image" editing anymore, conversion needed (imho for edits a lossless master image should be used anyway)

Will keep it private because...
Lack of time to support and maintain it. It requires disabling security. Needs to run a command line texture converter from VAM for downloads with VAM's embedded browser. Support nightmare for the VAM team to modified VAM versions floating around.

In total it did not even need more diskspace (I think?!) with the larger DXT/BC5 textures because the cache is gone and no texture is not stored twice anymore as "image" and cached "texture" ... do not have before- and after-numbers unfortunately.

 

[Han_01]

This is unlikely to be approved. Please open a support ticket.

ok, i've sent the support ticket, thanks.

 

[Han_01]

The funny thing is, I build the complete opposite of what nunkihanyu does:
I sacrificed texture size by using only DXT (VAM 1 standard, basically the cache is + metadata) and BC7 texture compression in a modified VAM version. Ripped out the original texture loader (and more) and replaced it. There is no support for "filthy peasant" JPG / PNG image formats.

pro:
-much faster loading times, no conversion process (cache generation) needed when a texture loads the first time
-no cache needed, texture loads directly because it's an actual texture format supported by the GPU
-higher quality BC7 texture compression possible (using it for high res skins)

con:
-larger file size for all textures
-while textures could technically have a better quality, they obviously aren't if the source is a low quality lossy compressed JPG
-no quick "image" editing anymore, conversion needed (imho for edits a lossless master image should be used anyway)

Will keep it private because...
Lack of time to support and maintain it. It requires disabling security. Needs to run a command line texture converter from VAM for downloads with VAM's embedded browser. Support nightmare for the VAM team to modified VAM versions floating around.

In total it did not even need more diskspace (I think?!) with the larger DXT/BC5 textures because the cache is gone and no texture is not stored twice anymore as "image" and cached "texture" ... do not have before- and after-numbers unfortunately.

wow, that looks good, long time to load the cache when loading some characters on my PC. (and eat huge spacedesk)

 

[AshAuryn]

I've also responded in support, but just to make a public statement here --

One issue is that due to recent security concerns, we are unlikely to approve any EXEs on the Hub for the foreseeable future unless they are Official releases.

Another issue I see is that Hub systems use, in some cases, file size and file hash to identify resources and versions. I'm not sure what trouble could arise from a script that changes those values on the local drive. I'm specifically thinking of trouble for creators, mostly.

Another concern I have is generally any script that proposes to modify large portions of your content automatically has the potential to irreversibly damage your collection. Not saying this would, necessarily, but even if we were able to allow it (which we probably can't) it would require a huge warning label letting users know there could be unforeseen consequences that could ruin their collection of vars.

 

[Han_01]

I've also responded in support, but just to make a public statement here --

One issue is that due to recent security concerns, we are unlikely to approve any EXEs on the Hub for the foreseeable future unless they are Official releases.

Another issue I see is that Hub systems use, in some cases, file size and file hash to identify resources and versions. I'm not sure what trouble could arise from a script that changes those values on the local drive. I'm specifically thinking of trouble for creators, mostly.

Another concern I have is generally any script that proposes to modify large portions of your content automatically has the potential to irreversibly damage your collection. Not saying this would, necessarily, but even if we were able to allow it (which we probably can't) it would require a huge warning label letting users know there could be unforeseen consequences that could ruin their collection of vars.

Yes, I just realized that the problem that vam sometimes couldn't load var files was caused by my script, I thought it was because I had too many var files.

 

[Origin69]

In other news, I've discovered a device that let's you park multiple vehicles in a one car garage.