Hi. I’d like to implement .zip support for vcmi (mostly for mods).
It seems that most easiest way to do this is to use minizip library: winimage.com/zLibDll/minizip.html
This library depends only on zlib which is already used by vcmi.
The problem is that this library seems to be unavailable in most of Linux distributions. This means that we need to provide it alongside with vcmi. Since library is really small this won’t be a problem.
What I’d like to do is to:
add minizip into vcmi trunk. Probably at lib/minizip
add implementation of resource loader interface into vcmi library so zip’s can be loaded just like H3 archives
Question is: how minizip should be linked with vcmi library? Dynamic library, static library or just include those few files from minizip into vcmi library?
I prefer having dynamic library so it can be easily disabled if minizip is already installed but if there are some issues I’m not aware of I’m OK to switch to another method.
Definitely as a library, with build time detection of system wide library existence. When provided vcmi/lib/minizip is used you shall install resulting dynamic library into %_libdir/vcmi and use rpath in vcmi lib, or build it in as static. Including anything into VCMI library sources is the worst thing you can do.
I have some serious problems linking minizip as dynamic library. To do that, I need .lib object file, which should be generated by MSVC. Still, it doesn’t appear. According to internet sources, this may happen if no functions are exported, like this
Indeed, zconf.h defines the following (just nothing)
# define ZEXPORT
Still, not sure if and how should I override it, or the issue is somewhere else
I have made changes to the required projects (lib + minizip), I have added the minizip to solution, added VCMI_DEBUG property sheets (for path inheritance), but now I am stuck on minizip with:
Error 3 error LNK2019: unresolved external symbol _inflate referenced in function _unzReadCurrentFile C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj minizip
Error 4 error LNK2019: unresolved external symbol _inflateEnd referenced in function _unzCloseCurrentFile C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj minizip
Error 5 error LNK2019: unresolved external symbol _crc32 referenced in function _unzReadCurrentFile C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj minizip
Error 6 error LNK2019: unresolved external symbol _inflateInit2_ referenced in function _unzOpenCurrentFile3 C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj minizip
Probably the same ZEXPORT, but I am clueless on how to fix it.
physfs is used by asc, blobby2, lincity-ng, tmw and warzone2100 (and some not games like SDL_sound or paragui). OTOH minizip is used by chromium (web browser), libdigidocpp, psi (communicator) and VLC - it seems to be more generic, so physfs designed especially for game archives purpose should be more suitable.
As for physfs not sure. Main physfs purpose is to create virtual file system - pretty much what we already have in lib/filesystem. Judging from code it does not looks like we can just take .zip support from it - too integrated in the rest of code. And we can’t replace our own VFS with it - for example we need H3 archives that use custom format to be part of VFS as well - physfs does not allows extensions. Our VFS allows “mounting” archives at any path, physfs allow mounting only at root.
I committed project files and changes to minizip that made it working on my installation.
Let me know if they work for you — I wasn’t able to get it working with Warmonger’s project files (even with krs’ patch)
By the way, is current mod system permits only one folder, from where mods are loaded?
Or is it possible to use 2 or more paths where mods will be stored?
I ask because now I have some final mods (like Cove) and mods-in-progress.
It will be great if user can store zipped completed mods in one folder and others in second folder (or there can be more folders).
Or it is too much work for filesystem?