#object limit

UPDATE: The information in this post is outdated. Please see this post.

Soooo... I didn't intend for two highly requested fixes for The Sims 2 to drop within the space of a week and a half, buuuut...

Here's where you can download an experimental patch to fix the so-called 'object limit'!

https://github.com/spockthewok/TS2ObjectLimitFix

(Ultimate Collection only at the moment, I'm afraid).

The good news is:

Both @lordcrumps and @teaaddictyt have tested it with stupidly large CC folders and report that it works.

There isn't a dissertation the length of Tolstoy's 'War and Peace' you need to read through to understand wtf is going on.

The crashing wasn't caused by some hardcoded object limit at all! (That I know of).

An explanation of the issue for programmers:

And for everyone else:

The code for the Build/Buy menu was missing basic checks to confirm that the data it was trying to do things with was actually valid. No, I'm not joking.

Basically, it appears that all of the objects you can buy in the game are stored in something you can think of as being like a big, long list, which grows in size with the more custom objects you have.

The only purpose of the code that this plugin patches is to sort the items in the list into some kind of order. This is done by assessing if the value of the previous item in the list is larger than that of the item currently being looked at, and swapping their position if this is true (also known as an insertion sort).

In short, the game wasn't asserting that the data it was about to compare for sorting was valid before accessing it, and then promptly blowing up when it tried to do so and discovered it wasn't.

I imagine that the odds of the game making an oopsie and dumping some funky data into the list increases with the number of objects it is having to process - this might be why this issue only presents itself to those using multiple GB of Build/Buy CC. It was much easier to patch the code encountering the bad data within the list than to try and hunt down the mysterious culprit putting the data in there to begin with, so this is all the information I have at the moment unfortunately.

Either way, one of the first things you're taught when learning to code is to ALWAYS check that the data you're operating on has been initialised (i.e. it holds some kind of value). I guess someone at Maxis must have skipped that lecture :D

Is the 255 objects per subcategory limit theory true?

The Downloads folder I was using for testing had ~672 objects in the Deco/Misc subcategory (Maxis objects included). With the patch, I can freely navigate throughout the entire subcategory with zero crashes, so I guess not?

What about the whole OBJD limit thing?

People have varying beliefs of what the limit on OBJDs might be, but HCDU reports my Downloads folder had an OBJD count of 20,787. Again, without the patch the game would crash when switching categories in the Build/Buy catalogue, with the patch, no crashing.

If you want to hear my opinion on whether such a limit exists, watch this video.

Do I even need this patch if I don't use much CC?

As it adds some fairly important crash-prevention checks to part of the Build/Buy menu's functionality, I'd probably recommend using it anyway, just to be safe - we all know how much this game loves to crash!

Aaaah! I'm still getting crashes with the patch!

I'm aware that a few of you CC addicts out there have Downloads folders larger than the total size of everything ever uploaded to the internet, so if you still experience crashing in Build/Buy mode with this patch, please take a look at the mod's GitHub page and send me over the information requested there. Fingers crossed that shouldn't happen, but if it does, I'll try my best to investigate :)

Anyway...

Will

If you click on LTW Chooser and the sim gets reset with "Too many iterations" error,

Congratulations! You've surpassed the Object Limit!

🏆

I recommend you sort out the limit issue, but if you want to live dangerously, you might just:

Download the object-limit-failsafe LTW Chooser

It will not recognize LTWs beyond the limit, but it will work for the rest of them, and chances are no LTWs will go beyond the limit anyway

I was getting crashes in the buy catalogue in random places that make no sense (once when clicking on the decorative icon, once when clicking on sofas). from my experience with the object limit, there is no rhyme or reason: the game will just randomly decide to crash when you're in buy / build mode. this is usually my clue that "you have too much damn cc!"

in previous cases i've dealt with this, the crashes would always happen when moving through the pages of the catalogue, but the crashes would be random (ie. it might crash on page 2 of decorative / sculptures; next time it'll be page 3. i've never had crashes when just initially clicking on a category, which is weird!

