link_message

haveing a little trouble with this . I have one prim message link to another prim sending text then a third latter calling the same prim with diff text but the the next time thru the variable ie str keeps the original value. Am i missing something?

Yes, but without seeing the code it's hard to say what.

Let me check I've got it right: A sends a link message to B with a string. C sends to B with a different string. B still thinks it's got the original value of string?

First guesses:

1) C isn't messaging B accurately the right prim.
2) You've got an = rather than == in your logic in B's link_message() logic.
3) You've got an error in a link_message event in A or B that causes A to resend it's value to B.
4) You've got something silly in the assignment operator for the message from C - including a ; on the end of the relevant if statement.
5) C doesn't actually send the different value you're expecting it to.

Without scripts it's almost impossible to say I'm afraid. There might well be other things that are wrong too, but they'd be where I'd start.

thanks for your help i tried and checked all you said but still haveing the same result had it once before had to resort to listen but even that wont work could it be there is a bug in the prim itself ive had that happen cut and pasted exact same script into a new prim and it works

I've had that happen before on occasion, where a prim itself seems to get borked. I could open a script file, make a change, recompile successfully, and it'd still act like the old script was in place.

Only solution I ever found that worked in that scenario was redo the prim, and paste the script into the new one.


- Newfie

Yes could be that too. In fact I had it happen this morning and I'm still swearing about it, lol.

happend to me enough times to wonder if that is what it is madening tho to check everything and THEN check that and its it grrrrrr well thanks for your help

Listening is persistent to the prim it's put in, like floaty text and sitpos, you have to shut it off not just delete the code setting line. My guess is that at some point there was a listener in object C on the channel A talk.... if I understand the question right.

Are you sure listens are persistent, it seems contrary to other behaviour for them, although there is a ListenRemove() so it's possible.

Anyway, listens and link messages shouldn't interfere with each other.

Listens are not persistent.