Unfortunately, at least in my setup, the sculptures and inventions always exist but just wouldn't be created without their versions in the XML changed to "BaseGame". For example, here's a failed sculpture from the InventSculpt_EP2 experiment next to the fully functional statues from buydebug:

Even in a test without touching the ProductRegistrationRequired values, the inventions and sculptures were still available in buydebug despite not being able to be created normally. Very odd.

That seems to be the right train of thought. The drop-in-a-file solution you desire would probably be a "correct" Ultimate Career Bundle installation. Whatever the difference is between that and our installation is the only thing separating the "registered" and "unregistered" expansion packs.

From a quick glance at the code, TS3 always assumes that the base game, WA, and HELS are registered. However, when it checks for Ambitions registration, it performs some sort of check using values from the two sculptures and two inventions provided by the Ultimate Career Bundle. I'm not sure if registering and downloading it from the EA store generates a personalized version for your game/CD-Key, or if it's just something that gets removed or altered in the usual methods we install Arr'd Store content (would love to hear the results of people who used a method other than decrapified Sims3Pack with and without Rothchild's mod). Either way, for legitimately registered games, the act of installing the Ultimate Career Bundle that EA provides you results in the confirmation of your registration in-game.

Due to that roundabout way of checking if the expansion pack is registered, it is doubtful that they perform any modifications to tag the game files themselves.

Normally from an elegance standpoint I would agree. That's technically what the core mod I posted should be. However, the Inventing/Sculpting items were further broken (again: only confirmed with the decrapified Sims3Pack installation) such that even having Ambitions "registered" wasn't enough, so Rothchild's XML solution which also addresses that issue is superior in every way.

In this case, the parts that are edited by this mod were already in the game data as of the 1.12/2.7/3.3/4.0 patch; not added by the Ultimate Career Bundle. If EA continues to use this method, the only time they could add more restricted content is with the release of a new patch. While it does concern me that this seems like a test swipe at the rampant store content sharing, I don't foresee them releasing restricted items rapidly enough that the mod catching up would become an issue.

The new mod works perfectly on my setup. Successfully created all four restricted objects. Confirming those is much simpler than the rest, so I haven't tested the new jobs, opportunities etc. at all. However,
they don't have anything suspicious about them besides the registration properties, so I think it's safe to say that everything currently unlocked by registering Ambitions can instead be unlocked with this mod.

Sorry about that, I tend to over-edit when following up on my own posts.

Anyway, after further testing, this is behaving very counter-intuitively. I can sculpt and invent all the normally EP2 version objects, but I cannot sculpt or invent the objects provided by the Ultimate Career Bundle unless they are set to BaseGame version. I am running a fully updated game with all expansion and stuff packs. The store content was installed via decrapified Sims3Packs and the Launcher. My tests were as follows:

I set up a mod that made it so all other objects that could be invented/sculpted had a minimum skill level of 10 required. In a situation where nothing can be sculpted, a FailureObject (red cube) is created. In a situation where nothing can be invented, the Sim will simply "Dabble" or "Invent" for several sim-hours with no result.

With only the ProductRegistrationRequired properties removed (defaults to "Undefined" in the parent structure):
All sculpting until level 10 results in FailureObjects.
All inventing until level 10 yields no result.

With the ProductRegistrationRequired and the SKU/EPVersion properties removed (defaults to "BaseGame" in the sculpting parent structure, and "EP2" in the inventing parent structure):
All scultping until level 10 yields The Guardian Griffon or Octavian.
All inventing until level 10 yields no result.

With the ProductRegistrationRequired removed and the SKU/EPVersion properties set to "BaseGame":
All sculpting until level 10 yields The Guardian Griffon or Octavian.
All inventing until level 10 yields Claw Dipper or Air Bender.

To put it simply, the only way to get the objects to work correctly in my setup is to set their version to "BaseGame" and remove the registration properties. Even "EP2" does not work. Despite this, all other objects can be sculpted and invented just fine regardless of the version they are set to. These results lead me to suspect that there may something wrong with my installation, so I would be very interested in seeing the results of those with different setups than mine. The following mods are all set so that only these specific objects can be crafted before maxing out the skill. The only differences among them are what the SKU/EPVersion properties are set to.

Been able to get around to testing:

I've tested by sculpting and inventing non stop with static moods. Neither with this nor the core mod was I able to sculpt an Octopus or Gryphon, and I wasn't able to invent a Robot Widget (different from Toy Robot, Claw something-or-other) or Fish Tank Widget (Presumably Air Bender). Due to the random nature of sculpting and inventing, I can't deny that I've just been very unlucky.

