Difference between revisions of "Talk:DatabasePackedFile"

Latest revision as of 16:08, 7 October 2010

[Thank you, FordGT90Concept; I didn`t know how, yet. --GeneralOperationsDirector 2010-Oct-07]

It's a Sims 2 wiki yes, but it also has Simcity 4 modding information on it thats linked from Simtropolis, so try not to remove all the Sim City 4 stuff. :) Delphy 17:10, 1 August 2006 (EDT)

I didn't, I just changed the focus to Sims2. Jaxad0127 17:21, 1 August 2006 (EDT)

I could get it until the File part. Then there's a header that may be there or may not be there, with no hint as to a method to know! Albmont 17:24, 28 December 2006 (EST)

How does it look now? I added links to the DIR resource and the DBPF Compression page. Delphy 12:08, 29 December 2006 (EST)

I still don't get it. I could read the header, but then I got struck at the index. I tried to "seek" to the position indicated by "Location of first index entry", and read the index table. Some of the entries seemed ok (instante ID = 1, second instance ID = 0, size = 133), but some looked weird (type ID = 206966585, etc). Then I continued reading the next entries, with similar numbers (FWIW: I am writing the read_package routine in the R programming language). I could continue, but those weird numbers might mean that I am missing something. Albmont 09:57, 30 December 2006 (EST)

Remember to check the indexMajor and indexMinor version and to read the Instance2 if applicable (for 7.1). I have code in PHP I can show you if you are still stuck. Delphy 14:33, 30 December 2006 (EST)

I did read the "second instance" in version 7.2. I don't know PHP, but I may get something. Is there a wiki for source codes related to The Sims 2 and Sin :-) City 4 ? Albmont 15:55, 30 December 2006 (EST)

Yes, this one. :D I actually found the same problem as you lately - there is very little actual code out there for reading package files, hence why I redid the DBPF and DBPF compression pages. I'll add a PHP DBPF class to the main DBPF page. Delphy 04:02, 31 December 2006 (EST)

I saw the code, I guess I could understand it (even though I know nothing of PHP and I could not run it), but I think there's something missing there. The code reads some of the files, but not all of them. I am specially interested in the "Property Set", the one with $value['typeID'] == 'EBCF3E27', because this is where Pets Bodyshop introduced a bug, and I would like to list all the packages that were infected with this Pets virus (there is no outfit in the Property Set). Albmont 14:05, 31 December 2006 (EST)

No it doesn't read everything, becuase it's basic code on how to get the .package/DBPF open. What you then do with your individual files is totally up to you, and you should follow the format for the specific filetype in question. Delphy 18:41, 31 December 2006 (EST)

[edit] Compressed or Uncompressed

The text says " To check if a file is compressed you first need to read the DIR resource, if it exists", but there's no hint to how we can know if the file is compressed or not, neither here nor in the DIR entry. Albmont 14:18, 31 December 2006 (EST)

Basic programming. The DIR resource has a list of compressed files based on the various TGI stuff (Type, Group, Instance ID, Instance ID 2). Each file in the index *also* has TGI info. So, what you do is basically check if a file from the index exists in the DIR array then it must be compressed. What I did with my PHP code was to basically add a field to the index array called compressed, then if a file exists in the DIR resource it tags the index entry as being for a compressed file, then when I come across a file later on, I just check in my index array and if compressed == true, then I know it contains compressed data. Fairly simple, really. Delphy 18:41, 31 December 2006 (EST)

That's a kind of very skewed logic, isn't it? So the whole purpose of this DIR resource is just to repeat what is in the index, and if the DIR is exactly identical to the index, it means the file is compressed, otherwise it means the file isn't? They use 20 or 24 bytes when one bit would suffice? That's not fairly simple, that's exotically complex! Albmont 15:14, 1 January 2007 (EST)

Yup! Completely and totally weird. That's Maxis for you. Personally I would have just added a single byte to the index as you would. You'll find a lot of things in these package files don't really "make sense" from a normal point of view, but I guess we have to work around them to make the programs we make... Delphy 16:12, 1 January 2007 (EST)

Another weird thing though is that not every resource in a DBPF file is always compressed so it's not as easy to flag the entire file as being compressed/uncompressed. What I did with my programs is once I've pulled the sizes from the index I check the first few bytes of the actual resource. Within the first 9 bytes of a compressed resource it gives the compressed size and uncompressed size along with some other info, (which I don't see on the DBPF compression page anymore BTW, was that removed/lost? I'll re-add what info I have if it is.) But anyhow, if the "Compressed Size" that I get from those first 9 bytes matches the size from the index then I know that the resource needs decompressed. I don't even really pay any attention to the DIR resource, though maybe I should. *Shrug* --Jfade 23:07, 2 January 2007 (EST)

Jfade, I couldn't find a good description of what those beginning 9 bytes where - specifically the second block of 5. If you could fill that in, that'd be great.

I was under the impression that every compressed file thats in a DBPF is listed as the DIR resource, which is a seperate list from the actual Index itself - so checking just the DIR and matching that against the Index should be (and has been for me) enough to indicate if a resource chunk is compressed or not, but your way of also matching the first 9 just provides extra error checking. Delphy 03:35, 3 January 2007 (EST)

Added the info about the header again. And I see, when you first said file I assumed you meant the entire DBPF, which is what threw me off. I've always referred to the individual files within the DBPF as resources, though I guess both are correct. It just threw me to see it referred to as a file at first though, heh. But the DIR resource or the header of the actual compressed file, both are valid ways of checking. --Jfade 14:16, 3 January 2007 (EST)

Excellent thanks for adding that. :) Delphy 15:48, 3 January 2007 (EST)