How not to get a NULL_KEY if defined twice

key id;

myParticleLink()
{
   llParticleSystem([PSYS_SRC_TARGET_KEY, id]);   
   llOwnerSay((string)id);  // NULL
}

default
{
    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay((string)id);  // NOT NULL
        myParticleLink();
    }
}

Hello,
id needs to be defined both for the custom function and the listen() event.
My guess is that the second definition doesn't update the value of the first variable even though it's global, and that's why the key can be null even later in the scope.

What could be the solution to this issue ?


PS : This is the simplified code.

I think the problem is that you have a 'local' definition of id in the listen declaration, try:

key id;

myParticleLink()
{
   llParticleSystem([PSYS_SRC_TARGET_KEY, id]);   
   llOwnerSay((string)id);  // NULL
}

default
{
    listen(integer channel, string name, id, string message) // <== subtle change here
    {
        llOwnerSay((string)id);  // NOT NULL
        myParticleLink();
    }
}

In your example, id in the listen() event handler hides the global id. Notice that I changed it so that id is now passed as a parameter to your function that calls the particle system.

- Bozo

Bozo is correct. (However, in the future, don't change quoted text, it's confusing. Post a new example.)

Get rid of the global 'id' variable, it's unnecessary here.

Deleting 'key' from the formal parameter list in the listen handler won't compile.

heh... well, I didn't know that... well spotted!

Right diagnosis... completely wrong remedy.

I guess if I do store an Event parameter - which can sometimes be useful - I must always be assigning them to a global variable in the code. Never really thought about it before.

Sure, just be aware it's a common source of bugs (storing event parameters in globals). You might still be doing something regarding an earlier interaction, and a new interaction changes the global. Sometimes there's no good workaround. Other times you can change state to make the first interaction undoable, or protect it in similar ways (e.g., don't clobber the global if a multi-step operation is going on).

Best to use a parameter as suggested by BozoCon, and whenever you're forced to use a global, it should raise an alarm bell.

You nailed the problem. By declaring id again, you're telling the compiler that references to 'id' in the listen event code refer to the argument, not the global.


Lose the requirement that you need variables in two different scopes to have the same value.

If you can lose that requirement, something like this...

key gId;

myParticleLink()
{
   key id = gId;
   llParticleSystem([PSYS_SRC_TARGET_KEY, id]);   
   llOwnerSay((string)id);
}

default
{
    listen(integer channel, string name, key id, string message)
    {
        gId = id;
        llOwnerSay((string)id);
        myParticleLink();
    }
}

...or this...

myParticleLink (key id)
{
   llParticleSystem([PSYS_SRC_TARGET_KEY, id]);   
   llOwnerSay((string)id);
}

default
{
    listen(integer channel, string name, key id, string message)
    {
        llOwnerSay((string)id);
        myParticleLink(id);
    }
}

...should work.

Thanks all.