All the ones which had ProductRegistrationRequired=EP2 also had another suspicious entry, however: for the sculptures and for the inventions. Unsure if having the decrapified Sims3Pack would count for the version, I removed those values and tested again, eventually sculpting a Gryphon.

Only been testing for about an hour so the random factor is very high, but removing those properties didn't seem to hurt anything, and I can confirm that those objects can be invented/sculpted with only the XML edits. I cannot, however, confirm that EA ever correctly restricted this content in the first place, once again due to the random nature of it all.

EDIT: After some modifying to ensure that only Octopuses and Gryphons could be sculpted, attempting to sculpt without the above change resulted in "FailureObject"; big red cubes. Removing the "Store" version requirement caused Octopuses and Gryphons to be sculpted, as expected. This may be a quirk with my particular installation. I have yet to witness the invention the Robot (Claw) or Fish Tank (Air) widgets in any combination of tweaks.

Another interesting set of entries is in JobsAndTasks (0xBAAB3D95EEA15F2E). There are three Interior Designer jobs (aptly named RegistrationIncentive(0, 1, and 2)) that include the property:
Besides those in use, it appears that there are a few other files with default "Undefined" registration-related properties that currently have no entries overriding them. Somehow I doubt that they don't intend to expand on this 'feature' in the future.

EDIT: Seems like it would be simple to bypass this in any core mod; everything that parses these values checks Sims3.SimIFace.GameUtils.IsProductRegistered(ProductVersion). Just need it to always return true.

EDIT2: I'm not in a position to be able to test it right away, but just threw together a mod which hopefully does what I just said. Most core mods do not modify SimIFace (the version of Awesomemod that I currently have does not), so it should be compatible with them. It is probably not necessary at all, since XML editing appears to unrestrict the content just fine. Still, it would be good news to me if this works without the XML tweaks; one can never be sure what else EA might decide to lock out from most of their user base.

June 9th EDIT: We've discovered everything we need to know about registration, and Rothchild's XML mod addresses all of it. The core solution no longer provides practical or experimental value. Attachment Removed.

WA:
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.7.7.006001_from_2.6.11.005001.exe
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.7.7.006002_from_2.6.11.005002.exe
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.7.7.006003_from_2.6.11.005003.exe
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.7.7.006005_from_2.6.11.005005.exe
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.7.7.006017_from_2.6.11.005017.exe

HELS:
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_3.3.11.006001_from_3.2.8.005001.exe
http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_3.3.11.006017_from_3.2.8.005017.exe

When I experienced the CAS crash, the game was limited to 30 frames per second. Though if I consider all hardware possibilities: I don't use a pagefile and I had quite a few other programs running at the time. I only have 4GB of memory and run the game at maximum settings, so running out of memory may have been the cause in my case.

Subfolders work fine for me, and I have only edited the Resource.cfg in the base game folder. The one in Mods/Files/ was left untouched.

You'll have a line like this in your Resource.cfg:
Below it, simply add more lines for however deep you want it to look for subfolders, as follows:
Appending the above two lines into your Resource.cfg will have it look up to two folders deep for any packages. It should be self explanatory to further expand it to any depth you wish.

As explained in this very thread: All Sims do is stand in front of/sit on the terlet without changing their clothing status; it looks far better with the mosiac and some imagination than without, and it is therefore not removed. I could be wrong, but I don't recall AM ever removing the "censor" from Sims in that state. Other no-censor mods that change the filter itself would apply to everywhere the mosiac is used, but AwesomeMod alters the code to never apply the filter in the first place.

http://akamai.cdn.ea.com/eadownloads/u/f/sims/sims3/patches/Sims3_2.2.8.002002_from_2.0.86.002002.exe

EDIT: Regarding the mosiac: If the problem is that the "nudity censor" on the toilet still appears, then there is no problem at all.
If the nudity censor still appears in the shower and bath tub, however, then there is a problem. Update your game to 2.2.8, make sure that the appropriate options are enabled in the config, and see if it still occurs.

Enable AwesomeStory. It's superior anyway.

EDIT: It appears the post I replied to was merged into a completely unrelated problem. Just clarifying that this is a reply to Scatterlung's post above this, not the OP.

What convenient timing. This just happened to me a few minutes ago and I didn't think anything of it. It isn't particularly a problem for me (it has only occurred once, after all), but I would like to mention that it's not only the OP with that issue.

