TL;DR; I’m going to have to recompile every one of my apps and I will no longer be supporting SimPe versions later than 75.69
Sims2Tools and Newer Versions of SimPe
Various sub-functions of my applications need to locate game files. To do this they need to know where the base, EP and SP files are located on disk. To find these, the applications use the information held within the simpe.xreg file (in the Data sub-folder) of your (hopefully) correctly configured SimPe install.
Unfortunately, versions of SimPe later than 75.69 do not have this file, or have moved it elsewhere.
In addition, versions of SimPe later than 75.69 have also relocated/renamed component .dll files and this means that I can no longer create my SimPe Primitive Wizards for these versions without a lot of effort on my part. (They are available for 77.69.7/9, but 77.69.11 has changed again and I have better things to do with my time.)
As I do not use any of the versions that are causing me problems, I have reluctantly decided to stop supporting them.
Fortunately, you can have multiple versions of SimPe installed, so you can pick-and-choose which version you use for the task at hand.
Currently, only the Repository Wizard and the SceneGraph Checker need to locate game files, although Outfit Organiser and Object Relocator will probably need to in the medium term.
Users of versions of SimPe later than 75.69 will therefore need to do ONE of the following
EITHER 1) Create a Data sub-folder under the newer SimPe install and copy the simpe.xreg file from the Data sub-folder of a previous version into it. Depending on how you upgrade SimPe, you may need to do this for every new release.
OR 2) Configure my applications to read the simpe.xreg file from a previous version of SimPe, you need only do this once as the applications share this information.
OR 3) Manually edit the UtilsLibrary.dll.config for every application (as they do not share this information) and enter the correct paths under the userSettings element.
On a positive note, it has highlighted a bug in the UtilsLibrary that was trying to access the DbpfLibrary’s .config file, the upshot of which is that every one of my apps will need to be re-compiled and updated to support option 3 above.
Sims2Tools and Compressed Resources
A .package file contains one or more resources (BHAV, OBJD, TXMT, CRES, TTAB, etc).
Individual resources can be compressed. The act of compressing a resource causes two effects; 1) the resource is compressed, and 2) an entry is created in the CLST resource. The CLST lists all compressed resources in the .package file along with their decompressed size.
Compressing a .package file is the same as compressing each uncompressed resource it contains (except for the CLST) individually.
Contrary to popular belief, a (correctly) compressed .package file will never contain only compressed resources, as the CLST will always be uncompressed.
Decompressing a resource is the reverse process, that is, the resource is decompressed and the resource’s entry in the CLST is removed.
Decompressing a .package file is the same as decompressing each compressed resource it contains individually.
Other than the non-trivial issue of decompressing a compressed resource, there are two problems faced by code trying to read resources from a .package file.
1) The resource is compressed but has no entry in the CLST - this results in using compressed data as if it was uncompressed data.
2) The resource has an entry in the CLST but is not actually compressed - this results in trying to decompress data that is not compressed.
Unfortunately it is very easy to create problem; 1) open the .package file with SimPe, 2)delete the CLST resource and. 3) save the .package file!
There also seems to be at least one 3rd party utility that writes decompressed resources back into a .package file without removing the associated CLST entry.
My DbpfLibrary has been able to handle the second problem for some time.
Weirdly, the incidence of the first problem has increased dramatically in the past six months - there’s probably a video/tutorial out there that suggests it, possibly because the CLST resource is never compressed.
And as my apps then get blamed for “not working” due to other’s errors, I’ve had to find a solution.
The upshot of all of this is every one of my apps will need to be re-compiled and updated to handle both of the incorrect CLST problems.
Huge thanks to bowedy, sgthebee and brattyful for helping me track the SimPe issue down.