Altier Verwood Posted September 2, 2021 Share Posted September 2, 2021 Hello scripting people, I am working with a script I tried to write, to listen for a message, but it would change the command it listens for based on the owner of the prim. but I can't seem to get it to work, and I'm not sure what I'm doing wrong because the script is compiling. I blanked out the channel cause someone might see this and break my script XD default { state_entry() { llListen(-???,"",NULL_KEY,""); } listen(integer channel, string name, key id, string msg) { string name = llKey2Name(llGetOwner()); if (msg == name + "1") { llSetTexture("0e730d5c-55b3-2d7d-600a-a52b3a32201f", 0); llSetPrimitiveParams([ PRIM_NORMAL, 0, "325f39ee-3eed-a369-b6c7-5a33de6a68de", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]); llWhisper(0, name + "Complexity = Henagon"); } if (llGetCreator() == "59ce94d0-12e5-4f62-987d-b9b78cc74e82" && msg == name + "1") { llSetTexture("0a28d60f-b12d-df66-9d7c-c83ec3a92dac", 0); llSetPrimitiveParams([ PRIM_NORMAL, 0, "d7536b1e-5ada-e91d-a830-49296faf84d3", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]); llWhisper(0, name + "Complexity = Digon"); } } } I've included two commands, the first is just listening to the message, the second is my attempt to make it listen for the owners key. Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 (edited) I don't quite understand what you are hoping to do, so let me just make a couple of observations: 1. You are creating a new variable, name, to supercede the variable with the same name that is already part of the information you get when the listen event is triggered. That's probably what you meant to do, and it's OK. It is potentially confusing, though. 2. You appear to be expecting only one specific message: the owner's username plus "1". Then you have set up two if tests, both of which will always execute. The first of them will only be TRUE if the message is that specific message. The second test will only be TRUE if the script has received that specific message AND the UUID of the person who created the scripted object is "59ce94d0-12e5-4f62-987d-b9b78cc74e82". Unless you plan on dropping the script into several different objects created by different people, that UUID is never going to change. Therefore: 3. When you run the script and send it a message: Absolutely nothing will happen unless you send the owner's username plus "1". Then, if you do send that specific message: (a) If the creator's UUID is not "59ce94d0-12e5-4f62-987d-b9b78cc74e82", you will always hear the owner's username plus "Complexity = Henagon" whispered in chat. Otherwise, (b) If the creator's UUID is "59ce94d0-12e5-4f62-987d-b9b78cc74e82", you will always hear the owner's username plus "Complexity = Digon" whispered in chat. (plus the stuff you do in the SLPPF commands, of course). EDIT: Note that if condition (b) is met, you will never hear the owner's username plus "Complexity = Henagon", because the second if condition will immediately supercede the results of the first test. Edited September 2, 2021 by Rolig Loon Additional information 1 Link to comment Share on other sites More sharing options...
Quarrel Kukulcan Posted September 2, 2021 Share Posted September 2, 2021 Well, for one, you're creating a variable "name" that redefines one of listen()'s parameters. I don't know if that's safe. 11 minutes ago, Rolig Loon said: Absolutely nothing will happen unless you send the owner's username plus "1". Then, if you do send that specific message: (a) If the creator's UUID is not "59ce94d0-12e5-4f62-987d-b9b78cc74e82", you will always hear the owner's username plus "Complexity = Henagon" whispered in chat. Otherwise, (b) If the creator's UUID is "59ce94d0-12e5-4f62-987d-b9b78cc74e82", you will always hear the owner's username plus "Complexity = Digon" whispered in chat. Actually, (a) always happens if the message is correct. (b) sometimes also happens. Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 4 minutes ago, Quarrel Kukulcan said: Actually, (a) always happens if the message is correct. (b) sometimes also happens. True. Thank you. My clarifying edit note: 19 minutes ago, Rolig Loon said: EDIT: Note that if condition (b) is met, you will never hear the owner's username plus "Complexity = Henagon", because the second if condition will immediately supercede the results of the first test. is not correct. You will hear both messages, one right after the other. Other than a brief flicker, however, you will never see the effect of the first SLPPF command if (b) occurs. 1 Link to comment Share on other sites More sharing options...
Altier Verwood Posted September 2, 2021 Author Share Posted September 2, 2021 yes you understood the script perfectly Rolig, how ever in my tests, even with the proper command given, the script doesn't seem to do anything, so I have a feeling. this string name = llKey2Name(llGetOwner()); if (msg == name + "1") Can not actually change the message being listened for right ? the message should be /CHANNEL, OWNER_NAME 1 but it doesn't' seem to work. Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 (edited) It ought to work, as long as you are sending the message from an object (like a HUD, maybe). After all, an avatar can't send a message on a negative channel. I assume you have tried inserting llOwnerSay statements at key points to tell you what the script is actually hearing and doing, as opposed to what you think it's doing. Edited September 2, 2021 by Rolig Loon 1 Link to comment Share on other sites More sharing options...
Altier Verwood Posted September 2, 2021 Author Share Posted September 2, 2021 (edited) Yeah, I put those in to test it, but it seems like it's not getting the message, I know an avatar can send - channel messages I do it all the time. my sling command works on -1 I tried it on a positive channel to and go nothing either. Edited September 2, 2021 by Altier Verwood Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 (edited) Here: default { state_entry() { llListen(12,"",NULL_KEY,""); } listen(integer channel, string name, key id, string msg) { string message = llToLower( llKey2Name(llGetOwner() )); if (msg == message + "1") { llSetTexture("0e730d5c-55b3-2d7d-600a-a52b3a32201f", 0); llSetPrimitiveParams([ PRIM_NORMAL, 0, "325f39ee-3eed-a369-b6c7-5a33de6a68de", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]); llWhisper(0, msg + "Complexity = Henagon"); } if (llGetCreator() == (key)"953d10f1-44ce-462a-8bc1-f634333ee031" && msg == message + "1") { llSetTexture("0a28d60f-b12d-df66-9d7c-c83ec3a92dac", 0); llSetPrimitiveParams([ PRIM_NORMAL, 0, "d7536b1e-5ada-e91d-a830-49296faf84d3", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0 ]); llWhisper(0, msg + "Complexity = Digon"); } } } I put my own UUID in as the creator for my test and I'm using a positive channel. Notice that I have cleaned up the confusion caused by having two variables called "name", and that I have forced message to be lower case and have avoided any typecasting error in the assignment of the creator's UUID. All it took was adding a couple of llOwnerSay messages to tell me what the script was actually hearing. Edited September 2, 2021 by Rolig Loon 1 Link to comment Share on other sites More sharing options...
Altier Verwood Posted September 2, 2021 Author Share Posted September 2, 2021 Oh I see it, you added a command I did not have, I've never seen lltolower before, I need to look that one up. thank you so much I will test this out now. Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 (edited) You should actually use llToLower on both the incoming msg and the variable named message, to guarantee that whatever the user types in will be forced to be lower case. I should have done that but was in a hurry. Edited September 2, 2021 by Rolig Loon 1 Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted September 2, 2021 Share Posted September 2, 2021 (edited) I seem a bit confused. The original script does work as-is. Assuming that the channel is -1, if you type "/-1 Firstname Lastname1", the script will set the texture. Maybe there's some detail @Altier Verwood is misunderstanding? For example, if they want to be able to type "/-1 FirstName Lastname 1", the only change needed is a space before the 1: if (msg == name + " 1") P.S. When you redefine a variable, it "hides" the previous one and you no longer have access to it. In this case, the values will be identical so the name variable is totally redundant, it can be removed without breaking the logic. Edited September 2, 2021 by Wulfie Reanimator 2 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 Yes, it does work as is. The reason I made those changes was largely to clear up potential ambiguities and to make the script accept input regardless of whether it was Camel Case (to match what llKey2Name generates) or not. I think that's where @Altier Verwood was getting confused. 1 1 Link to comment Share on other sites More sharing options...
Altier Verwood Posted September 2, 2021 Author Share Posted September 2, 2021 (edited) wait.... I think its a very simple solution isn't it, I type the command as /-CHANNEL altier.verwood 1 am I typing the command wrong? Edited September 2, 2021 by Altier Verwood Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 (edited) Without the dot between altier and verwood. Remember that llKey2Name generates a legacy name, not a username, so it doesn't have a dot. That's why I suggested using llOwnerSay statements to see what the script it actually doing. And, as Wulfie says, don't type a space between your name and the "1". Edited September 2, 2021 by Rolig Loon 1 Link to comment Share on other sites More sharing options...
Rolig Loon Posted September 2, 2021 Share Posted September 2, 2021 The way to avoid making the user figure out all of this is to do as I showed in my edit. Force the string variables to be lower case, regardless of what the user types in. As I I said in responding to Wulfie, your script was fine as is, but potentially confusing (since it obviously confused even the scripter who wrote it ). 1 Link to comment Share on other sites More sharing options...
Altier Verwood Posted September 2, 2021 Author Share Posted September 2, 2021 YES you were right! There was no problem with my script! wow, thank you guys. my script is working perfectly! 2 Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now