zipped folder access

#1 I haven't tried this in ages... I'll toy around with it when I get home tonight and see what I can find out.

#2 Yeap. It works, but you need to do a couple of changes in engine.

First, you need to enable the support of virtual mount system.

Open Engine/source/core/volume.cpp (around line 890)
and uncomment the

static VirtualMountSystem   sgMountSystem;

and comment out the:

//static MountSystem   sgMountSystem;

Now, open Engine/source/platform/platformVolume.cpp (line 37)
and uncomment

return MountZips("game");

and comment out the:

//return true;

If you read comments around that code in engine, you may see that there are bug in engine, so this is why VirtualMountSystem is disabled by default.

Here is a "fix":

FileNodeRef ZipFileSystem::resolve(const Path& path)
{
//...skipped
   if(mZipNameIsDir)
   {
      // Remove the fake root from the name so things can be found
      // [Apr/28/2011 bank]: Added "NoCase" param
      if(name.find(mFakeRoot, 0, String::NoCase) == 0)
         name = name.substr(mFakeRoot.length());
      // [Jan/7/2011 bank]:
      // If the name doesn't contain our root, break off immediately as we are inside wrong zip.
      // Otherwise it will "find" the stuff from another zip, e.g.:
      // we requesting to exec("scripts/client/missionDownload.cs");
      // which we expect to be launched from scripts.zip in game folder.
      // But if we have "core.zip" right here, it will be parsed before the "scripts.zip" (simple asc order)
      // and without taking off fake root ("core") it will FIND few lines later file
      // "scripts/client/missionDownload.cs" as it's a correct path for the file inside the core.zip
      else
         return NULL;

      if (name.find("/") == 0)
         name = name.substr(1, name.length() - 1);
   }
//...skipped

#3 Ah, thanks Bank, I thought that the feature removal gremlins had been at work here too.

#4 What is the bug that happens if enabled, or is the bug fixed with the additional code?

#5 I will be glad to know if this is the only fix. If so... it should be included in 1.1 final!
@GG,
Is it on your list?

Thanks Bank!

#6 According to the comments it looks like scripts with the same name but in different zip files can be confused for one another. I'd dig more before deciding on using this - or put everything in one monolithic zip. That solution might have performance implications (or not) based on whether it's faster to open a few separate zip files or to handle one large file.

#7 With my fix (added else return NULL;) you can safely use many zip files and all should be working fine as expected.
Without this small addition Torque can mess with "same-name" scripts in different archives.

#8 Is this allowing the zip files to only be in a certain folder("game"). Implemented it but it wasn't showing the .zip files as folders to use the models from. I am not using the standard T3D directory structure, so wondering if that is the problem.

#9 can we use this to ease the client update?
I meant, if I download a zip file on the client, it will be loaded, and should overwrite the previous script run.
is it the case? or should I manage some coding.
This is on my todo list, but I never dig into it yet..
Thanks,

#10 Yes, this would be excellent for updates. You break up your data into folders which could change a lot to ease the download size, then just download a replacement ZIP.

Or if you want to be easy on the bandwidth you could also download individually compress files and add them to the ZIP with a replace option. Now you'd probably need to look at another ZIP library to handle the building of datafiles, but I bet it's worth the effort.

#11 For this my preference would be to have something working a bit different...

A system where the content of the zip folder is like if it would be in the main game folder.
Let's say I have pack1.zip, pack2.zip placed into the game main directory and both containing a folder named "art"...
The content of those "art" folders is treated as if they would be exactly in the "art" folder under the game main directory.
If both packs contain a "art/shapes/bigBeaver.dts" file the engine choose which one to load based on which zip file is the more recent...

I see such a system useful for updates, so if you wanna replace the bigBeaver.dts file, because you decide your 10 meters tall beaver shape is not big enough, you just put a new bigBeaver.dts with a 15 meters tall beaver in pack2.zip :-P

#12 This is exactly how Blizzard proceed with their mpq(or something like) file. It's a compressed, signed file and for each update, you just download the delta in the latest package and it will take that as the latest version of the file!

#13 @Giorgio
Huh... Look at it closely: that may have been the intention of the original code.

#14 sticky >.>

#15 Greetings!

Logged as THREED-1460. Thanks!

- Dave

#16 Another update to THREED-1460.

Issue: If you have archive with name like:
art/shapes/MyShapes.zip

and the engine will look for file inside archive, the request will be for:
art/shapes/myshapes/someshape.dts

And it will fail to load it as it will check MyShapes as mFakeRoot against myshapes folder, TAKING into account "case".

The fix:
Replace

if(name.find(mFakeRoot) == 0)

with

if(name.find(mFakeRoot, 0, String::NoCase) == 0)

My original post with changes updated.

#17 Fixed in 1.1 Final.

#18 I thought reading a ZIP was already enabled.
So we have to make a source change to enable it? Grrrrr.

#19 It's enabled for T3D 1.1 Final by default.
If you are using pre-final, you will need to apply fixes from this thread.

#20 is posible use a password for the zip file?