either way, it's fixed now- i was doing a lovestruck bonanza and using the category folders to see / get rid of things i didn't want. I don't typically throw in 4t2 stuff like that, since I like to use the conversion catalogue to look at all the objects before I even put them in. But they don't have a page for Lovestruck yet, and I wanted all the cute stuff now! Funnily enough, i wouldn't get any crashes when using the eye dropper to make a copy of an object- and i could scroll through the category it was in just fine without issue. but click on it myself? Sims 2 says nope! Crash.

I'll also say that given we still don't know much about the object limit, I still wonder what causes it. Like if there's a hard limit, something related to computer specs, or something else entirely. This laptop is a gaming laptop and has 32GB of Ram; my last one had about 16GB. I feel like I have way more CC currently than I did then, but that may just be me. Plus, it wouldn't make much sense, since Sims 2 is such an old game and can only utilize 2GB of Ram anyways (4GB with the patch, of course).

Either way, I'm probably overdue to go through my in-game catalogue and taking a good hard look at everything I've hoarded and determining if it's really necessary. Like... do I really need three different uni-type showers, where you just put them on the wall? I say yes, of course I do!! Obviously! But when it comes to keeping this twenty year old game stable and not crashing? Then, probably not.

The alleged object limit is the limit at which you can no longer add objects to your game without it crashing. I say alleged, because nobody seems to know much about it, including whether it really exists. I’m inclined to think it does, because I’ve come across it several times now and the results are always the same.

Basically, at first glance, it’s the usual story. You add new things and the game crashes. Either it’ll crash when you open the catalogue, or just a few minutes into game play. However, doing the 50/50 on your new downloads doesn’t seem to work. You take out half, the game works. You take out another half, the game works. You put it all back, just in case it was a glitch, but then the game crashes. You take out a different, completely unrelated folder of CC that’s worked perfectly for years, the game works. You add things in, one at a time until the game crashes. You take out the last thing you added, put something new in, it crashes. You take out the second-to-last thing you added, keep the last thing in, now it works. You have hit... The Object Limit.

I don’t know exactly what the object limit is, although on this computer, it seems to be about 10,000 files. I don’t know if it varies between computer setups (although I did take out a stick of RAM and was still able to run the same amount of stuff). I don’t know if it’s been fixed in the Ultimate Collection, which I own, but haven’t installed on this machine. I don’t know if a different Windows OS would make a difference. What I do know is that:

It doesn’t matter if it it’s a multi-tile object or not. Bundling files does not get around the limit. Putting files in Bins does not get around the limit. And it’s only objects that are affected. By that, I mean files containing an OBJD resource.

Bodyshop content is fine. You can have as much bodyshop content as you want without hitting the limit. Object recolours are fine. Neighbourhood deco is fine. You’d think it wouldn’t be, but it doesn’t contain OBJD resources. You know what does? Custom jobs! That’s why it’s so difficult to find info about it, people have been saying “oh but I have 70GB and no problems and you’ve only got 5GB,” but that 70GB could be all uncompressed hair in all Pooklet recolours, including unnaturals, with swatches included, and it wouldn’t make a difference. Or people will be very confused when they take out their custom jobs because they have no clue that custom jobs are objects.

Good Bad news, everyone!

I have returned from a grueling 48-hour adventure deep within the Maxis mines, and have witnessed unspeakable man-made horrors with my own two eyes — the object limit is very real and there is nothing that can be done to fix it! The end times are upon us!

Okay, I'm being slightly dramatic. It could be fixed fairly easily, but not with a simple patch, and likely not without access to the source code (anyone else tired of hearing that excuse?).

The issue is that the limit isn't localised to purely the Build/Buy menu — it's integral to every aspect of the game that involves objects. Here are just a few examples of the game's functionality that would need modifying to remove the limit:

Sim pathfinding and routing.

Mapping tree tables to objects.

Interacting with objects.

Manipulating objects within lists (reading/writing/deleting them).

