![]() I'm guessing Simpe either ignores this extra byte, or does something else with it - I can't find anything in the SimPE code specifically mentioning it. This is 1 byte for the string length (0x95 - 149 bytes) and then a 01 and then followed by the actual string (brandi.)Ī string in the SHPE ref chunk *should* be encoded with 1 byte for the length and then the actual string. This is 1 byte for the string length (0圆6 - 102 bytes) and then immediately followed by the actual string (Brandi.).įor a compressorised SHPE ref, in Hex view in SimPE: 95 01 62 72 61 6e 64 69. Normal compressed SHPE ref, in Hex view in SimPE: 66 42 72 61 6e 64 69. The reason is that there is an extra byte inserted after the length of the sgResource string but before the actual string. It is only on the SHPE chunks that are run through the Compressoriser that it borks. ![]() On *normal* Maxis/SimPE compressed SHPE chunks, the DDO works fine. It reads normal SHPE refs and other compressed ones fine, that I can see. I posted this over in the compressoriser thread but figured I'd duplicate it here.Įssentially, my DBPF code for the DDO has issues with SHPE refs in files that are re-compressed using this program. It wouldn't be too hard to implement, though. This is maximally flexible but seems pointlessly complicated for a rare and useless case, and makes pointlessly larger files. Allow opening and writing, always writing the duplicate entries uncompressed, unless the write_disposition makes that impossible, in which case fail.do what? Discard all but one? Compare them to make sure they're equal? Clients like dbpf-recompress would have to check for duplicates and. Probably a bad idea, since at least one exists. Refuse to even open files with duplicate index entries, because they're broken.How should the library handle this? It could: Of course it took four times as long as I expected (Hofstadter's law), and the decompiler will probably never see the light of day, but in any case the library is finished (modulo bugs), so I'm happy.Īs everyone else has figured out already, Jack Sparrow's hair has index entries sharing the same type/group/instance ID, and because compression status is indexed in the file by type/group/instance ID, it's impossible to have duplicate entries unless none of them are compressed. ![]() I thought that a SimAntics decompiler and recompiler might be an interesting project, and as a first step I needed a DBPF read/write library, so I looked around for one, and discovered that it was a most-wanted item, so I wrote it. One of my hobbies is writing decompilers for obscure virtual machines, like these. I'm a PhD student in the theory of programming languages. I've never posted on a Sims forum before. Um, I guess I should have introduced myself. See the changelog in the zip archive.Īnd welcome to the ranks of Peasants At Least As Tall As The Beefy Arm, whoever you are. ![]() And please use the library to build useful tools, otherwise it will all have been in vain.Įdit: New version 20070530. Please test dbpf-recompress on every package you can lay your hands on (after backing them up!). This is a very preliminary release and some things are completely untested. It shaves about 100 megabytes off the size of a base Sims 2 installation, and everything seems to still work. I also included a sample app / useful utility called dbpf-recompress which uses the library to recompress package files. The compression code is based on zlib's deflate code with lazy matching, and almost always compresses better than SimPE or the game itself (sometimes a lot better). It has full write support with incremental and in-place updates and compression. This is a DBPF (*.package) library written in C++ with a C interface, GPL licensed. I think this belongs in the Bowels of Trogdor, but I don't seem to have posting permission there.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |