object rez and llGetKey()

How come when I retrieve a key for a rezzed object through object_rez(key id) it is different to when the rezzed object calls llGetKey() ?

Each rezzed instance of an object gets a new key. If that weren't the case, SL wouldn't have any way to tell multiple copies of the same object apart. When you use an object_rez event, you reference the UUID that is stored in SL's asset servers. The rezzed object is a new entity with its own key, which is what you read with llGetKey().

So the id in object_rez is the id of the object that is in the inventory?

No it is not. it is the id of the object that has been rezzed in world. Read Rolig's explanation again. Each new item that is rezzed is given a new key.

Welcome to the forums. Just hang in there, it all begins to make sense after a while!

The object is never "in" your inventory or the inventory of an object you are using as a vendor. What's there is a pointer to the object in SL's asset servers. The object only "exists" when you rez it by referring to that UUID with object_rez (key UUID). You can refer to that UUID as many times as you like. It's like looking for an original document by its file number, finding it in the proper file cabinet in your office, and taking it to the Xerox machine to make a copy. The COPY is the only thing that makes it out of the file room. The original goes back in the file cabinet. When the copy leaves the file room, it's stamped with its own number so you can keep track of it.

ETA: To be really clear, now that I see Jesse posted a reply while I was typing... .... The idea here is that your script rezzes an object by calling llRezObject. That action refers to the UUID in SL's asset servers and produces an object at the coordinates you chose. It also triggers an object_rez event (if you have written one into the script), passing it the key of the newly-rezzed object. The object_rez event therefore makes it possible for you to do things that depend on knowing the identity of the new object .... like broadcast its name and position to the world.... Make sense?

Actually, the OP was clear..

The object_rez() event for a rezzed object IN the rezzing object SHOULD have the same key as the rezzed object returns in llGetKey. That it doesn't means something is borked.

It could be you are rezzing multiple objects, or your llGetKey script is in a child prim of the rezzed object (child prims have their own unique UUIDs, too). object_rez just returns the key of the root prim of the rezzed object.

am I going in sane or did neither Rolig nor Jesse answer the question?

Find UUID for the rezzed object in the rezzing object:
object_rez(key id)
{
// id is the UUID for the rezzed object
}

Find UUID in the rezzed object:
ID == llGetKey();

Bobbi ask this (as I read it): why is id not equal to ID?

I can't answer that because in my opinion they should be the same

I agree with Dora and Talarus.

I can only surmise that the others misread object_rez() as llRezObject() -- but IIRC, the latter doesn't take a key, it takes a string name.

In any case, it sounds like something's seriously borked. I'll try to recreate.

EDIT: I looked back and I answered the follow up question that I quoted correctly.

Just checked in Agni and they are the same:

[16:43] rezzed object: 30f220a8-597f-42df-a5ba-12ff04615eaa
[16:43] rezzer: 30f220a8-597f-42df-a5ba-12ff04615eaa

Now are you trying this in Agni or in Aditi?

Ooops, here is my test setup:

//rezzer
default {
	touch_start(integer n) {
		llRezObject( llGetInventoryName( INVENTORY_OBJECT, 0), llGetPos() + <0,0,1>, <0,0,0>, <0,0,0,0>, 0);
	}
	object_rez(key id) {
		llOwnerSay((string)id);
	}
}

//rezzed object
default {
	on_rez(integer start_param) {
		llOwnerSay((string)llGetKey());
	}
}

Hmmm... I did misread the question. I thought the OP wanted them to be different. I did a test like Jesse's earlier today and it worked for me too.

(fixed), yes.

Yes, you did. It was confusing, though, because Rolig's answer was non-sequitur. It's all good now.

It's easy for this kind of misunderstanding to happen.

If the OP can reproduce this, it's a serious problem. Most likely, there's something else going on and confusing the results.

When I get counterintuitive results, I keep stripping out code as long as the "invalid" result continues, to get the simplest script to show the problem. Often, I find out that something else was interfering with my understanding of what was really happening -- that is, the problem goes away when I remove something I thought didn't matter. Other times I end up with a simple script (or pair of scripts, as above) that shows something truly failing. Either way, I learn something.

It's time consuming, but often the best way to make progress.