I've also been getting this error for about a week also. My full error code is 123:35e4f805:2671b6ce. Deleting easels did not help.
I’m encountering a persistent Live Mode crash (error 123:35e4f805:2671b6ce) that appears when switching certain lots from Residential Rental to Residential, or when loading households into these lots. The issue began after adding items from the For Rent, Werewolves, and Laundry Day packs.
> Do you own the eco pack and get famous?
No, I don't.
Key observations:
Any new lot built from scratch with new-pack items works fine, including Live Mode and saving.
The crash only occurs after a lot has ever been zoned as a rental; changing back to Residential triggers the Live Mode crash.
Resetting the lot with forrent.resetlot and eviction does not fix it — hidden rental data appears to persist in the save.
Saving affected lots to the Tray often produces “server errors,” suggesting corruption in lot serialization, but this may be secondary to the Live Mode crash.
Sometime I can load into Live Mode on the effected lot and households. Maybe 1 out of 20 times?
Conclusion:
This appears to be a For Rent rental-unit data corruption that survives zoning changes, cheats, and even lot resets. The lot’s rental metadata seems embedded in the save, causing Live Mode to crash and Tray saves to fail. A workaround may require exporting rooms or manually stripping rental-unit components via a save editor.
Remedial Actions Taken:
Verified game files through Steam and EA App.
Performed a fresh reinstall of The Sims 4.
Attempted to save affected lots to the Tray and Library multiple times to test serialization.
Deleted all CC and mods to rule out conflicts.
Cleared localthumbcache.package.
Tested new saves and new lots with all new-pack items — confirmed they load successfully.
Incrementally added and removed new-pack interactable items (Werewolves, Laundry Day, For Rent) in small test lots.
Used testingcheats true and forrent.resetlot to clear rental data.
Evicted households from affected lots.
Switched lot types between Residential and Rental repeatedly.
Bulldozed and rebuilt rooms, saving isolated test rooms to the Library/Tray.
🧾 Troubleshooting Summary – Persistent Live Mode Crash (Error 123:35e4f805:2671b6ce)
Date Range: October 2025
Status: Ongoing — clean save and never-rental lot still affected
Issue Summary
Live Mode crash (error 123:35e4f805:2671b6ce) persists even on clean saves and lots that have never been zoned as Residential Rentals.
Originally suspected to stem from corrupted For Rent rental metadata, the issue now appears to be a deeper situation scheduling or object-component failure unrelated to zoning history.
Key Observations
Newly built test lots (with identical assets) still function normally.
Affected lot (Alpha 3) was never a rental, but still triggers Live Mode desync and crash.
Save file confirmed clean of rental data (no rental tuning in lot or household).
Crash reproduces consistently when placing or loading into the affected lot.
Lot placement without furniture occasionally succeeds; with furniture, it often CTDs.
Reproducible error in logs:
"AttributeError: 'SituationSchedulerComponent' object has no attribute 'object_situation_shifts'"
Indicates missing or broken situation scheduler binding to an object or lot component.
Conclusion
Root cause has shifted from rental data corruption to broken or orphaned SituationSchedulerComponent references within lot objects.
This points to a core lot-component corruption?
The component error originates in object_based_situation_zone_director.py, meaning one or more objects on the lot are still linked to invalid situation or business logic.
Remedial Actions Taken
✅ Full clean reinstall of The Sims 4.
✅ Verified game files (Steam + EA App).
✅ Removed all Mods/CC and cleared localthumbcache.package.
✅ Tested affected lots in clean saves — same crash persists.
✅ Built and tested new lots using same packs — confirmed stable.
✅ Attempted placement of affected lots with and without furniture.
✅ Bulldozed, rebuilt, and isolated room-by-room to test stability.
⚠️ Desyncs remain tied to specific lots, regardless of save or mod state.
⚠️ Crash now consistently references the SituationSchedulerComponent, not rental scripts.
Current Status
A3 and other previously affected lots remain unstable even on clean saves.
No rental or mod dependencies remain.
Crash is reproducible under fully vanilla conditions, confirming core lot corruption rather than systemic save or mod interference.
Thoughts for next time
Remove vanilla bars and interact-able items? I'll think more about it later but I'm just going to give up on this lot until there is a status update and use my old megabuild.