Is it just my CPU that sucks? (1.7 amd, 512 mb memory, radeon 9700)
Or is there another problem aswell?
The file I’m trying to load is about 14 mb
Edit:
I tried loading it without the -z option, that works. But still… why cant it read from the zipped version? Also… how to read from encrypted files in this way?
You should be able to compress files within a Multifile and read them without trouble, although certain image file formats (like tiff and rgb), which require being able to seek within the file stream in order to decode them, don’t like being compressed. I don’t think you should get an “out of memory” error when you try to read them, though; I’d expect some different error message.
Maybe there’s a problem with zlib on your machine? I think with Panda3D 1.1 we’re using Panda-specific versions now (e.g. panda_zlib.dll), so a conflict with another version is unlikely, but maybe there’s still something wrong in there? There probably isn’t, though, especially if you are able to run multify without difficulty. Can you extract out the files successfully with multify -x?
Try compressing just some of the files in your Multifile. See if you can narrow down which files are giving the trouble. You can do this with the -Z option to multify to exclude files by extension, or you can compress individual files by adding all the non-compressed files first (with -c and without -z), and then running multify again to add just the files you want to compress (with -u and with -z).
To read encrypted files, add a fourth parameter to the mount() call, which is your encryption password, like this:
Yes, I can extract them without trouble. Now I tried excluding the .tif files, but that didnt help. I also noticed that setting a password without using the zip function gives me the same error, so I dont think it has anything to do with zlib… Could there be some sort of memory leak in the Virtual File System?
Hmm, we do still use the VFS for Toontown, and it works fine there even on low-memory machines, with some compressed files in the Metafile. But there might be some recently-introduced bug that’s not yet part of the codebase that ships with the Toontown client.
What version of Panda are you running with? Can you successfully compress/encrypt any files in the Metafile at all, or do you get this problem even with the smallest bam file?
ahh there we are, the sound folder bugs it. This folder contains two .wav files and one .mp3 file.
Also, the mf file (with sounds without compression) breaks after it was compiled with inno setup (zip,bzip and lzma). Regular compression using winrar didnt give any problems though…
I can live with sounds outside my mf archive though, thanks for your help
If you need to to look further to find the bug, I will.
Edit: The wav files break it, both of them, the mp3 file works just fine
Ah, I see the problem. Panda’s FMod layer wants to allocate a memory buffer to hold the entire sound file. To do this, it first tries to seek to the end of the file to figure out its length. That’s an understandable mistake; that’s the only way to get the length of a file in the normal C++ interface. But it doesn’t work when the file is stored compressed in a Multifile (if you try this, the returned length will be -1, and it causes an out-of-memory error if you try to allocate -1 bytes).
Panda’s VFS interface provides a different way to get the length of a file that doesn’t require seeking. The programmer that wrote the FMod layer probably didn’t know about this interface, and since the CMU team doesn’t much use VFS, and Disney doesn’t use the FMod layer, the bug went undetected until now.
Should be a simple fix. I’ll put it in.
Err, I can’t quite figure out what you’re referring to here. How do you mean it “breaks”?
Well, I’m trying to find out how far I can push a distribution version. So I packed up the files in an installer using inno setup. But when my assets.mf is already zipped or using a password the installed version “exits in an unusual way”, atleast thats the error…
It might just be the way inno setup handles the files though, since it works just fine when its packed with winrar.
Is it possible inno setup is corrupting the multifile, for instance by treating is as a text file and converting CR characters to CR-LF? You should verify that the installed multifile is exactly the same, byte-for-byte, as the original.
