Merging mods to increase Performance!
Anach:
Quote from: AloeOwl on 2010 January 05, 00:02:58
I've been reading through this post since the beginning and thought of giving this a try. I don't have THAT many CC files (around 200), but if it can boost performance why not?
I just tried this out but it didn't work out. One thing I'm confused about is that you said that the 0x00000000000000 xml files can be deleted, but more than three quarters of the files I imported are made of 0x00000000000000 xml files.
I tried this out with some build mode objects and my buy mode objects. And got two files (packages) and put them with my other mods in the mods/packages folder (not in sub-folders). Supposedly they should work but they aren't. I went back into the game and found nothing. Am I doing something wrong? Should I have deleted all those tons of 0x00000000000000 xml files?
Also when I click to import the packages I get a window listing all the files inside (The location of the packages) and it shows me things I can check like deleting duplicates or not, to compress them, and other things that are grayed out (I can't check those). Any suggestions on why this didn't work?
EDIT: When you say "0x00000000000000 xml files" are you referring to the group they belong to or the type? Examples of other groups: 0x00000000000001 or 0x00000000000002
Get the latest s3pe, read the instructions on page 1, post 1. Keep in mind that this is all new, so even though I imported about 700 different types of mods, there are bound to be some troublesome mods or mod types that wont merge with other mod types. Also you can try import and choose "reject duplicates" as an alternative to import as .dbc. This process might require a bit of trial and error with certain files.
Inge:
I need to point out the s3pe linked in this thread is *not* the latest public release you will find at MTS. It is a special test release for the purposes of this experiment, so you need to get this one.
Anach:
Quote from: Inge on 2010 January 05, 08:38:54
I need to point out the s3pe linked in this thread is *not* the latest public release you will find at MTS. It is a special test release for the purposes of this experiment, so you need to get this one.
Thanks for the info. I updated the links on the first post to the one you provided.
I've also been doing some more testing by removing all custom content I had installed in sims3pack format via the launcher, extracting it and then merging it with the new import .dbc function. All worked very well. I didnt have any issues, except for the extraction using Delphy's tool. It seems that straight packages extracted from sims3pack dont like to work until they are merged into a fresh package, which I found very odd. The single packages on their own were not loading (20k+ in process moonitor) and the game was taking forever to load. As soon as I merged them to a fresh .package using the new import function they all worked without an issue, which makes me wonder if doing the same with other problematic .package files might fix the issue too.
Furthermore, I found that some packages will like to be merged in a specific order, which is entirely likely to be due to the way conflict resolution works. I was trying with a particular set of furniture (Cellar set) and found that I had to separate them into 3 files (paintings, furniture and clutter), then use the import feature and reject duplicates instead of the import .dbc function. So it will take a little toying with to get working right for each person.
As for the _xml manifest files, they seem to only be in certain files like clothing and hair, and I have deleted every single one without issue. Most likely it doesn't matter either way, and one could probably leave them all in a conflicted state and it wouldnt matter to the game. Though the _xml manifest files and icon files could also be excluded from the merge and save hassle of conflict resolution for those who might be inclined to panic :)
Compression is something I'm wondering about. I notice that while "Import from package" is all or nothing in terms of compression, the "import as .dbc" seems to be selective. Looking at the official .dbc, certain files seem to be almost always compressed, while others almost always not. Prior to the .dbc feature, I was compressing everything and didn't notice an issue?
PS. Wife forced me to correct spelling :P
Inge:
I guess with import dbc he left the compression as he found it, whereas the user gets the choice (but *not* "leave as found" lol) with the normal import.
That's the trouble as things get bolted onto tools, they get out of step and inconsistent. What would be the preferred action here?
Anach:
Quote from: Inge on 2010 January 05, 16:15:00
I guess with import dbc he left the compression as he found it, whereas the user gets the choice (but *not* "leave as found" lol) with the normal import.
That's the trouble as things get bolted onto tools, they get out of step and inconsistent. What would be the preferred action here?
I was actually thinking it would be nice to have a "leave is found" option when I was first playing around with the merging before the .dbc option, so that works well for me :)
As far as creating a trouble free merged file, with less worry for the end user, I would prefer to see only needed files merged. For single .package files it makes sense to leave in unofficial file types in case the user has need of them later when importing back into various tools, but if they are creating a merged .package for the purpose outlined in this thread, then there is really no need for files not used by the game, as the merged files can't be used by the tools that use those specific files. I'd imagine they could be filtered out of the merge or ignored when it comes to alerting about conflicts, so the user doesn't have to panic over 50 different _xml manifest files with the same key.
Navigation
[0] Message Index
[#] Next page
[*] Previous page