Expose support for packing/unpacking ZIP archives to the scripting API

[GlaDOSik]

Describe the project you are working on:
Node based image and material editor.

Describe the problem or limitation you are having in your project:
I would like to be able to pack and unpack user configuration to a single zip file. I will for sure find another usage for it later.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I will be able to do what I cannot do now.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Inspiration can be taken from gdunzip (link below). Zip functionality can be a method in File class (which could zip files and directories).

If this enhancement will not be used often, can it be worked around with a few lines of script?:
It cannot be done with a few lines of script.

Is there a reason why this should be core and not an add-on in the asset library?:
The plugin in GDScript was made but it's only unzip, it doesn't do CRC checks and it's not very fast. The engine already uses some C library (still minizip?) so it shouldn't be hard to expose it to GDScript to get native performance.

Related links 3701, 22440 and gdunzip.

Bugsquad edit (keywords for easier searching): extract, create

[Calinou]

There's a pull request implementing this feature: godotengine/godot#34444

[goatchurchprime]

bzip (brotli zip) might be a more up to date standard to aim for that is quite widely used and is good for compressing small snippets because it uses a common dictionary. I've encountered its in pointclouds files from potree

There is a Javascript implementation of the decompress function here:
https://github.com/potree/potree/blob/37dc46a25ca56683e216c973dd117bc68b75ab0f/libs/brotli/decode.js

It looks like this may have been created by porting the C-code to Haxe and then converting from that into Javascript:
https://github.com/dominikhlbg/BrotliHaxe There's then a Haxe converter that outputs Godot/C#.

(Or I could just work out how to compile C++ asset add-on modules into Godot)

[ssokolow]

@goatchurchprime That would be useless for various plans I have for this.

1. When I use Zip as a container for something like a custom level and all its assets, compression is desirable, but my number one goal is accessibility to modding-minded players without special tools. Support for at least unpacking Zip with DEFLATE is built into all major OSes now.
2. If I want to write support tooling in Godot, Zip with DEFLATE is the popular choice for various existing formats to use as containers, not zip with brotli.

Heck, 7zip only supports brotli in any form via a fork and I'm not sure if that's as a Zip compression type or just as a stream compression to wrap around .tar.

This bug is about exposing scripting access to a packfile format Godot already supports. Proposing a new packfile format is orthogonal to that.

[akien-mga]

We finally got to discuss this with some core contributors in a proposals review meeting, and confirmed that this would be a nice addition to the engine.

One problem @Faless raised with the current implementation in godotengine/godot#34444, which is consistent with all similar APIs in Godot currently, is that everything needs to be loaded in memory before writing, which could be a problem for bigger ZIPs. We'd need some form of read/write file StreamPeer to be able to read/write partial amounts of bytes. But that can be implemented after the fact.