Kaluura Boa

You cannot target a specific script with some chat... Well, not easily. What you can easily do on the other hand is to talk on a specific channel and all the scripts listening on this channel will hear if they are within range. In the case of llRegionSayTo(llGetOwner(), ...) on a negative channel, the range is as wide as the distance in between your attachments. That is zero meter since for SL servers, all our attachments are stuffed in our *ss. (Defintively not the technical term.) :smileywink: Some other scripts may hear but there is really nothing you can do about it... except hope that their listener filters out all the unexpected messages or they might do some unexpected things. On the other hand, the listeners can filter what they hear from the beginning and later when they actually receive a message... but that is your work to do.

EDIT: Of course, somebody answered while I was typing... (Grumble) As for your script: The problem is in the llListen(). You cannot use your own key as a filter. It should be the UUID of the HUD... which you cannot guess just like that. Leave it blank. You can use your own key as filter only if the the HUD uses a blue dialog but then the name must be blank or match yours. Previous answer, still valid: That is quite simple. Like for any unlinked prims which want to communicate with eachother: Chat from the commanding script toward the script performing the action. In the case of 2 attachments, just use llRegionSayTo(llGetOwner(), SomeVeryNegativeChannel, SomeMessage); in the commanding script. Despite the name, your script will not shout regionwide but just talk to its owner on a channel they cannot actually hear but which their attachments can. Basic skeleton of an emitter: // Commanding Script//integer SomeVeryNegativeChannel = -12345678;string SomeMessage = "Action!";default{ touch_start(integer num) { key owner = llGetOwner(); if (llDetectedKey(0) != owner) { return; } // Paranoid safety... // llRegionSayTo(owner, SomeVeryNegativeChannel, SomeMessage); }} And of a receiver: // Acting Script//integer SomeVeryNegativeChannel = -12345678;string SomeMessage = "Action!";// string NameOfTheHUD = "Commander"; // See herebelow.default{ touch_start(integer num) { llListen(SomeVeryNegativeChannel, "", "", ""); // To narrow the listener range, you can filter on the name of the HUD // ***** That is what you need. ***** // llListen(SomeVeryNegativeChannel, NameOfTheHUD, "", ""); // Or on the chat string... If you expect only one string. // llListen(SomeVeryNegativeChannel, "", "", SomeMessage); // Or both. // llListen(SomeVeryNegativeChannel, NameOfTheHUD, "", SomeMessage); // Do not bother about the UUID, it is a complicate story. } listen(integer channel, string name, key id, string msg) { if (llGetOwnerKey(id) != llGetOwner()) { return; } // Accept only chat from your own objects. // (Alas, you cannot filter out everything which is not an attachment.) // if (msg == SomeMessage) // Necessary if the llListen() has no filter. { // Action! llOwnerSay("Message received:" + msg); // DEBUG } }} That's all. Not tested in-world but I'm confident... :smileywink:

