ana

entitled to what? a realistic experience in a community built upon a game that has always been about personalization and representation? is it seriously too much to ask to have hair cc that represents your own hairstyle in a sandbox life simulator? i'm sorry, but some of you have gotten extremely comfortable letting your racism show.

"i only make the content i want! if you want this kind of content, make it yourself!" you need to ask yourself why you only want to make cc based on eurocentric standards of beauty. why are you so afraid of having the slightest bit of melanin in your game?

i am a white person before i am gay, before i am trans, before i am autistic. some of you guys need to realize this as well. racism is a bonding experience between races and what i've been seeing is blatant and unapologetic racism. my friends have been getting dogpiled and dragged every which way by some very loud and very bold people who i think need to educate themselves. some of yall need to confront your own internalized racism. do not settle for a sub-par experience in a community that needs to do better just because you think it's what you deserve.

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

Basically, when devs are programing a game, to check if textures aren't loading, they often put a really obnoxious, eye-catching texture in to make it easier to spot.

Other examples include Valve's iconic pink checkboard, Bethesda's similar hot pink/purple textures (video 1, video 2), and Sims 4's gradient question mark and demonic question mark textures.

These are, as said above, obnoxious and eye-catching on purpose because they are easy to spot even on small objects or in the distance, and their sole purpose is to inform devs that textures aren't loading properly. So basic game logic is if the intended textures don't load, default to obnoxious texture.

Pink flashing and pink soup have always been the result of the intended textures failing to load en masse, and the game is pulling the obnoxious debug texture. And now we actually have a working theory as to what's causing textures not to load based on spockthewok's research and master thesis.

What it's really important to take out of this is that the failsafe isn't directly triggering pink flashing.

Pink flashing is an indirect consequence of the failsafe panicking and telling the game to stop loading textures (and possibly anything else deemed resource-intensive) because on a 32-bit computer, TS2 using more than the 2GB of RAM intended can full on crash your machine and cause serious issues that obviously the devs didn't want.

So, since part of the failsafe's panicking is to stop textures from loading as they're very resource intensive, the game pulls the "shit isn't loading" texture instead of the actual textures, because TS2 deemed itself running out of memory and crashing is better than the whole computer running out of memory and crashing. In result, pink soup.

We're only really noticing this now because the 4GB patch means, in theory, TS2 should be able to call on up to 4GB of memory, but due to the failsafe, this isn't entirely true. You can now technically play past what was historically possible, but honestly the same failsafe that results in pink soup is probably designed to ultimately crash the game to prevent catastrophe.

(Which does also mean there's a possibility that raising the cap for the failsafe to trigger or removing it out-right might cut down on at least some of the crashing.)

The fix itself (along with the thesis for those interested) can be found here:

So his experimental mod for TS2 RPC launcher basically tells the game to stop freaking out and turning stuff pink when shaders' memory usage goes over certain threshold. NOTE: it may get rid of the pink, but the game will still crash if you exceed 4GB limit.

There are two mod options to choose from:

Version 1 is more radical, it completely removes the safety check. You'll (probably) find out the shader's memory limit has been exceeded when your game crashes.

Version 2 is supposed to allow some pink soup at around 3.5 GB memory usage, near the danger zone, so you have time to act - so obviously, this one sounds more sensible.