My guess is you're using the wrong version of twojeffs' Visitor Controller. Never saw that "attempt to call a nil value" error before. I'll have to make note of that.

What you describe sounds like normal behavior. Are you sure you understand what those hacks do?

Is there anything wrong with the second CD? Can you browse and see the files okay?

Use the Inge teleporter shrub or Insimenator teleporter+family tree to move them in. Then use the newspaper to move them to the bin.

Try cleaning your mouse.

The cheat doesn't always work right away. Depending on which EPs you have, you may need to return to neighborhood view, then lot edit mode. Also, be careful not to go too high or the game engine may crash to the desktop.

Another option would be to modify the BCONs at 0x7FF64E02. That way, you can control which levels of aspiration decay and which ones don't.

The second error is an old one that we've discussed before. Simply shift-click on the stereo (in testing cheats mode) and set the offending sim's dance skill.

That first error is a little bizarre. I've seen things like that happen (for example, there's a bug in the Bad Mouth social that can cause an NPC to activate behavior trees that aren't meant to be run in "immediate" mode). What you're witnessing there is more akin to tight pants (as Pescado would say) in that I can't even see where this 'Function - Main' is coming from. The actual Maxis code at that treeId *should* be the 'Function - Init'.

In Windows, you would just hit Wnd+R, then run "cmd.exe". Then type in the following command:

dir MYDOCU~1\EAGAME~1\THESIM~1\DOWNLO~1 /S >listing.txt

Or something like that. On a Mac, you just pull up a terminal and "ls -1R >listing.txt" in the proper folder (wherever it is).

See attached. (Slightly edited to contain just the important stuff.)

I sometimes click the mouse button and don't get a menu, but that's most likely a mouse issue.

I think each significant developer on a project should have their own version of the code. The main developer should probably focus on simply maintaining the main code by merging the various diffs that each developer contributes. Ideally, the version control software would handle all that automatically.

If you remove SecuROM and it then works, then it was probably SecuROM.

Can't help you with saving dorms. I ran into similar problems with ordinary dorm operations and soon realized that I needed to bulldoze and replace more often. It's not like your sims are going to live there more than a semester or two, right?

There's also the slight possibility that you got a bad disc.

This gives me an idea...

The problem is not conflicts. The problem, I think, is that you can't count on the state of the VM even for ordinary modifications. It goes without saying that WTF type problems will show up with the type you're proposing to do.

It isn't just the way SimPE works that is problematic. There are many times when I work on something ordinary where through 3 or 4 revisions, I make only subtle changes that should not affect the logic of the code, but somehow manages to work differently anyway. Were I doing that to a custom Global or custom PersonGlobal, I doubt the code would work consistently at all.

Laptop mobos suck. It's cheaper just to buy a new computer than to fix the mobo in a laptop.

Ouch. I wouldn't use custom globals again. Debug hell. You're welcome to it Inge, but don't say we didn't warn you.

There is really no efficiency issue with the size of GUIDs. You can make them 128000 bits if you wanted without any performance penalty (with proper tables and separate hashing).

Given that The Sims sells in the millions and each customer is a potential creator, it's obvious that you need at least a 64-bit GUID. However, the smaller the GUID, the greater the likelihood of GUID collisions.

The real problem isn't how many GUIDs could be used on one computer, but how many unique GUIDs the entire world could use. Any collision anywhere (among published objects) would still conflict if you use those two or more colliding objects with the same GUID.

The mere fact that it *can* be hijacked (or someone could spill beer on the server) proves that it's inherently wrong. That gives a single choke point of failure, which is always a VBT. He who can destroy a thing controls a thing, etc.

Inefficient allocations are the fault of EA for not providing enough bits, and this once again goes back to the limitations of their shitty Simantics (which only provides 32 bits for a GUID). If their programmers working on TS3 have an ounce of common sense, they will more likely be using 128 or 256 bit GUIDs.

Is everybody having the tree issue running TSS or BV? I know TSS has its own exe file, but you can still run the BV exe instead.

Let's not have another GUID database next time, either. That was frankly a REALLY stupid idea. Whatever we do, it needs to be a lot more scalable.