Wampster

I completely agree with you. And, I might try to find a more meaningful way to distinguish the bowls to the user at a later date. For now, I'll consider what I have as "working" and get other systems working around it. Of course, everything will need "polish" once the initial systems are built.

To thank everyone for their input, I thought that I would show you the resultant, working code. With all of the input that I received in this thread, I was able to look at the problem from a new perspective which allowed me to acheive the desired goal. We can't parse more than one thing through a llDialog() but we sure can use a conglomeration of ideas from several of you. Pre-fix button labels with an identifying numeral. Build a concurrent list for storing UUID's whilst building the button list. Use an integer to index both lists. The Food can: listen(integer channel, string name, key id, string message) { if(channel == menuChannel) { if(message == "Find a bowl") { llListenRemove(menuListener); bowlListener = llListen(bowlChannel, "", NULL_KEY, ""); llSay(bowlChannel, "BowlPing"); } } if(channel == bowlChannel) { if(message == "BowlPong") { integer bowlNumber = bowlCount + 1; // Because the first bowl would be zero'th index. list listObjectNames = llGetObjectDetails(id, ([OBJECT_NAME])); string objectName = llList2String(listObjectNames, 0); string objectUUID = (string)id; bowlLabels += (string)bowlNumber + ". " + objectName; bowlUUIDs += objectUUID; bowlCount += 1; SelectBowlMenu(); } } if(channel == selectedBowlChannel) { llListenRemove(selectedBowlListener); integer selectedBowlNumber = (integer)message; selectedBowlNumber -= 1; // Because we adjusted for the zero'th index. string sendFood = llList2String(bowlUUIDs, selectedBowlNumber) + "|" + (string)foodContent; llSay(sendFoodChannel, sendFood); } } The bowl selection dialog. The food bowl: listen(integer channel, string name, key id, string message) { if(channel == listenChannel) { llListenRemove(canListener); if(message == "BowlPing") // Food can { foodListener = llListen(receiveChannel, "", NULL_KEY, ""); llSay(listenChannel, "BowlPong"); } if(message == "Bowl Pos") // Hungry cat { if(foodContent > 0) { llSay(listenChannel, (string)llGetPos()); canListener = llListen(listenChannel, "", NULL_KEY, ""); } } } if(channel == receiveChannel) // Bowl selected and food sent { llListenRemove(foodListener); list data = llParseString2List(message, ["|"], [" "]); string newUUID = llList2String(data, 0); string foodAmount = llList2String(data, 1); if( newUUID == myUUID) { foodContent += (integer)foodAmount; UpdateFoodContent(); } canListener = llListen(listenChannel, "", NULL_KEY, ""); } } Food can, bowls and cat. I couldn't completely dodge substrings but certainly kept it to a minimum. And, of course, the "messages" used to transmit information will be changed to more suitably discreet codes later. These are merely preliminary ones to get the overall systems working. As it stands now, I can click on the food can, tell it to find bowls, select one of the discovered bowls and then send the food to that selected bowl. Granted, I don't 'intend' for someone to have a bunch of bowls laying around. Nonetheless, I felt it necessary to handle the istuation which is probably inevitable. I still have a lot more work to do but the purpose of my original question is solved. Thank you to everyone who responded.

First of all, thank you all for your kind, thoughtful responses. You've all given me a lot of ideas and insight in to how others see the problem. I truly appreciate the time and effort. In the example, we're supposing that the object is a pet food bowl. Changing the name (whilst not impossible) is not ideal. Since, we would be expecting that a vendor would be selling duplicates of a "prefab" object. Thus every instance of the object are identical, including the name. The only thing unique to each instance would be the UUID, which itself changes each time that the object rezzes. Of course, we can cache that UUID in the on_rez() callback. The second thing that we're supposing is that the owner intentionally or unintentionally rezzes more than one bowl. Thus we want to handle not just the 'first' bowl to respond but multiple bowls which may respond. I hadn't thought about this angle, honestly. I think that you're right. It is better to do any processing within the same script and only parse results to the bowl which leads us to the next ideas. I agree that appending a pre-fix integer to the button name is a great solution. It looks clean and presentable to the user, having the buttons numbered, but, also, gives us a unique string to deal with. Two birds with one stone almost. This is what popped in my mind, from the previous comment. Well, for the most part. I love the simplicity of pre-fixed numerical labels. Perfect to build a second list containing UUID's with matching index to the pre-fixed numerical labels in the first list. This is very insightful. I literally did not know what the "string name" held, nor if we could use it. An example of why I pondered if we could parse our own data through this argument can be found in llMessageLinked(). In llMessageLinked(), I parse my own "integer num" through, along with "message". This allows me to control two different levels of data tranmission within the same object. One level being the integer, which that value might be used for pathfinding only. And then the next level, which pathfinding function to access. I did try to quote Molly, here, regarding the very interesting and expanded substring approach to padded labels. I guess I hit my quote limit or something. The idea is very interesting but I am not particularly confident with substrings (in any language). More of a failing on my behalf than anything to do with substrings. I can usually fumble through such cases but feel lost & confused the entire time and out of my depth. About the only time that I've ever felt cornered in to using substrings with delimiters was when I was working on a login manager for a game and wanted the character and account stats sent to the game manager from SQL. Otherwise, I typically find ways to avoid substrings! Again, nothing against substrings, just my inability to process them in my head! I think for my skill level and comprehension the best suggestions that would work for me are pre-fixed numerical button names to clearly distinguish one from another with matching indexes built in a second list to reference UUIDs. As each message comes in, you can add each to both lists ensuring matching indexes. The llDialog() response can therefor match a UUID. Thank you all so much for taking the time and effort to give me your thoughts and opinions.

I am redesigning an old system that I made a year or two ago. A "food can" and "food bowl". But, the same principle could be applied to many different things. The goal being to move data from one object to another. Now, on the surface, moving a typed integer ( (string)myInteger ) to denote a quantity from one object to another is straight forward. In this example, moving a quantity of 'food' (integer) from a 'food can' to a 'food bowl'; By simply parsing the typed string through a chat channel and listening on the receiver. What if there's multiple receivers? Ahh, now, we'll need to build a list of objects that responded to the first "call" and our sender "listening" to each object that responds. That's fine. Each returning message contains the UUID of the object that sent a response. So, we can build the list of button names from those. Let's say that we build the button list by returning the object name of each respondant, such as "Food Bowl". The owner, for whatever reason, may have rezzed two or more bowls. Fine. The list contains two (or more) buttons labeled "Food Bowl". This is where we're presented with the dilemna. When the user clicks on either button, the only thing that we know is that it was a "Food Bowl". Sure, instead of the object name, we could parse the UUID to the button list. But, then, it wouldn't give a meaningful label to the owner. Ideally, when we build the button list to parse through the llDialog(), we want to track which "label" (the string parsed to each button and presented to the user) has which UUID associated to it. I know of no way that we can know two things about any message returned by the llDialog(). Am I simply missing something obvious? Or is this truly a bottleneck in the system. In which case, how can we overcome it? I know that others have overcome this issue. But, I draw a blank on how they may have handled it. key userKey; integer menuChannel = -654321; integer menuListener; integer bowlListener; list mainMenuButton = ["Find bowl:"]; string mainMenuMessage = ""; default { touch_start(integer num_detected) { userKey = llDetectedKey(0); menuListener = llListen(menuChannel, "", userKey, ""); llDialog(userKey, mainMenuMessage, mainMenuButton, menuChannel); } listen(integer menuChannel, string name, key id, string message) { if(message == "Find Bowl") { llListenRemove(menuListener); bowlListener = llListen(menuChannel, "", NULL_KEY, ""); llSay(menuChannel, "Food bowl"); } if(message == "Food Can") { llListenRemove(bowlListener); //list buttonList = []; Would reset the list after each message received (one bowl listed). buttonlist = llGetObjectDetails(id, [OBJECT_OWNER]); list textMenuButtons += [llKey2Name(llList2Key(buttonList, 0))]; string textMenuMessage = "Please select a bowl:"; llDialog(userKey, textMenuMessage, textMenuButtons, menuChannel); // Can we somehow send more than one piece of information in the button? // As far as I can tell, we can 'only' send a label (string to be displayed on each button). // How then can we distinguish between multiple, identicle objects (multiple food bowls)? } if(message != "Find Bowl" & message != "Food Can") { llListenRemove(bowlListener); llSay(menuChannel, message); //We can't exactly concatonate UUID + message, since the button label would // be illegible to the owner. // Therefor, we can't have a string to attempt to split at the other end. // It would seem that the llDialog() button label is a bottleneck. } } } Screen capture of Visual Studio Code with LSL Intellisense. How, in the listen() event, can we recieve both the UUID and the button label? integer myChannel = -654321; integer foodListener; default { state_entry() { foodListener = llListen(menuChannel, "", NULL_KEY, ""); } listen(integer channel, string name, key id, string message) { string myUUID = (string)llGetKey(); if(channel == myChannel) { if (message == "Food Bowl") { if (name == myUUID) { // Can we parse the UUID of the label's originating object through here, as name? // If so, how do we 'send' it? } } } } } Screen capture of Visual Studio Code with LSL Intellisense. The previous code snippets are not compiled, tested code. I literally wrote it just now as examples to attempt to clarify where my mind is at and attempt to pinpoint the bottleneck that I see (rightfully or wrongfully) regarding llDialog(). My apologies for any errors that may be associated with it which may make it more difficult to understand the overall dilemna posed. Any insight and discussion is welcomed.

I reread the wiki again. It would seem that we have to use a standard avatar skeleton, then 'adapt' it to suit the model in question.

I got passed the hip only to come undone on the next bone. Are Linden sure they really set this up to animate non-human meshes? On their wiki for Animesh, there's no details on this subject of uploading non humanoid skeletons. Edit: The lack of information regarding specifics for non humanoid meshes on the wiki lead me to believe that it would work with any skeleton, so long as the mesh and animation matched. It's starting to look like a dead end.

I am trying to get the Animesh system running. I never did upload animations for avatars. I have a frog model and am trying to get the idle animation running, to begin with. I have exported my mesh animations as *.bhv from Blender and after getting this error, I even changed the root bone to "hip" to appease Second Life. Is anyone familiar with this particular error?

I went through the video multiple times. It's not helping my situation. I'm open to uploading the model in sections. I even expected to do so when I first started out. The only reason that I haven't done it already is because I hadn't thought about how to align the pieces precisely after I rez them. In fact, the house is already in sections. In Blender, the house is made of 28 objects thus far. I've tried uploading the cube system and the plane system. I don't seem to be having any success. I'm confident that I understand the principles involved as I have a lot of experience working with physics engines (outside of Second Life), modeling and related tasks. I just seem to be missing something crucial and probably obvious.

Thank you. I'll watch it now.

I am working on a custom house that I have been developing in Blender. Right now, I am working on the floors. At first, I created convex boxes (with spaces between to avoid touching). I could not get the physics to work in the test server. On this attempt, I have reduced the convex boxes to simple planes. The physics still don't work. Physics planes Also, the planes are not positioned in the upload screen where they are in Blender. Not only do the yellow sections protrude out the front of the building but they are also not aligned vertically with the floors of the building. Upload window Does anyone know what I am missing or not understanding, in regards to Second Life physics? I would appreciate any and all input.