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!

There is a simple way to see things... Before: Up to 10m == prim, beyond 10m == megaprim. After: Up to 64m == prim, beyond 64m = megaprim. So, now, prims snap back to 64m. You should have no problem to resize any prim of which no dimension exceeds 64m, even if it was called "megaprim" when the limit was only 10m. But you must look at the real dimensions of these "formerly-known-as-megaprims". Some very old megaprims from the first wave are cut and/or sliced to appear smaller. This is not the case for the megaprims of the second wave.

Hmmm... The question was not answered. I am resurrecting this almost necropost. There is no such thing as llGetHeadRotation() because animations are purely client side. As far as SL's servers know, we are moving around in T-pose. Besides, since you cannot see your avatar in mouselook, animations are pointless and actually kinda ridiculous for an external observer. However, yes, something is moving in mouselook and that is your camera so... llGetCameraRot() (I added a link to llGetCameraRot() on the llForceMouselook() wiki page in the "See also" block. A full wiki page on mouselook is sorely missing tho...)

Everything is here: SCR-163

(Sorry, it's almost early morning and I'm always grumpy before my coffee kicks in...) :smileywink: Hmmm... There is a lot to say about this script. First, some basic knowledge: Events in LSL are atomic, meaning that they cannot be interrupted. If another event, like on_rez() happens while your script is in an infinite loop, the event is queued until your script exits the current event. So... It never happens if your script stays forever in state_entry(). From there, the script never reads the current position as it is supposed to do with llGetPos() but keeps using the one it has in memory, i.e. the one from the first time it ran. Next, LSL never ignores anything you tell it to do. If the on_rez() could interrupt your infinite loop, it would not matter. Your attempt to reset cpos forcibly at the beginning of the script would simply fail. It is a matter of scope. Anything declared before the default state is global. Anything declared inside an event is local to this event. In your script, you have a global vector cpos and a local vector cpos in state_entry(). They happen to share the same name and the same type but that is all. Guess which one gets used? LSL always tries to find what it needs amongst "the locals", then it looks "beyond the border" where the global variables live, and eventually it complains that it found nothing to satisfy its needs. As to your loop, it is really infinite and even unbreakable. You can insert a hundred times msg = "OFF"; and you will find yourself saying that LSL ignores what you tell it to do. The equal sign is the symbol of assignation. The comparison distinguishes itself with a double equal sign. LSL logic says that an assignation is always true so your infinite loop works (also because the compiler does not complain) and the value "ON" is assigned to msg every time the loop restarts. So... To make a breakable infinite loop (Hello, oxymoron!), it must be interruptible from a LSL point of view. Using a timer is the most straightforward solution. (No, no, no! Timers are not pure evil only.) So you can control the timer through chat or touch, or else.

There is no absolute number. It all depends on the diameter of the cylinder. For a very thin cylinder, 4, 5 vertices can do the trick. then you increase the number of vertices with the diameter, keeping in mind that prim cylinders use 32 vertices. You should never go beyond this number unless it is a huge cylinder. Any way, the uploader will stop you with a Land Impact blinking in red and blue. :smileywink: Very important: Just do not forget to set your faces to smooth or you can add as many vertices as you want, it will still stay blocky. (In Blender: W key then "Shade Smooth" or "Set Smooth" in Blender 2.49.)

Quite simple: Select your face and split it! Press the Y key, confirm and that's it. It works with a single face or several and the same with vertices. However, I hope that you are not talking about sculpties. They don't like you to mess with their mesh. In general, the export script will complain and you'll just have to put all your work into the trashcan. But for a "real" mesh, splitting is just business as usual. Just for the information: W key >> Remove doubles. (The label should actually be "Merge by proximity" or something.) If you don't explicitely recreate bridges in between your islands of vertices, just bring vertices from two islands together, select them and use this feature to make them one again. Once again, not a feature to use with sculpties... Sculpties are very strict with faces and vertices counts.

Work on a platform at 4000 meters high. If nobody sees you, nobody can be offended by a bit of bare skin or what-not. :smileywink: I do not think there is even one adult region on Aditi...

I stand corrected. Warp can fail on return only because the prim is not a vehicle (i.e. a sitted object) any more and is subject to the rules applying to regular objects instead of the ones applying to avatars. We still need to see the script... or we are like shooting darts in the dark.

Alright. I did not succeed in making it work with the root and I find it still too slow altho I managed to make it very minimalist... but it works! integer GrabbedLink;vector CurrentPos;default{ state_entry() { } touch_start(integer numb) { GrabbedLink = llDetectedLinkNumber(0); GrabbedLink *= (GrabbedLink != 1); // Ignore the root. // Equivalent to: if (GrabbedLink == 1) { GrabbedLink = 0; } // Working on link number 0 silently fails in linksets. CurrentPos = llDetectedTouchPos(0); } touch(integer num) { vector new_pos = llDetectedTouchPos(0); if (new_pos) // != ZERO_VECTOR then held cursor is (still) within the prim area. { // Let's move... or not. We don't check for speed reasons. CurrentPos = llList2Vector(llGetLinkPrimitiveParams(GrabbedLink, [PRIM_POS_LOCAL]), 0) + (new_pos - CurrentPos); llSetLinkPrimitiveParamsFast(GrabbedLink, [PRIM_POS_LOCAL, CurrentPos]); } }} If you use it on cubes, you can move them in 3D depending on the face where you click and how you move your mouse cursor... in a way that kind of makes sense... to me. :smileywink:

Does this prim TP use Warp, PosJump or llSetRegionPos()? Warp and llSetRegionPos() should not fail. The only known reason for a sudden fail of PosJump is well documented: No-entry flag set on parcel at <0, 0, 0>... but it should affect all the prim TP's in the region. So... I cannot say much more without seeing the script. My take on prim TP's is that it is better to make them one-way. Prims turn to temp and jump away, they die when the avatar unsits and another fresh one is rezzed as soon as the first one is far enough. It divides the possible causes of failure by 2.