Just had a look at all the homeless using super computer and it seems they were all the same woman (blonde) with different names. Very creepy... So i nuked them all.

Not really the place for questions about xml tuning. I'd suggest using one of the already available teen whoohoo mods, and then adjusting that yourself if you wish to experiment with specific settings (winmerge is handy for finding out differences between original files and custom). You can grab one from the link in my sig, and I also link to another one in the last post of that thread.

I have quite a large town of about 238 sims (leach house has cots, so lots of babies), with no vacant houses, I also had about 8 homeless families that had bee moving in as older sims died. However, today I noticed that another 36 single sims had suddenly filled my homeless list, and my performance dropped considerably. Are these new homeless created for any particular reason, such as no compatible love matches in town, or is this a bug, and is there any point in me killing off the homeless sims, or will they simply regenerate?

As there were quite a few single people in town, I'd been working on pairing them up manually anyway and hoping to limit my town to those already available. It Would be nice to have an option to set a population limit in the town, and not allow any random generated homeless sims until the population drops below that level.

Also, while on the topic of romance, is there a reason AM story mode keeps finding romance victims (quite frequently) for married sims? It seems everyone in town is quite the adulterer.

Uploaded the limo. I was surprised I couldnt find it anywhere else.

We learn something new every day. Worked for me!

Just drag the sims3pack onto the s3rc.exe, then extract the sims3pack as usual.

That would probably be the new Dr Pepper car. I got the same issue when I tried extracting and opening that file in either s3pe or postal. However, even the launcher wouldnt open it, which is a little odd.  I'd say that is a question for the s3pe forum.


When it comes to sims3pack items, they are usually just ugly thumbnails that I like to remove to allow the game to generate replacements, or maybe a buy mode category change, as many people seem to put everything under plants or misc decor. Currently my launcher only has official paid content in it, which keeps it nice an clean and easy to navigate.

2. Yes it gets rid of conflicts automatically. The only ones it doesnt (so far) are the manifest _xml files as explained in the howto.

1. This was answered in the above post. However, the reason you see mention of sims3pack files in the later posts of this thread is because I have also been extracting and merging my sims3pack manually, as doing so keeps me from having to use the horrible launcher and allows me to edit them in was I was previously unable to do when installed via the launcher.

I must admit that I haven't tried compressorizing them before extracting. I shall give that a try next time I extract some sims3packs.

I've finally narrowed down my issue to my original set of objects I used for the first merge. It was solely down to the cellar set from ATS3, which is what I used for the first experimental merge. I had thought I'd sorted out the issues I had with that and marked it safe, but obviously I hadn't. I removed all my CC from the launcher and merged it back into my custom dbc package one by one until I was left with that set. As soon as I did anything with that set it dropped from 50fps (big house with lots of sims) to 25fps. However, when installed via the launcher, the fps were back at 50. So what I did next was to create a fresh .dbc using the launcher to only install the cellar set, so I was left with a merged cellar set dbc that I could rename to package. I installed this to the mods directory and all was fine. Now I also tried merging the freshly created dcbackup folder package files to a fresh dbc with s3pe, as I thought something might be happening to the set during my manual extraction. However, i was left with the same broken set when trying to merge those.

I now have finally merged the cellar set back into my main custom package file (dbc) with s3pe and all is working fine. This leads me to believe that something is wrong with the cellar set, but the launcher seems to fix it when merging where as s3pe doesnt. Which makes me wonder if I could possibly gain anything from doing this with my other sims3pack to package conversions, but for now I'm just going to go play the game for a while, i've spent days playing with merging, in and out of the game.

In that case I'll keep plodding away to see if I can track my issue precisely, which is difficult when nothing in this game is exactly precise.

A further note to everyone else experimenting with this. I haven't had much success in extracting .sims3packs into .package then importing them to the merged archive. While the process itself works ok, I experience quite nasty slowdowns, which put me back to where I was at before I merged everything, at about 50% loss of FPS. I don't know whether it's the conversion from sims3pack to package, or if the objects themselves are buggy (and somehow in sims3pack format aren't buggy), but no matter the item (tried about 50 different items), the outcome is always the same. If I remove those converted .package files and reinstall them as sims3pack with the launcher, I regain my FPS. I've tried multiple extraction methods and used two different computers with two different programs (s3pack and delphy's extractor), and I've tried every variation of merging these items.

I'd be interested to hear of any experiences of other people who have converted sims3pack to package and merged them into a single .package (dbc) archive. I know it must be possible, as a lot of these .packages originate from sims3pack, so it might simply be down to the sets i'm using, however I'm curious as to why when those same packs are installed with the launcher the FPS increases.

My mods are released as is, the only tweaks I'll be doing to them are bug fixes or if I want to change something to suit my tastes. However, you can tweak my files yourself with s3pe, or go find yourself the pregnancy morphs on MTS, then head over here to get yourself a custom pregnancy mod compatible with AM.

Something you could try is importing your packages using the standard import from .package function rather than the create dbc, try either replace or reject duplicates, group only similar mods together, and experiment a little to see if you get better results. You can't really hurt anything unless you save your game with half your content misisng or if you delete your original packages.