Objects being unselectable in the Build/Buy menu was also a result of this limit and I managed to fix it very quickly, but because The Sims 2 is a house of cards with the limit as its foundation, everything started falling apart almost instantly.

"So, what is this limit?", I hear you ask. 32,767. Yes, you read that correctly. The game is only willing to accept object IDs up to a meager value of 32,767. In computing terms, this is the maximum value of a signed 16-bit integer. It can store many more objects than this in a list, which is why you can still see all your 4t2 objects in the catalogue, but it isn't designed to recognise this many IDs and thus can't do anything with them.

Why are integers signing things? Are they famous or something?

'Signed' refers to the fact that these are integers (an integer is just a whole number btw) that can represent both positive and negative values — negative numbers have a negative sign before them, hence the term 'signed'. An unsigned integer is therefore one that can only represent positive values.

While they can both represent the same total of different values, the range of representable positive values differs. Using 16-bit integers as an example:

Unsigned: 0–65,535 Signed: -32,768–32,767

This shows that both can represent 65,536 different values, but the range of positive values for signed integers is half of that of unsigned integers. Object IDs cannot be negative, which means Maxis deliberately chose to use signed integers as a way to cut the ID limit in half.

The cherry on top of all this is that the game is manually converting 32-bit numbers into 16-bit numbers to enforce this limit. This is why I could fix objects not being selectable in the Build/Buy menu easily, as all I had to do was patch out the conversion. Could EA do this across the whole game themselves if they wanted to? I imagine so. But then again, if I had billions of dollars, I probably couldn't be arsed either.

What's an object ID?

An object ID is just a number from 0–32,767 that the game assigns to each new object it places into a list, presumably starting at 0 and incrementing by 1 for the next object. It would appear that CC objects are given IDs first, which is why it was solely Maxis objects becoming unselectable after passing the limit.

Sims and objects are stored in separate lists, but I believe they both contribute to the overall limit. My single piece of evidence for this is that I experimented switching between several hoods and observed that the IDs of objects in the Build/Buy catalogue fluctuated across them. Objects in hoods with subhoods attached had higher IDs than in those without.

What was causing the Build/Buy menu crashes?

The same thing I explained in my original post (the game trying to access null pointers), except the creation of these null pointers was no accident and not the result of something going wrong.

The game merely checks whether the ID for the object it is looking at is above 32,767, and if it is, it deliberately sets the pointer to its address to 0. This would be fine, if it didn't then try and access this nullified pointer immediately afterwards!

I'll cut Maxis some slack here, because surely no one would be crazy enough to want more than 32,767 objects in their game, right guys? How could they ever have predicted such a scenario? (2004 was a simpler time).

Wait, so you were wrong about there not being an object limit? Not so cocky now, are you?

Whoa there, cowboy — hold your horses. If I may direct your attention to this excerpt of an email I sent to @teaaddictyt on the 22nd of April 2026 at 13:42 BST:

As you can see, I was right all along!!!

In my defence though, we thought the crashing was the only thing we had to solve, which is why I missed the completely obvious 16-bit conversion that was occurring within the functions I patched. Unfortunately, I am only human, but I understand if you want to destroy all the spockthewok posters I know you have hanging on your walls...

In light of these new findings, if you want to hear my updated opinion on the existence of the object limit, watch this video.

Is your patch useless?

Yes, but also no. It's not fixing the object limit (I should probably rename it tbh), but it is fixing those annoying crashes caused by it.

At the moment, not having the Build/Buy menu crash when you try and use it is the best we can do. It's up to you which you find more annoying — crashing, or not being able to buy x number of objects in the catalogue. Like the 4GB memory limit, this is going to be an additional constraint we'll have to learn to accept :/

Another alternative would be to join me and the 12 other weirdos who play with no CC, and never have to worry about any of this. No? Oh well, it was worth a try...

Will you ever actually fix the object limit?

If it's even possible without the source code, then not by myself, no.

