If you'd be so kind as to explain to me the difference?
Do I always have to turn nID into an ID for the checks to work, for instance?
I already know that as the *instance* ID, Sim ID is a safer way for engaging a Sim in an action through the instanced object. You want the Sim's instance, if present, to be called to work. But what about checks?

My specific problem: I want to check an nID against the "Person Type" global BCON (0x0104).
Do I need the Sim ID for this, or would nID be enough (or safe-er)? And if so, why exactly?

ETA: Correction: would *Sim ID* be a safer choice, and if so, why exactly?

My head is spinning...

ETA.2.: Another example: "Stack Object's person data Ownable Lot Job - Lot ID == Current House". Does the Stack Object here *need* to be Sim ID?

ETA (I promise - no more after this): Just to make clear: I know the difference between them. I'm just not sure when to use one and when another.

The nID is the sim's "Neighbor ID". That number stays with them from the moment they're born right through to the grave (or ghosthood, or zombiehood, etc). It stays with them between lots, between families, in other sim's memories, pretty much everywhere. If you want to store a reference to an individual sim, that's what you want to use.

The Sim Object ID (which I assume is what you mean by Sim ID) is the object ID for the sim. Absolutely everything on a lot at any time has a number associated with it, an object ID, and that number is unique to that lot. You buy a chair, it gets a new object ID. A sim arrives on the lot, it gets a new object ID. But those object IDs are only relevant from the time the object first spawns on the lot until the object is deleted from the lot. A visitor might have a different object ID each time she visits. If you take your sim to a different lot, he will probably get a different object ID.

You need to use the Object ID if you want to access the sim through the Stack Object. So if you want to access a sim's person data while they're on the lot, then you'd set the Stack Object ID := Sim's Object ID. Then you can retrieve "Stack Object's Person Data whatever", and it would be for that Sim. The Stack Object ID always needs to points to an object which exists on the lot.

