How to prevent ItemsAdder from overwriting 3rd-party compressed zips?

xRebelD

ItemsAdder does an amazing job at compressing PNGs. However, it doesn't handle JSONs in by itself, nor does it go in true depth with the compression as some of us might need. We're using external tools in order to compress our resource pack (with reductions of 3-7MB in size), and for that we work with the "generated.zip" archive in the output folder. When we add back the compressed resourcepack, ItemsAdder immediately overwrites it on the next /iazip, rendering our work useless.

Is there a way through which we can avoid this from happening?

ItzASecretBoi

Well i'm pretty sure ItemsAdder actually does automatically compress .json files assuming this is enabled in config.yml, as for your question of canceling the overwriting, I looked through the config and didn't see anything personally, so I'm not sure. Maybe @LoneDev can shed some light on it?

LoneDev

ItemsAdder immediately overwrites it on the next /iazip, rendering our work useless.

Well it's normal, how it's supposed to apply changes without touching the zip file?
ItemsAdder (and any other plugin in the world) cannot edit the zip file without, well, editing it.

We're using external tools in order to compress our resource pack

I don't know which tool are you using nor how you trigger the tool, but I can code an event in ItemsAdder API which is triggered when the resourcepack is ready so you can hook into it and trigger your tool to handle the zip file re-compression and optimization.

Would that work for you?

Or you can still continue doing it manually after each /iazip, as I highly doubt you need to make changes to your resourcepack everyday or more than 3 times a month.
Note: you don't need to run your compression tool each time you edit the ItemsAdder resourcepack, do it only when you are ready to release it to the public and you finished your changes. It's not useful to do that each time you add an item when you're still working on the pack updates (my opinion based on how server usually are handled).

I hope this is enough to clarify the situation, have a nice week 😄

xRebelD

Hey @LoneDev we're using PackSquash (https://github.com/ComunidadAylas/PackSquash) which works directly on the resource pack folder, hence the need to unzip, compress, and re-zip. I don't know if an integration would be possible, but PackSquash helped us a lot in cutting down our resource pack sizes so we'd love to be able to continue using it.

My problem is mostly that I have no idea how to have the plugin use the generated (and manually compressed) zip file instead of generating its own & overwriting it. While a iazip of course overwrites the file, I'm not sure if a restart would replace the resource pack in cache with the one we compressed, or simply trigger an overwrite again.

Would a solution be a config-option that prevents overwriting the generated.zip file on restart? Not so knowledgeable on the topic, so sorry if this doesn't make much sense.

LoneDev

ItemsAdder doesn't overwrite generated.zip file on restart, I don't know what you're talking about.
The only occasion when the generated.zip file is regenerated and overwritten is when the /iazip command is triggered as the plugin has to generate the pack again and add/edit content.

xRebelD

Noted, sorry for the confusion. I was under the impression that ItemsAdder cleans its cache and reloads the resource pack whenever the server restarts. Given that, I assume replacing the generated.zip archive and then restarting the server would do the trick and make ItemsAdder load the pack we uploaded after compression?

LoneDev

I was under the impression that ItemsAdder cleans its cache and reloads the resource pack whenever the server restarts.

No, contrary to other plugins ItemsAdder writes the resourcepack only if you run /iazip.
It has no sense to waste CPU processing to generate the pack on each restart (some plugins do that).

I assume replacing the generated.zip archive and then restarting the server would do the trick and make ItemsAdder load the pack we uploaded after compression?

Yes