As far as what is behind it: All I can say is that when I encountered the crash I did have some custom clothing, although the crashes aren't consistent enough to suggest that any specific items could be causing them.

By your logic:
1. If something does not work for one subject that works for most other similar subjects, said subject is flawed.
2. AwesomeMod works for most people.
3. AwesomeMod does not work for you.
4. You are flawed.

Almost all of the problems I've encountered so far seem to have been solved as of the latest beta. CAS relations works, and the Tourist Orgies have ceased to occur. I've been testing in longer-term games due to these fixes, and have yet to experience any explosions.


I do, however, find it comforting when posting to periodically think "I know you can read my mind, Pescado."

Just in case.

Following up on this - it would appear that this might be an AwesomeStory issue after all, and is possibly related to the issue from the person with the Chinese boss.

When it first happens (at a random point during the game), the Tourist household contains very few Sims. All Tourists that end their roles end up joining this household, however, causing it to fill up to 20+ in a manner of seconds.

Just tested now, I can confirm that putting in the latest AwesomeMod with an extremely irresistible pollinated Sim results in interactionfail where none once was.

I have noticed this happening quite a few times in my tests, as well. The target Sim will occasionally become unclickable (for interactions) if:
1. The two Sims are standing.
2. The conversation is in the "extremely irresistible" tone.
It hasn't always happened every time these conditions are met, but once it starts happening it seems to always happen. If the conversation tone is changed from "extremely irresistible", or if the conversation continues while sitting or lying down, everything works again.

On an unrelated note: Am I the only one getting a "Tourist" household appearing and quickly filling up with 20-30 (foreign) Sims, causing extreme routefail lag at the door every night? This happens whether Overstuffed Households is enabled or disabled, but I haven't had a chance to test without AM. The tourists that live there drop the ", Tourist" suffix from their name. My games seem to enjoy choosing houses with one small front door and one single-bed for the Tourist household, causing much hilarity and much lag. I can't predict when the household gets created, and have been unable to reproduce it when I'm intentionally trying to, but once it does the tourists start moving in at a ridiculous rate.

Obviously, this is with WA installed. The latest time I've noticed both of these issues was with the 11/25 1:18 PM (time stamp in the zip) version, and I shall continue testing with the new 11/25 3:26 PM version.

That is intended if the Sim that yours attempted to talk to was TL;DR.

I experienced this (although it was an NPC Sim) and thought nothing of it at the time, but figured I'd "second" this post since I'm not the only one. This also happened yesterday for me, and I only noticed it twice over several hours of testing.

Have you had a chance to test Family Relations in Create-A-Sim and/or impregnation? Although I'm testing with WA installed, confirmation that they work fine in at least one other setup would be excellent.

Regarding crashes: With EA story I, of course, crash at 1:00 AM. With AwesomeStory, I've yet to experience non-Try for Baby related crashes (Ran for about 2 Sim days, will keep trying until I experience a 'random' crash).

Regarding folder arrangement: I copied only d3dx9_31.dll from the Framework to the WA Bin folder. Only the base game has the Framework and AwesomeMod installed. Awesome features work fine for me (besides the issues mentioned in my previous post) with this setup.

EDIT: There it goes. Got through Day 3 without crashes (on a new game) before a 'random' crash occurred (using AwesomeStory).

May I suggest not typing at all? It has the potential save even more time and effort than your current approach.

I've been testing this version of AwesomeMod with World Adventures installed and patched to 2.2.8.002002. The base game is patched to 1.7.9.002002.

Naturally, I've tested it while removing all custom content with the exception of TS3 Store booty. Everything I've tested seems to be working just fine for the patch, sans two problems that are instantly eliminated when AwesomeMod is removed:
1. Attempting to set up family relations via Create-A-Sim causes extreme mousefail.
2. A successful "Try for Baby" results in an instant crash with no errors/debugging options. This does not occur when no baby was made; it only occurs when I otherwise would have heard the bells.

These occur whether the game is new or saved, and persists for all families. It is most likely that my game has simply failed, but I thought I would put these out there to see if others have found the same things to occur. I do not ask for help solving them, merely whether other testers for this version of AwesomeMod with a similar setup experience the same issues.

Just to be sure: The default option for that AwesomeMod field disables the no-CD check; changing the configuration field for that to "Disabled" would, in fact, re-enable the check. You say that the other features of AwesomeMod work, and the way you worded that sentence makes me think you might have changed an option in an attempt to 'disable' it. Otherwise, I've got no ideas. Sorry.