Check back through the thread or the instructions on the first post where I mention _xml. If you have other types of conflicting _xml, then it's likely you have an actual conflict. Yes the .dbc import will merge the manifest _key files for you.

Most of it should work fine without WA, as long as you have the latest patch.

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.

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.

My Wife was also having this issue, but only with a particular save game, so changing games, rolling back to an older save, or starting a new game seems to fix it. This seems to be the case whenever neighbourhoods go bad. Over my time with sims 3 I've had to start new games and import all my families to the new hood about 3 times to fix corrupt neighbourhood issues, but most those times i've worked out it was due to a particular mod, sim or item in the game world, not AM. In my Wife's case, which sounds identical to yours, we still don't know why it was happening.

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

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.

You all have some very good points. I certainly suggest using a probation folder for testing individual packages before merging anything, and as I mentioned on the previous page of this thread, I like to test every single mod I install, simply to maintain a trouble free game. There is a lot of broken content out there, and it will do nasty things to the game if left in. My wife is currently going through her content 1 by 1, just as I did over a few days, as we both had some nasty game issues to track down. I removed a lot more than I would have expected to. Once each mod has been tested, It's certainly worth merging into fewer packages.

The only files I manually removed from any of my merged mods were _xml (in the tag column) with resource keys of 0x00000000000000 (instance column). These only seemed to show in a few mods, and were my only conflicts that required manually merge (as alerted by s3pe). I haven't seen any negative effect of removing these, and I didn't find them in the official .dbcs, so I assumed they were created by the modding tools as some form of identification for those particular tools, but I really don't know at this stage.

None as far as my own testing has shown. I initially did .dbc, then renamed (later remerged) as .package, and saw no difference performance wise. As JM stated, they appear to be identical files, except for whatever the official launcher does to allow the game to recognise the .dbc when in the docs folder.

However, it certainly seems that the fewer .package files in your mods folder, the better your game runs. I originally went from over 700 total, to 20 merged and 45 tweaks which I left as single files for ease of frequent modification and updates. I later cut that down to 5 merged and 39 tweaks and noticed that my larger household was running a few frames quicker average. I'm hoping to cut that down further to  6 main merged .package and a couple essential separate files (such as awesome and other tweaks that arent merge friendly) to see if it improves further. I would imagine that after a certain point there would be very little noticeable difference in performance.

*edit* as expected, it doesnt seem ill be gaining anymore performance by decreasing the amount of .packages further. I tried reducing my 45 total to 12 total, and didn't see a difference. Most of those were xml, ini, dll , ui type mods, so I didn't really expect much of a change, as they are fairly small and light compared to objects, clothing, or hair type mods. So as a recommendation, i'd suggest everyone leave those types of mods outside of the merged mods, due to it not making any difference performance wise, that they usually updated a lot more frequently than other types of mods and not all types will play nicely in a single file.

The 0x000-lots-of-zeros... xml files were only included with hair as far as I found. I also didn't find them in any official .dbc files, so I assumed they were probably added by DABOOBs or TSR Workshop and weren't actualy needed. The unknown files could very well be something to do with it. However, the merged content works perfectly fine in the mods directory, as either .dbc or .package, with no crashes or other issues without those zero xmls.

A scary thought, as i'm sure it will break the launcher horribly, but worth an experiment. I like to keep mine as clean as possible, that's why i'm excited about merging possibilities, as I can keep my CC separate to my SC, and not have to scroll through that horrible launcher to find stuff, since I generally never uninstall store stuff.

*edit* Doesn't work either. Tried importing 200Mb of various object mods to my existing official .dbc. Nothing showed in-game, similar to when I tried a freshly created .dbc in my docs.

At the moment I certainly don't see myself as experienced enough in s3 modding to give any more advice than I already have, in that people take a look themselves. Even those mods which are often broken or missing stuff, i'd find it very difficult to make myself. Like you, a lot of it is simply guesses and my own testing for obvious stuff , So other than my own personal quality limits, I wouldn't feel comfortable in stating any thing else. I'd kinda feel akin to some noob coming in and telling Pescado how to make core mods.

I prefer to simply advise people to be very fussy when it comes to installing mods, as not every mod creator has the same level of expertise or quality control and quite a lot of mods will break your game in one way or another.

However, I will say that Hair mods seem to be one of the most frequently broken mods I come across, and one to watch out for. I now have very few CC hair in my game simply because it was causing game issues or simply had ugly visual issues. I've set my own limit of acceptable quality on that, and even while I might use one or two hairs from a one particular modder, it doesnt mean every hair from them will be fine, and more often than not, its the hair I actually want to use, unfortunately.

The trouble with threads that list troublesome mods, is that everyone has a different level of acceptable quality, often modders will update and fix mods, and quite often they end up so full of nonsense that they end up being ignored anyway. As much of a pain as it is, there really is no way to tell without testing every single mod prior to adding it permanently to your game.

Updated the main post to simplify the process with the latest information.