If you want to store some information about a sim indefinitely, between lots, (like a friendship, or an object's owner or something like that,) then you need to use the neighbour ID. That way, no matter what happens, it will always point to the same sim.

Neither is inherently safer than the other, they just have different purposes. Does that clarify?

Yay! Thanks Again, you explained it all.

Instead of editing my previous post, I've decided to add a new one in hopes that this way it will get noticed. It's been some time since this thread's been active, so - I hope I'm doing it right

Anyway, I have a serious question and an issue. Again. Always with the issues...

The expression from Echo's previous post: "Stack Object ID := Sim's Object ID" means "Stack Object ID := *MY* Object ID", right?

Also, if I write: "Stack Object ID := My Object ID" TRUE: "Stack Object ID := My (Person Data) Neighbor ID" it's the same as writing "Stack Object ID := My (Person Data) Neighbor ID"?
So I can simply write: "Stack Object ID := My (Person Data) Neighbor ID"? Or shouldn't the Stack Object ID be a nID?
In other words, if the interaction object in an *interaction function* is in the Stack Object then when I call "My Object ID" I'm calling the Sim's object ID? That's not some other, random object?

For instance, in this error log:
"Error: Object referred to must be a person.
Iterations: 15
Frame 8:
Stack Object id: 19
Stack Object name: Controller - Inheritance
Node: 57
Tree: id 4128 name 'Sub - Produce Clothes - Process - Badge Bonus' version 5
from SIMPE_SCULPTUREWISEMAN_CRES
Prim state: 0
Params: 2 20 Locals: 346 20 18 19 73"

You can see that the Stack Object id is 19 and that 19 is "Controller - Inheritance". But 19 is also the Local3 variable value which stands for the acting Sim's nID - and if I may say so, that nID is correct: it is the Sim, since in an info message using that same Local3 value (i.e. 19) I get the correct info about a Sim's name and surname - the info correctly identifies the Sim as a creator of the box (the object made by the object he's interacting with). I even have a "Verifiy nID" somewhere down the same stack, that verifies the same value as a Sim's nID.

But in this BHAV, this very same value 19 is the ID of the "Controller - Inheritance"?! An object ID (a temporary ID created by the lot load, as I understand it) has - apparently - the same numerical value as is an unchangeable nID of a living Sim. (Is my problem accidental?!)

What I did to get that controller into the Stack Object ID? While the interaction object (the fashion station) was on the stack as Stack Object, I called "My Object ID", thinking it was the Sim's ID, into the Stack Object and got the Controller-Inheritance ID.

*confused

Imagine this scenario:

You load up a new lot in a completely clean game. This lot has four things on it:
A letter box (Object ID: 1)
A rubbish bin (Object ID: 2)
Betty Sim (Object ID: 3, Neighbor ID: 1)
Bob Sim (Object ID: 4, Neighbor ID: 2)

You have two sims, so they get the unique Neighbor IDs of 1 and 2. You have four objects, so they get the unique Object IDs of 1, 2, 3 and 4.

You then take Betty to a new lot. This is a community lot, so it has:

A phone booth (Object ID:1)
Betty Sim (Object ID: 2, Neighbor ID: 1)

Notice how Betty has a different object ID (because she's on a different lot) but her Neighbor ID has remained the same (because that number is hers for life). Also notice how the values in the object IDs are in no way tied to the neighbor IDs.

Now, assume you're in that first lot, with two objects and two sims.

With Betty as the active sim, you click to run an interaction on the rubbish bin. At the point where the interaction starts, Stack Object ID is 2 (the rubbish bin's object ID) which makes the Stack Object the rubbish bin, and Me is the sim (Object ID: 3, Neighbor ID: 1)

If you run the following code:
"Stack Object ID := My Object ID"
then the Stack Object ID becomes 3. That means that the Stack Object is now Betty. Hooray! :D

However, if you run:
"Stack Object ID := My (Person Data) Neighbor ID"
then the Stack Object ID becomes 1, because that's Betty's neighbor ID. But if you try to access the Stack Object, it'll look for the object with the Object ID of 1, which is the letter box. So now the Stack Object is the letter box. Probably not what you were after.

The Stack Object ID is basically a special "pointer". Whatever number you put in there, it looks up the object with that object ID, and makes that object the Stack Object. From that point on you can look up and modify that object's data using the Stack Object data owner. While you can technically put an nID in there (as you saw above), the stack object can't tell that the number you gave it was an nID, so it will continue to assume that it's an object ID.

Most neighbor IDs will end up having the same numerical value as an Object ID at some point. That's pretty much inevitable. Consider this scenario:
In your world, there are three sims:
Bob (nid:1)
Betty (nid:2)
Bruce (nid:3)

Betty moves into a new lot by herself. Now, let's assume that there was some logic in there to stop objects from getting an oID with the same value as a sim's nID, so the letter box gets the object ID of 1, and the rubbish bin gets the id of 3, thus neatly avoiding a conflict with Betty's nid... Then Bob and Bruce come around to visit, and we've got a conflict again - Bob's nID is the same as the letter box's oID, and Bruce's nID is the same as the bin's oID. We already established that the oID won't change from the time the lot is loaded until the time the lot is closed, and the nID never changes... Basically, it's not possible to keep the two number series' from stumbling on matching pairs occasionally.

As for the stack trace you posted, it looks a lot like a a command which was expecting the Stack Object to be pointing at a sim, and then found a not-sim object. You want to make sure that the Stack Object ID is pointing to the sim's Object ID, not their nID.

This is driving me nuts, I tell you. ATM I'm ready to give up on my idea of learning this modding stuff...

This was the situation in detail:
Right after the "Stack Object ID:=Local 0" (interaction object's - i.e. station's - object ID), there was a line "Stack Object ID := My Object ID". Shouldn't have this been the Sim's ID?
Namely, I first put the "My Object ID" into the Stack Object and *then* I wrote: "Local 3:=Stack Object's /Person Data/ Neighbor ID".

So, in a word, I was doing it in correct order. First put Sim's ID in the Stack Object, then access the person data from there and use it. But "My Object ID" was apparently "Controller Inheritance"'s object ID. Not the Sim's ID.

ETA: Unless I had to first put that data into stack object and then stack object into the local 3? Like this: "Stack Object ID:=Stack Object's /Person Data/ Neighbor ID" then "Local3:=Stack Object ID"?

My head is spinning. I'm sorry if I've made yours spin too.

Are you inside an interaction at this point? Could you attach the whole stack trace, and possible even a screeny of the BHAV that is causing you grief? What you've described sounds fine, I suspect your problem is not in these three lines of code but somewhere else.

Stack trace - sure, can do that. Though I've changed the code in the meantime to make it work - so now it's not what it was then. But the error log you can have

Thanks for trying to help me.

And "somewhere else" is exactly where I'd like to be... I thought I understood this.

ETA: The node the error log finally points to as the place of the error is the line "Local 3:=Stack Object's /Person Data/ Neighbor ID" (node 55). Obviously, since the object was the controller that has no person data for access.

Don't stress about this stuff, a lot of the time it's a really simple fix. From the sounds of it, you *do* understand it, you you just need another set of eyes.

Okay, I need to see:
Sub - Produce Clothes - Process - Badge Bonus, around line 0x39
Sub - Produce Clothes - Process - Make Clothes Box, around line 0x2D

Either a screen shot, or if you're in a hurry you can attach the object. (You can always unattach it later if you're worried about someone else looking at it, but honestly, I've yet to see anyone steal a broken object from one of these threads. )

I'm not worried about theft, not in the least. I want it to work. Okay, I'll attach it. There are actually two: station and the box the station produces. The box also had a funny issue similar to this one where in the same way (through a "Stack Object ID:=My Object ID" line) the Light Controller got swiped into the code instead of the active Sim's.

Do you have the stack trace which goes with this version of the object? Or alternatively, the version of the object which goes with this stack trace? (Because the two don't line up, I can't actually tell which line is causing the error. )

ETA: Okay, I can see a couple of things without the stack trace. Delete lines 0x33 and 0x34, then change line 0x35 to "Stack Object ID := My Object ID", then see how that goes.

There you go.

ETA: And I will do as suggested and see. lol

The lines you suggested to delete are there as an attempt to fix things. Funny, right?

I thought they probably were... Honestly, I've never actually seen "Neighbor in stack object 0x0000 (person instance id))" before.
Give the suggestion above a go, and see if you get any further.

That expression is used in game code when a param (or a temp) containing a nID is passed to the code, and you need an ID, for instance in the "Is nID Owner of Shop ID?" or something or other.
Anyway, it was an desperate attempt to get any Sim into the Stack Object istead of the stupid Controller...

ETA: Now it's "Error: Missing neighbor for data access." at the node 53 - the node I just added, I think. Will have to exit and load SimPe, but I'm fairly certain it's that line.
Log attached.
ETA, again: At least, the box is behaving. No errors there, not in the instances it was before. I guess I should be happy. But am just confused and discouraged instead. I really don't know what i'm doing either wrong *or* right at this point....

When I remove the two extra lines and change the third, then that makes line 55 this:
Expression (Stack Object ID 0x0000 := Local 0x0000 (Station ID))
Which can't throw the "Missing neighbor for data access." error, so I think you might have changed something else in the object at the same time?

The good news is that the Stack Object is now definitely Trent, so that part's working correctly.

Loading SimPE as we write...

Thanks again for sticking with me through this one.

ETA: It's node 53, line 35, the dialog. $Object is making a problem out of itself. Any suggestions as to the proper substitution? Or should I simply use a local value and then call $NameLocal:x in the dialog? That way I'm losing the gender difference of the dialogs too, which is kind of the whole point of this entire issue. I wrote it this way to get to that gender data.

Oh... I missed the part where everything is working and now only the dialog substitution is an issue. But isn't "$Object" here supposed to be Stack Object ID, i.e. Trent's object ID? Oh, noes - it wants a nID?! But that is not object...
See? I'm lost.

You've already got the sim's nID in a local, you don't need to get it again. Just change $Object to $NameLocal:3 in both lines and you should be able to keep the gender specific text.

ETA: I really must sleep now, but I'll be back on tomorrow if you're still having trouble.

Yeah, as i said, i missed the part where my problem is *solved* )

Thanks, Echo, from the bottom of my heart. I'll give you credits for this one, if I ever finish it: to Echo, for she kept me sane through a nasty ID issue.

ETA: So anyway, now that's behind us, how did that Controller end up in my Stack Object? I have a feeling it can pop up in any Stack Object it likes!

No crediting required, just glad you got it working.

No problem, i think I'm gonna catch a few z's myself.

ETA: So, a couple of z's later, I've come to believe that the stray "Inheritance Controller" is exactly that - stray. In other words: a bug. Or a situation specific to *my* game. That was no kind of clean, testing environment - it was my game, as I play it, with tons (and I mean: tons) of hacks.

Anyway, I think it's relevant that the numerical value of the stray object ID is the same as is the nID of the Sim whose object ID should have been there. (Try to say that one fast, I dare you )

As if the game supplanted a nID instead of an ID of a Sim. Has this behavior been noted in the TS2's past? Some sort of a related bug, functioning like this?
It happened once before too - with the box object, and in a similar situation, where the ID's numerical value was 20, which is also the nID of Trent's wife. Then, the stray object ID was "Controller - Light". It was also after an "Stack Object ID:=My Object ID" expression.

It has to be a bug, right? Otherwise, I can flush all I've learned down a toilet - I understand nothing.

Could it be relevant that the family in question is the Travellers? They are said to be borked anyway. But if they are this borked, you don't want them anywhere near your poor stack objects!

Also, I think it could be the lot. Maybe. Since it tends to happen there. I'll move them out into a different lot and see what happens. I mean, in one instant, the code works, in another it doesn't. What are the signs of lot corruption? Could this be one of them? Wandering stack objects, like little lost stack zombies: controllers instead of Sims... Sounds like an apocalypse to me.

First thing, do no flushing of learning. You have excellent learning, and it must not be flushed. Your code is very readable, straightforward, and shows that you do know what you're doing. Stack Objects and the like are a confusing concept, and one which catches up even the most experienced of modders unexpectedly.

The reason you were ending up with the Inheritance Controller as the stack object was that you had this line:
Stack Object ID := My Neighbor ID
rather than this line:
Stack Object ID := My Object ID
Since the current sim's neighbor ID happened to have the same numerical value as the Inheritance Controller, that meant that the Stack Object became the Inheritance Controller. When you then went to look up the sex of the person, you got an error because the controller has no sex (poor controller).

I don't think this error was caused by a game bug, or even by another mod. If it were, than the fix we ended up with would not have worked the way it did. I do, however, *strongly* suggest doing all modding with a test game and test sims, rather than your actual game with actual sims. Modding can and will completely bork families if you're doing it creatively, or if you accidentally save a lot with a broken object, or any number of other things completely unrelated to whatever else you have in your game. Plus, it's a *lot* easier to narrow down problems if you can discount third party mods as the potential cause!

I'll be looking forward to seeing the finished product!

I deleted my last post because I hate double posting and I really had to put this separately. I know what exactly was the issue, finally. And this maybe helps someone else so....

Inside the dialog after the gender check, there hid a "neighbor" in the Icon box.

I wasn't aware of it - I thought I removed that, but obviously I got distracted by something else. I certainly didn't leave it there on purpose.
It was a part of an experiment that I gave up mid-way, before even testing it in game. I even remember thinking during the whole thing that I removed it, and that that shouldn't be an issue. Why didn't I check?

Anyway, that's why object ID wasn't enough - it wasn't what the dialog needed. But I knew that the gender check needed an *object* ID, because I wanted it so: "Stack Object's Gender" - so ID, not nID, cause I've never seen an nID used in stack object at face value. It is placed there to extract the info out of it.
So I thought I was going crazy. Obviously. My stack object has been kidnapped - or so I thought.
And I panicked - I tend to do that when basics of anything seem to be disrupted. So I put there what ever I could think of to get to that "person" or "neighbor" the code was always missing.

Stupid accident. And a warning - if you have a dialog right before the node which errors claiming "neighbor" is missing, check out the dialog, and the "icon" box. That's where the neighbor is hiding...

Anyway, thought this thread needed the same closure I felt when I found out what the problem was.
I feel such a relief. I was not crazy - just careless and ADD as usual. But most importantly, my stack objects are *safe* and where I put them.