Skip to content
The object editor is now NewTool
- The NewSO object editor has been renamed from Volcanic to NewTool on Windows and macOS. The application, running process, pink launcher button and prompts, window titles and About screen now use the NewTool name, while the launcher still recognizes older Volcanic installs during the transition.
- NewTool has its own blue-and-pink NT icon. The new artwork is used by the Windows executable and editor windows, and by the generated NewTool app identity in the macOS Dock.
NewTool works alongside NewSO on macOS
- **NewTool now launches NewSO as its companion on macOS and keeps its object tools connected to the active lot.** Creating an object instance and the NPC Manager now send their actions to the running game instead of silently doing nothing or crashing the editor.
- The Object Browser now shows real object previews on Mac. NewSO renders the same temporary simulated object used by the Windows preview – including multitile and dynamic graphics – and sends the finished thumbnail back to NewTool without requiring a second graphics device in the editor.
- Mac lots no longer damage their original artwork with block texture compression. The Mac OpenGL path was automatically packing small, dithered sprites into fixed 4-by-4 colour blocks, leaving foliage and objects visibly pixelated. Mac now keeps those textures uncompressed, as the classic artwork requires. Windows rendering is unchanged.
- Floor tiles on Mac are pixel-aligned again. A half-pixel offset left over from the legacy OpenGL renderer exposed the dark edges between adjoining diamond-shaped floor sprites, drawing a dotted diagonal grid across carpet and terrain. The current Mac renderer now uses the same aligned projection as the good-looking PC path.
NewTool opens the game again instead of dropping to IDE-only mode
- Fixed “Game startup failed: Could not find a part of the path …\IDERes\bg.png”. The editor’s own artwork ships next to the editor, but the editor switches its working folder to the install root so it can find the shared Content folder – so it went looking for the artwork in the wrong place and fell back to IDE-only mode every launch. It now loads that artwork from its own folder.
NewTool: crash when opening an object for editing
- **NewTool loaded and could create objects, but clicking through to edit one closed the whole editor with “Operation is not supported on this platform”.** The resource browser’s right-click menu (Alphabetical Order / Show IDs) was still built with the old .NET Framework menu classes, which .NET 10 keeps only as stubs that throw the moment you construct one – so the object window died before it ever appeared. The menu is rebuilt on the modern control and object editing works again.
Residents cook for the house, leave the food alone, and stay out of the beer
- A resident who is not a good enough cook now practises instead of giving up. Cooking a group meal needs a cooking skill of 5 – below that the stove is a fire risk – but nothing a resident did on an ordinary day ever raised their cooking. A resident who moved in under that bar could only ever grab a single serving for themselves, which is why they looked like they never cooked for anyone else. They now study cooking until they are safe at the stove, and then cook for the household normally.
- Residents no longer throw away food somebody still wants. Two of the three ways a resident can reach a plate already checked whether the food was still wanted; the third – the one they use when the house is untidy – did not, so a freshly cooked meal or a fresh loaf could still be binned. It now follows the same rule as the other two.
- Residents stop helping themselves to your beer tubs. They were already told to leave player-stocked drinks alone, but a hungry or bored resident took a different route to the tub that skipped the rule. Beer tubs, kegs, wine, cocktails and juice are off limits to residents on every route now. Guests and owners are unaffected.
- Thanks to Cecii, squeezannah and Sierra Raine for the reports.
Roommate invites tell you when the property is full
- Inviting a Sim to a property that already has eight roommates now says so. The invite was correctly refused – eight is the maximum – but the game only showed the generic “There was an error when trying to make you this Sim’s roommate” message, which made it look like something had gone wrong. It now tells you the property is full and that someone has to move out first.
Clothing racks: new outfits moved to the end, and “withdraw funds” pays out again
- Shop owners could withdraw $0 from a rack that had just sold a $10,000 outfit. If the property had skilling switched off in its lot settings, the game was treating the shopkeeper emptying their own till as if it were skill income and zeroing it out. The money was never lost – it stayed banked in the rack – but there was no way to collect it while that setting was on. Cashing an object out to its owner is now always paid in full, on every lot, whatever the skilling setting. This applies to any object that holds money for you, not just clothing racks.
- Outfits we add to the game now appear at the END of the “stock clothing rack” list. New outfits were being sorted in by price, which shoved every original outfit along and broke the numbering shop owners read off TSOmania.net and other guides. The base game’s rack is back in its original order, with our additions after it.
Crash when the game asked “who am I?” too early
- **The game could close with an “Object reference not set to an instance of an object” error coming from the local player lookup.** Anything that asks the client which avatar you are – the city chat box, IM windows, the bills dialog, the person page – went straight to the shard login result for your avatar id. Before the city handshake finishes, and again for a moment after a disconnect or while a reconnect is settling, that result simply is not there yet, so the lookup threw instead of answering. It now answers “no avatar yet” (0), which the callers already know how to handle, so the game rides out those windows instead of crashing.
- One related detail: while no avatar is known, the client no longer treats NPCs as if they were you (both share the id 0), which could make an NPC’s portrait or name appear as your own.
Staff portraits: one frame instead of two
- Team members’ portraits in the people list had a double border. The colored role frame was being drawn twice – once as the portrait’s own frame and again as a second outline painted on top of the picture – which made the border look twice as thick and cropped the outer ring of the sim’s face. The inner outline is gone; the role color now lives only on the normal person button frame, so Staff, Moderator and Admin portraits read the same as everyone else’s, just in their own color.