"Prince Bolkonsky?" "No, simply Bolkonsky."

You know that thing where a story is written in tight third person limited — we’re meant to be inside someone’s head, seeing the world through their thoughts — and then suddenly the narration says “the blond frowned” or “the shorter woman sighed” about a person the POV character knows really well?

That’s called antonomasia — using a descriptive label instead of a name. And it’s fine when we’re talking about strangers: “the cashier handed her the receipt,” “the tall guy blocked the door.” The POV character doesn’t know their names, and we just need a quick way to tell people apart.

But the moment it’s used for someone the POV character already knows, it breaks immersion. Because that’s not how our minds work. We don’t think “the older man smiled at me.” We think “Mark smiled.” Or maybe “my boss” if that relationship matters in the moment.

Third person limited means the narration sits inside someone’s perception. Their inner monologue is the story’s voice. So when you switch from “Mark smiled” to “the blond smiled,” you’ve pulled the camera away from their mind and turned it into an outside shot.

If you want to create distance or irritation, you can do it on purpose —

“The idiot from accounting emailed again.”

That’s character voice. That’s judgment. That works.

But otherwise?

As soon as your POV character knows someone’s name, use it. While we do tend to worry about repetitions, names rarely register as such to the readers.

If you need variety for rhythm, use relational or emotional identifiers that make sense in their head: her friend, his partner, their teacher, the person they loved.

Because inside someone’s thoughts, there are no “blonds” or “brunettes.”

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

A herd of donkeys 🫏

Dedicated to the blog that said people in their 30's are too old to be on Tumblr and we should just "go scrapbook or something."

Hannibal illustrations by CelestialsArtistry. Everything else by me. Suck my dick.

+ Bonus