llMessageLinked Affecting Non-Linked Objects

First of all WTF?!

Ok now that I have gotten that out of the way, here is the quicky: 2 objects, exactly the same, not linked to one another. Only difference is the Message channel and string value stashed in a variable.

The copy of the original (object and script minus differences listed above) works correctly and does not affect the original, however when the llMessageLinked is activated on the original it affects both the original and the copy. Again... both of these objects are not linked. they even have different parent prims. And yet again... WTF?!

I would appreciate any help that I can get.

Sure you're not using a llSay or llWhisper in there someplace?

Yup.. it is the only way i can really describe the integer num in:

llMessageLinked(integer linknum, integer num, string str, key id)

As saying the message channel is the filter.. Unless I am misreading this.

Post some code!

Line from sending script

llMessageLinked(LINK_SET, 10001, "<0.2, 1.0, 0.0>", NULL_KEY);

Receiving script

link_message(integer sender_num, integer num, string message, key id) {

if (llToLower(message) != "" {
vector newcolor = (vector)message;
llSetColor(newcolor,ALL_SIDES);
}

}

Could someone explain the 'integer num' portion of this function? I believe I am getting this confused with a type of chat channel.

The 'integer num' section of the event/function is just that...the passing of an integer. People will frequently use that portion of the message to 'identify' message strings and know how to process them between scripts. Other times, it's useful simply to send an integer to another part of your script.

TECHNICALLY, the only information an llMessageLinked needs is an integer for how to send... llMessageLinked(-1, 0, "", NULL_KEY); sends, essentially, a completely 'empty' message to all prims in an object. Not so much in 'byte' emptiness (still sends data), but in that there's no useful info being sent. You can decide to send whatever you want through the num, str, and id parameters.

In fact...the 'key id' parameter is also useful for hiding strings...as a key is essentially just a string in another format.

As far as getting cross-talking objects...I would imagine it to be some sort of SL bug and would recommend you delete and remake your 2nd object. Shouldn't be happening at all.

By 'Message channel' do you mean 'Listen channel'? In the sending script what is it that triggers the llMessageLinked function?

If it's a chat command then the likely problem is that both objects are hearing, and responding to, that same command. They would then both execute the llMessageLinked function. Cross-talk is very possible in listen Event Handlers.

In my original post I thought that the 'integer num' of llMessageLinked can be used as a Message Channel, just in case you have different levels of communication within the same object. I understand that people are thinking that since I said "message channel" that they think I am confusing llMessageLinked with llSay, llWhisper, and llShout. I am not. I understand that they are two different function types.

I think that I have narrowed down the issue to my llDialogs... but, they are on 2 completely different channels on communication but one is still affecting the other.

Another question. Are variables set by scripts held client side? By this I mean that if one script is working with a string variable named say "ksStuff" but another script, running on the same client but in a different object that has a string variable with the same name. Would a change of the value in one script affect the values in another script?

Kenn, I will try that once I get back into SL.

It can be used for that, but you have to filter manually within the link_message event handler. When llMessageLinked is called, all scripts in the specified prim(s) with a link_messsage handler will have that event raised.


Scripts are entirely server-side. The only time a client sees script code is when the owner edits it, then it's uploaded to the server (sim) and all execution is handled there. (Though personally, I can think of a few examples in which at least limited client-side scripting would be advantageous, though it might be considered too prone to abuse to ever implement)


Scripts are entirely self-contained, so if this is happening, it's definitely a bug.

Deanna, thank you very much for that information. I have a better understanding now.

It sounds like you may have an open Listener. llDialog communicates on a chat channel and could be picked up by any object with a listener on that channel.

I have thought about that, one objects channel is on 10001 and the other is on 10002. So there should be no conflict.

I tried duplicating the copy of the copy and edited the script to be on completely different channels... Same issue.

One affects only itself while the other affects both.

Any other ideas? Or should I report this as a bug?

pass it to a (trusted) buddy, see if it dupes, without seeing the code its hard to pinpoint, ive never had this issue, and with the confusion surrounding this topic and your assumed novice skill (llToLower for no reason tips me off) its just hard to tell

I can't understand why you send 10001 in num when you don't use it? Link messages don't use channels. Try this:

llMessageLinked(LINK_SET, 10001, "<0.2, 1.0, 0.0>", NULL_KEY);

And in receiving script

link_message(integer sender_num, integer num, string message, key id)
{
if (num == 10001)
{
	 vector newcolor = (vector)message;
	 llSetColor(newcolor, ALL_SIDES);
}
}

What causes your link_message to be sent? Touch event? Chat message (including llDialog response)? I'd suggest putting a debug message via llOwnerSay (e.g. "I was touched" or "I heard this message: " ) in whatever event handler it is in which llMessageLinked is called, in order to rule out some sort of crosstalk before the link_message occurs.

This same question has appeared in here several times before. In all cases, what was happening was completely unrelated to link messages. They just *appeared* to be the problem. The real problem was that they were being triggered by some external event in both objects that the creator didn't realize he was doing.

As such, I would either recommend that you look for what code triggers the link messages, and look for crossover causes in it, or post your code here (or give a scripting mentor or guru in-world a copy of it), and have it looked at for you.

I can almost 99.999999% guarantee that it is doing exactly what you told it to do, and no bug in the link message implementation is involved at all.

Chat Message from a llDialog. The channels that the 2 objects communicate on through these llDialog are different. The last thing that I can think of doing is renaming the llDialog commands to be different. But someone should have to go through this much if the code is correct.

I'll get that looked into though.

This is difficult to diagnose without seeing a script but do you know that an object can listen to more than one channel?

Lets say you had: llListen(mnuChannel, "", llGetOwner(), ""; where mnuChannel is being read from a Notecard.

Scenario:

Original object reads Notecard and sets mnuChannel = 1. That object is copied into Inventory.

A second copy is taken from inventory and its Notecard is changed to 2 which, using the changed Event Handler, causes the Notecard to be re-read setting mnuChannel = 2. The copy will now be listening on channels 1 and 2.

The copy may appear to behave correctly (using channel 2), however, commands from the original (on channel 1) will also trigger the copy.

When using llDialog this is a common approach (showing snippets only):

opendialog() // User Function
{
    llListenRemove(mnuHandle);
    mnuChannel = llRound(llFrand(900000) + 100000) * -1;
    mnuHandle = llListen(mnuChannel, "", llGetOwner(), "");
    llDialog(llGetOwner(), mnuTitle, mnuOptions, mnuChannel);
    llSetTimerEvent(15);
}

:
:

timer
{
    llSetTimerEvent(0);
    llListenRemove(mnuHandle);
}

listen(integer channel, string name, key id, string message)
{
    llSetTimerEvent(0);
    llListenRemove(mnuHandle);

    // usual if {message == stuff
}

Notice that the one and only listen is always being removed prior to the llDialog and the llDialog is always using a randomly chosen, and negative, channel number. This is to prevent cross-talk.

The listen is also removed after 15 seconds under the assumption that the ignore button may have been pressed. This is to keep things clean by not leaving the unused listen hanging around - even though it would get cleared out the next time the Dialog was requested.

The listen Event Handler also removes the, now used, listen, and stops the timer which is no longer needed.

At all stages the listen and its channel are being tightly controlled to guard against cross-talk and to keep lag to a minimum. Like others, I'm of the opinion that this is a cross-talk problem.

You might need to post some more code, expecially your listen events. I.e., it's possible that even though your llDialogs are chatting on different channels, your llListens are not listening on different channels, but on ANY channel.

But it's hard to tell without seeing more code.

Rj

At the very least, try putting something like this at the very beginning of your listen() events as a debug measure:

listen( integer Chan, string Name, key ID, string Message )
{
    llOwnerSay( "\nChannel: " + (string)Chan +
                "\nName: " + Name + 
                "\nID: " + (string)ID + 
                "\nMessage: " + Message );

    // the rest of your listen code here...
}

This way, every time one of these objects hears anything, it will tell you on what channel, who, and what they said.