Because of the number of core areas of the game that would need patching, I don't trust myself not to miss something and have the game explode. Unless someone wants to assemble a modding strike force to try and tackle the issue as a team over several months, I'm not touching it with a 10-foot pole (for your safety and for mine).

Should Maxis go on trial at the Hague for crimes against humanity?

Probably.

Anyway, that's all from me, apologies for the false hope :( One small positive is that I did manage to map out a reasonably large chunk of the game's code while I was frantically searching for solutions, which should make my life easier when looking at your requests. I feel like I need to successfully complete some of them now to make up for this dud!

Will

UPDATE: Might have already solved it, just testing now!

UPDATE 2: I have fixed the objects being unselectable, but their functionality seems to be broken when placing them...

Whelp, I knew the fix seemed a bit too simple...

To be brief, there appears to be an issue where some objects (seemingly always Maxis ones) become unselectable in the Build/Buy catalogue when using a non-specific amount of CC with the object limit fix.

Having reproduced the bug and observed what's happening in the debugger, I can see that the data for these objects is null, meaning the game has soiled itself (as usual) and failed to properly initialise the data at an earlier point in the code.

This means my patch is technically working as intended, as it's preventing the game from crashing in these instances, but the core problem remains unsolved, which is determining where this null data is coming from and what is failing for it to be created.

I'm not sure how easy it's going to be to figure out and fix, but rest assured, I am currently working on trying to resolve it.

Apologies for any inconvenience this may cause!

Oh well, back to it...

Of course! In fact, I'll even provide pictures :)

From what I have observed, the majority of things that define how an object behaves is dependent on the object ID it is assigned. If the game wants to know how many tiles the object takes up, it needs to use the object's ID to find that out; If a Sim wants to know which object is blocking its path, it checks the object's ID (and so on, and so on...).

Because these checks are limited to only looking at IDs up to 32,767, if the game encounters an object with an ID higher than this, the whole system collapses.

Here we can see that the game can't correctly determine the tile footprint of this bed, as its ID is over 32,767:

Likewise, placing the bed on the lot causes Sims to throw object errors in an endless loop because they can't figure out wtf it is or how to interact with it:

If you're lucky enough to try and interact with the bed in between each error, you'll find that you're unable to:

This is why removing the limitation would be extremely difficult, as there are so many moving parts that are reliant on it to work. I've been messing around with patching out the limit here and there, but once I modify one area, another one breaks.

If I use it anyway (to prevent the game from crashing in Buy/Build mode), and I have so many objects that the 32,767 object limit is exceeded, does the game randomly decide which objects become the ones that can’t be “used” during each play session?

In other words, how does the game decide which objects are the “extra” ones that stop functioning? Are they the objects from the folders that load last in the Downloads folder, or are they chosen randomly? Are they always the same objects, or can they be different every time the game is launched?

Hey!

The order the game assigns IDs is definitely not random. That's how I can confirm that it only appears to be OBJDs that increment the ID count, as the assigned ID for an object remained persistent across game restarts.

As for how this order is chosen, I'm not certain, but CC objects seem to be given IDs first as the objects that were breaking in the Build/Buy catalogue were always only Maxis ones. The only way the game 'decides' an object is non-functioning is whether its ID is 32,768 or above, as it is programmed to consider this impossible/invalid. All of the additional OBJDs from CC are simply pushing Maxis objects outside of the range of IDs the game permits.

I'll paste your other ask below for reference to save answering across two posts:

"If I don’t need Maxis objects taking up space from my object limit at all, is there any way to completely disable Maxis objects? Or perhaps disable the OBJDs of the ones I don’t want to use? They also unnecessarily clutter the Buy/Build catalog. And making individual default replacements for each object would be far too time-consuming."

I don't think there's a way to disable Maxis objects outside of deleting them from the objects.package files, but I really wouldn't recommend trying that. Thankfully, it's Maxis objects that seem to be the first to break, so if you really don't need them, you can always download some catalogue hiders that hide whatever objects you're not interested in to ease the clutter.

Hopefully that is helpful!