It looks like you resized things in Object mode but did not apply the changes. You must trust no-one... Especially not the 2 "people" in between your mesh and SL: the exporter and the uploader. To be (more or less) sure of the result, you must chew the food for them and that means to give them pure geometry that requires no fancy calculation. It makes their head hurt. :smileywink: Just use CTRL+A in Object mode to apply everything: size, position and rotation. (PS: I hate it when somebody answers while I'm typing.)

You don't need a list. The inventory is already a list. Here is a very short script for an object to give its inventory one item at a time until it's empty. (I suppose your ribbons are objects.) default{ touch_end(integer num) { key av = llDetectedKey(0); // First toucher string item = llGetInventoryName(INVENTORY_OBJECT, 0); // First object if (item != "") // Still one item left at least... { llGiveInventory(av, item); // Give it. } else // ...otherwise, complain. { llRegionSayTo(av, 0, "Sorry, the box is empty."); } }} Simple, isn't it? (Although I typed it directly into the popup window to paste scripts, I'm confident it will compile.)

Sorry for being your wet blanket for today but... No. Just no. That is simply not possible. Scripts cannot access your avatar's inventory. Period. One complicate way to achieve this would be to use a scripted agent, i.e. a bot, with a specialized interface. Still, that would be several levels of complexity above your simple idea. If LL would allow script to access your avatar's inventory, either directly (My personal dream) or indirectly through the web (The dream of a lot of people), then we, scripters, could start to have some fun. You can always write a letter to Santa... errr... I meant a Jira. Just do not hold your breath. LL has its plate full with big things already, like Pathfinding, Experiences Tools (i.e. gamification), Mesh Deformer, and what-not. Nothing will happen this year. Next year, we shall start talking about security issues related to scripted access to one avatar's inventory. And the year after that, we'll see... Very good idea. Very unlikely to happen in any foreseeable future, alas.

There is no function in LSL to obtain an avatar's key with only their display name. It is however not needed. When an avatar pays, the scripts also receives the key of this avatar. Then it can use this key in the function llGetDisplayName(). That is all you need to do to handle display names. Once the money received, you can simply set the price to zero. But the nicest way is to switch to another state where there is no money() event. This way nobody can pay at all. All the script has to do is to wait for a signal telling it to accept money again. (You did not talk about this part.) As for the profile picture, there are plenty of scripts for this everywhere. For example: here. By the way, this is almost all that you need to do once you have the avatar's key.

Your question is not very clear. I think I understood something but I may be wrong. Any way, here is my answer about passing variables to a script through gesture. First, the gesture: You need a gesture which replaces the trigger by a channel number. For example: "/trigger" replaced by "/11223344[_]". (Where "[_]" represents a blank space.) Your avatar cannot speak on a negative channel but you can speak on a very high positive channel. It's the same thing. Then, the script: Nothing complicate, a simple listener for the owner on the channel you set in the gesture. (Here, 11223344.) Your script will hear everything you type beyond the trigger. For example, if you type "/trigger param1 param2", your script will hear "param1 param2" on channel 11223344. You use llParseString2List() and you get all your variables nealty put into a list. You can go a little further and use several gestures which talk on the same channel but insert a keyword so that your script can sort things out. For example: "/triggerone" replaced by "/11223344[_]one[_]" and "/triggertwo" replaced by "/11223344[_]two[_]". The listener script will hear "one" or "two" followed by everything you type beyond the trigger. But there is no special syntax to respect. It's up to you to decide what and how you want to receive the variables... and to check them. For example, amongst the scripted gestures I use, I have "/chat" which is replaced by "/11223344 chat,[_]" (Not the real channel) and the variables I am supposed to give are range, channel, name, text. So I can speak to my objects on any channel, including the negative ones, through any means from llWhisper() to llRegionSay(), using an appropriate name if necessary. The same script commands my titler through another gesture and I have a bunch of gestures which send predefined texts to it like an orange "AFK" which appears when I say "brb" or "afk" and disappears when I say "back", etc, etc. The sky is the limit... but you have to script it.

Altho it is not totally impossible to do it by hand --with a lot of determination and a TPV which can put the axis of rotation on a prim instead of in the middle of nowhere-- a script will do it within minutes instead of hours... so, it is more likely that a faceted dome is a scripted build. I wrote such a script a long time ago. It is a simple problem of topology which does not even require a lot of mathematics.

EDIT: Altho my first snippet was correct, I prefer Dora's symetrical beauty in her code. I just added what she forgot. The modulus operator allows you to simplify your calculations a bit. integer secs = remaining % 60; integer mins = (remaining / 60) % 60;integer hours = ((remaining / 3600) % 3600) % 24;integer days = remaining / 86400; 2 days, 2 hours if my calculator is correct... That's all.

Now, I know what I did differently from previously: I created a new object in the scene instead of simply modifying my model to create a lower LOD. So I have another workaround which is one step before editing the Collada file by hand: Have all your LODs in a single object. You can work in several objects and merge them. (Just do not forget to put them on a line if you do no want to have a massive mess of vertices in one place and keep an eye on the material list if you merge from files.) You re-load this multi-LOD file to save each LOD in deleting all the vertices of the other LODs. You can do the UV mapping before or after merging, or even in each separately saved LOD file, it does not matter. ...And the uploader is happy. Its food is already fully chewed. Still, it remains that either the Blender exporter or SL importer must be patched. I guess that the Blender's side of the things will happen in less time than LL need to mark a Jira as "Won't finish".

I now have 3 holes in my screen through which ones I can see the wall... Seriously, I am overfed up with this error. "The material of the model is not a subset blah blah blah". I have been fighting for hours with the uploader which is apparently more stubborn than me... I made a low LOD version of my model as a second object in the scene of the original object (which I deleted before to save and export). The materials are all the same, all present, all used. There are 8 of them, not too many. There are no loose vertex or face without material anywhere. The materials are the same since I simply re-used the ones from the original model. And still, the uploader always spits the same error. I tried everything, down to merging the low LOD model into the original scene, re-applying all the materials one by one and cleaning up the list with the Outliner. Save, quit, load, verify, save. Total failure! I cannot think of anything I overlooked. Do you? All this, using Blender 2.63 and LL's viewer 3.3.0 and 3.3.1. (The latter reported the same error for files that I already uploaded weeks ago so I tried an older version...) The only way to make the uploader accept my files was to edit the Collada files by hand and to replace everything that was material related in the low LOD file with the same thing from the high LOD file. (The difference was a matter of order of the materials and the resulting different numbering later in the file.) This is not a practical solution... Any idea? The old trick of the cactus on top of the screen did not turn well with my flat screen... :smileywink:

First, I would say that it is unlikely that your model is optimized enough for SL. Basically, models for SL must be optimized like for a game... And it is most probable that your friend made his model to look nice on screen. Still, you can test the upload process with this model. Start a recent Blender (for the updated Collada export) and export the default cube as Collada file for later. Next, load your model and export it as Collada too. (You only need the File menu to do this.) In SL viewer, upload from the tiny icon in the inventory floater or from the Build menu. Use the cube as physics shape. (See: Physics tab.) Once loaded, click "Analyze" and the uploader will tell you "1 hull, 8 vertices" at the bottom of the tab. (That is all. No need to simplify a cube.) If no error occured you should then be able to click "Calculate weight & fees"... and scream! (It is very likely that Land Impact is of nuclear type.) :smileywink: That is really the whole process to upload into SL. What can be wrong is that the model is a high-poly one, hence the nuclar land impact. For an attachment, it is not necessary to optimize your model down to a Land Impact of 1 but you should not go crazy with vertices and triangles either. The number of material (texturables faces in SL's linguo) may be over 8. The model may use huge textures. Anything beyond 1024x1024 is a problem for SL and textures add to the price since you have to upload them too. The model texturing may use visual tricks that cannot be imported. All we can do in SL is use a texture, add some shiny, set the transparency and eventually colorize. Bump mapping is limited to SL's default bump maps which are... well, limited. (The list of features that cannot go from Blender into SL is very long.) Any way, if the land impact is not apocalyptic (and beyond), you can always test to import the model on Aditi. IMHO, it is very likely that your model can be used... as a model to make a new simpler one. :matte-motes-sunglasses-1:

Hmmm... I have no explantion about the weird behavior but there is one thing I know for sure (...so far) and that is that the numbers of triangles and vertices are always correct in the uploader. If you "triangulate" your mesh in Blender (CTRL+T), the numbers of faces and edges appear respectively as triangles and "vertices" in the uploader. If the numbers are not correct, it means that the uploader does not like your file and you should not go on as some of the most "interesting hidden features" are to be expected... if you see what I mean.

You are not the only one to be confused by the uploader. From what I observed through various experiments, lowering the number of triangles of the lowest LOD has an enornous impact... I would even say "insane"! To have some numbers to put in this post, I fed the uploader with a high-poly model and played with the triangle limits for the various LODs. The model is 13376 triangles and the uploader "proposes" me LODs of 3344, 836 and 419 triangles, for a download (DL) of 44.7. If I double the medium and low LODs to 6687 and 3343 triangles, the DL barely climbs to 50.9. If I double the lowest LOD too to 836, the DL doubles too: 86.5. If, on the contrary, I divide the lowest LOD by 2 at 213, while keeping the higher numbers for medium and low LODs, the DL looses roughly 1/4 at 31.8. And, in the end, if there is a formula behind these numbers, it makes no sense to me. My wild guess is that to increase the number of triangles in medium and low LODs has a moderate impact on the final numbers but it is best to stick to whatever number the uploader "proposes" for the lowest LOD. Any way, since yesterday, I decided that I refuse to even try to understand the uploader. I moved 4 triangles... Just that! Somewhere in the file, the definitions of the triangles changed to use some other already existing vertices... and the land impact was divided by 2! So... YMMV and YGIAGAM...

Unfortunately, yes, it will. When land is deeded to a group, you are not really the owner any more, the group is --at least, as far as the permissions system is concerned-- and anything with the wrong group or no group at all will be subject to autoreturn. But there is a quick solution: Set the right group to everything on your land. Depending on the size of your land, you can select everything or do it part by part and just set the group for the whole at once. (Use both "Select by surrounding" and "Select only my objects".) Edit: Ron and I posted at the same time apparently... And he is right to remind you: Do not touch the "Deed" button!