Merging mods to increase Performance!

<< < (12/76) > >>

J. M. Pescado:
The fact that you even NEED a tutorial for such a thing clearly indicates you are mentally deficient. Have you even LOOKED at it?

tizerist:
Tried it and it works lovely.
Are there any advantages to 'reject' rather than 'replace'?
And the 'compress' option: have you lot been using that?
Nice one.

Anach:
Quote from: tizerist on 2010 January 06, 05:31:41

Tried it and it works lovely.
Are there any advantages to 'reject' rather than 'replace'?
And the 'compress' option: have you lot been using that?
Nice one.


Make sure you get the experimental version from the first post in this thread.

The reject and replace options only show on import from .package. There is no such option on "Import as .dbc", as the default option seems to be "replace". However, I found that some mods (so far only exported sims3packs) will break if imported as .dbc (game cant read them) and I need to switch over to import as .package instead, but the only problem with using import as .package is that it will not generate the merged _key (0x0166038C) which I assume is important when merging large amounts of certain mod types that rely on these manifests.

I still have no idea what causes it, and unsure if anyone else has this issue, but the majority of sims3packs i extract to .package files aren't able to be read by the game until I import them to another package, even if it worked fine as a sims3pack.To test to see if the mod is broken, I usually try to open the freshly merged .packages in the blue lot fixer, as usually if the merged .package it wont open in that, the game can't open it either (very slow loading and process monitor goes berserk), which is when I need to resort to importing as .package rather than importing as .dbc.

Keep in mind that I'm still bluffing my way through this, testing various options to see what works and what doesn't, but I have limited knowledge of why things do what they do.

*edit* A little experimenting with my above stated issue. I decided to extract the files on a Win2k3 32bit PC and the game read those extract files fine without any further modification, but tried multiple times to do the same thing on my main PC (Win7 x64) and the game would not read the packages until I merged them into a new .package. Now to re-extract and re-merge them into the main package to see if there is any difference performance wise (in proc mon.)

*edit 2* While the newly extracted files worked fine, there was still one set (cellar set) which wouldnt import correctly using the import as .dbc function, but worked fine with import from .package with either replace or reject. Once they were initially imported into a test package, i was then able to import them to my main package using import as .dbc. So I dont know what the odd thing was about that particular object set.  Currently all is working fine.

AloeOwl:
Quote from: J. M. Pescado on 2010 January 06, 02:47:12

The fact that you even NEED a tutorial for such a thing clearly indicates you are mentally deficient. Have you even LOOKED at it?


Thank you Witch for your very informative thread!! (Sorry about not searching)

I tried this out in-game, everything seems to be working perfectly fine. However, as far as performance goes, I don't see any improvement; It actually seems as though the game is slower :P. I'll have to look into that.

cefwyn:
Quote from: AloeOwl on 2010 January 06, 08:38:32

One more thing: When I was importing my "sims" CC (which includes everything from clothes, hair, default replacements...) I got an error saying that "some resource names may not be displayed". Has anyone had this problem occur?


Yeah, I've had this issue with a few of HystericalParoxysm's hairs, but those are the only thing I've had a problem with so I just leave them as .package since there are only a few of them and I would rather not mess them. From what I can tell from the error message though, it's due to the fact that the packages are probably just slightly altered from each other and contain identical _KEY files. It may be safe to merge them anyways, but the difference in performance for the few files with that issue would be immeasurable.

EDIT: Since the experimental import to .dbc attempts to merge the _XML files (And fails every time I've tried it saying "manual merge of xml files required"), does that mean those files have been decided to be more then just necessary for the launcher?

Navigation

[0] Message Index

[#] Next page

[*] Previous page