Kaluura Boa

EDIT: What I wrote about the need of a TPV was a bit misleading. Corrections will follow. @Chosen: I kinda agree with you. I look like a leech... Which I am not. My partner will kill me but, so be it! First thing to do: Ditch any recent or old official viewer from LL for a moment, since none of them have import/export features. You need a multi-grid TPV, like Imprudence, for example, to import once. However, all viewers AFAIK can correctly see multi-faces sculpties. 1 Export a scuptie (Anything!) 2 Export a hollow torus 3 Open both XML files in a text editor 4 From the sculptie XML file, copy the block: <key>sculpt</key> <map> <key>texture</key> <uuid>SOME_KEY_HERE</uuid> <key>type</key> <integer>3</integer> </map> 5 Paste it into the torus XML file, just after the block: <key>scale</key> <array> <real>NUMBER</real> <real>NUMBER</real> <real>NUMBER</real> </array> (In other words, on the same line than where you copied from.) 6 Save, import the modified torus... After that, it's up to you to sculpt in order to take advantage of this new object which is just a regular sculptie... but with 2 faces. You will be disappointed because the 2 textures are not set to cover exactly the 2 halves of the sculptie, there is a little hole in between, some loss of definition occurs in the sculptie, and stitching does not always give the expected result. It works with other prims too. You can cut them, twist them, whatever. It changes the number of faces but also introduces varying losses of definition in the sculptie and changes in the layout of the textures. And that is pretty much all that I know for the moment.

What Qwalyphi said was enough for me. You don't want me to ruin the fun of the discovery for everybody, do you? Export, look and you'll find. It's really damn easy. The modification of the file to import requires no more than 2 keyboard shortcuts. Seriously! But be prepared to be a bit desappointed... It just adds new constraints in the straightjacket of the sculpties.

Thanks a lot! That was the push in the right direction I needed. I made sculpties with up to 6 faces so far... and I'm happy!

To make things clear, if you feel the need to talk about meshes, do it in another thread, I can do multi-face meshes already, I want to talk about sculpties, this feature unique to SL and compatible grids. So... Multi-face sculpties, i.e. sculpties to which you can apply more than one texture are possible in SL.They are not tricks with a special texture composed of several smaller ones. They are real. So far, I've only seen (and bought) 2-face sculpties and, as well the building tools as a script recognize the 2 faces which can be colored and textured separately so you can have, for example, one part shiny and another part semi-transparent. The big question is: How is it made? And more important: Is there somebody who is willing to share that knowledge? The creator of the multi-face sculpties I bought is willing to auction this info. Bids start at 1 million of L$... Google led me to a drama thread on SLU forums in the middle of which one person said he will share this info but I gave up digging in the mud of this thread very soon. And that's pretty much all I found. My attempts in-world led to nothing and, since, I learned that it is apparently not the way to do it. So I am asking: Is there somebody who wants to enlighten me? To make things clear again, this knowledge will be used to do something, not to brag in the forums (The number of my posts speaks for itself.) and it would not even be necessary to ask me not to spread this info. Of course, since there is such a high level of mystery and secret around this, you can contact me directly in-world.

Hmmm... I was obviously a little too much in a hurry when I replied earlier. You can keep that line in every listen() event... BUT, in the main script, it must go in the block which deals with objects communications ONLY. else if (channel == REZ_CHAN) { if (llGetOwnerKey(id) != llGetOwner()) { return; } // // Keep the rest... // }  Otherwise, the dialog will work for anybody but the script wil not hear anything except from the owner. For the object to object communications, object A and C, even transferred to somebody else, will always have the same owner so my little safety line prevents any chat from other people's objects from interfering. And the "circular paranoid safety" checks make sure that the chat --which succeeds to go through-- is valid.

Actually, Object C sends a list with the key of the toucher and its position, the whole converted to a string with llList2CSV(). Object A sends the key of the user of the dialog. So Object C knows to whose touch it must react. When the right av touches Object C, it sends back the av key and its pos... and Object A verifies that the key matches the one of the user of the dialog before to rez. Let's call this "circular paranoid security"... As for extending my skeleton of script, you can remove the names from the llListen() calls so that they do not matter any more. In that case, --and in all other cases too-- I would add the usual line at the beginning of every listen() event: if (llDetectedKey(id) != llGetOwner()) { return; }// Accept chat only from owner or their objects It is very unlikely that a lot of people will chat on your very negative channel so filtering by name or not will not make a big difference as far as lag is concerned.

Almost a one-liner... default{ state_entry() { llListen(8, "", llGetOwner(), ""); // Listen to owner on channel 8 } listen(integer channel, string name, key id, string msg) { llSetText(msg, <1.0, 1.0, 1.0>, 1.0); }}

Stupid but mathematical idea: C = llVecNorm(A % B) * llVecMag(B); I'm not sure about the precision that will be preserved tho...

A bit tortuous but doable... Script in object A: interger REZ_CHAN = -99887766;integer DIAL_CHAN = -66778899;integer Handle;key Avatar;default{ state_entry() { llListen(REZ_CHAN, "Object C", NULL_KEY, ""); // <<<<< Object C's name } touch_end(integer num) { Avatar = llDetectedKey(0); llSay(REZ_CHAN, (string)Avatar); Handle = llListen(DIAL_CHAN, "", NULL_KEY, ""); llSetTimerEvent(60.0); // 1 minute timeout. llDialog(av, "\nClick an object C to rez a nice B!", ["OK"], DIAL_CHAN); } listen(integer channel, string name, key id, string msg) { if (channel == DIAL_CHAN) { llSetTimerEvent(0.0); llListenRemove(Handle); // // Dialog handling goes here. } else if (channel == REZ_CHAN) { list tempo = llCSV2List(msg) key av = (key)llList2String(tempo, 0); if (av == Avatar) { vector pos = (vector)llList2String(tempo, 1); if (pos != ZERO_VECTOR) { llRezObject("Object B", pos + <0.0, 0.0, 0.5>, /* Offset here! */ ZERO_VECTOR, ZERO_ROTATION, 42); llSay(REZ_CHAN, "Finished"); // Invalid key for object C } } } } timer() { llSetTimerEvent(0.0); llListenRemove(Handle); llRegionSayTo(Avatar, 0, "/me -- Time out! Dialog disabled."); llSay(REZ_CHAN, "Finished"); // Invalid key for object C }} Script in all objects C: interger REZ_CHAN = -99887766;key Expected;default{ state_entry() { llListen(REZ_CHAN, "Object A", NULL_KEY, ""); // <<<<< Object A's name } touch_end(integer num) { if (llDetectedKey(0) == Expected) { llSay(REZ_CHAN, llList2CSV([Expected, llGetPos()])); } } listen(integer channel, string name, key id, string msg) { Expected = (key)msg; }} If there aren't too many typos, it should compile... If it works is another question... Altho I'm confident.

To switch the visibility of 2 sets of prims using llSetLinkPrimitiveParamsFast() and PRIM_LINK_TARGET for maximum speed. For example: Folded vs. extended wings. Easily extensible for more than 2 sets. Only caveat: All the prims are assumed to have only one color each because llSLPPF() doesn't allow you to set only transparency without also setting the color. (Vote for Jira SCR-4!) integer FirstOne; list ShowFirstSet; list HideFirstSet; integer SecondOne; list ShowSecondSet; list HideSecondSet; integer theSWITCH; uuSetPrims(integer switch) { theSWITCH = switch; // Don't forget this! if (switch) { // Show second set and hide first set. llSetLinkPrimitiveParamsFast(SecondOne, ShowSecondSet + [PRIM_LINK_TARGET, FirstOne] + HideFirstSet); } else { // Show first set and hide second set. llSetLinkPrimitiveParamsFast(FirstOne, ShowFirstSet + [PRIM_LINK_TARGET, SecondOne] + HideSecondSet); } } default { on_rez(integer param) { llResetScript(); } state_entry() { integer i = llGetNumberOfPrims(); for (; i > 0; --i) // Checking all the prims, including the root. { string name = llGetLinkName(i); if (name == "first") // Name of the prims in the first set { if (ShowFirstSet != []) // Params list for first set not empty { // We need PRIM_LINK_TARGET... ShowFirstSet += [PRIM_LINK_TARGET, i]; HideFirstSet += [PRIM_LINK_TARGET, i]; } else { // ...otherwise not. FirstOne = i; // Store that link number. } // Primitive params are needed in all cases. vector color = llList2Vector(llGetLinkPrimitiveParams(i, [PRIM_COLOR, 0]), 0); ShowFirstSet += [PRIM_COLOR, ALL_SIDES, color, 1.0]; HideFirstSet += [PRIM_COLOR, ALL_SIDES, color, 0.0]; } else if (name == "second") // Name of the prims in the second set { if (ShowSecondSet != []) // Params list for second set not empty { // We need PRIM_LINK_TARGET... ShowSecondSet += [PRIM_LINK_TARGET, i]; HideSecondSet += [PRIM_LINK_TARGET, i]; } else { // ...otherwise not. SecondOne = i; // Store that link number. } // Primitive params are needed in all cases. vector color = llList2Vector(llGetLinkPrimitiveParams(i, [PRIM_COLOR, 0]), 0); ShowSecondSet += [PRIM_COLOR, ALL_SIDES, color, 1.0]; HideSecondSet += [PRIM_COLOR, ALL_SIDES, color, 0.0]; } } uuSetPrims(FALSE); // Set and use the switch. } touch_end(integer num) { if (llDetectedKey(0) != llGetOwner()) { return; } // Owner only! // uuSetPrims(!theSWITCH); // Invert and use the switch. } }

(Edit: I added the possibility to have colored prims.) Here is something else... Only caveat is that the prims must have only one color each. integer FirstToe; list ShowToes; list HideToes; integer FirstFlyToe; list ShowFlyToes; list HideFlyToes; integer theSWITCH; uuSetToes(integer switch) { theSWITCH = switch; // Don't forget this! if (switch) { // Show fly toes and hide regular toes. llSetLinkPrimitiveParamsFast(FirstFlyToe, ShowFlyToes + [PRIM_LINK_TARGET, FirstToe] + HideToes); } else { // Show regular toes and hide fly toes. llSetLinkPrimitiveParamsFast(FirstToe, ShowToes + [PRIM_LINK_TARGET, FirstFlyToe] + HideFlyToes); } } default { on_rez(integer param) { llResetScript(); } state_entry() { integer i = llGetNumberOfPrims(); for (; i > 1; --i) // Checking all the prims, except the root. { string name = llGetLinkName(i); if (name == "toeflat") { if (ShowToes != []) // Params list for regular toes not empty { // We need PRIM_LINK_TARGET... ShowToes += [PRIM_LINK_TARGET, i]; HideToes += [PRIM_LINK_TARGET, i]; } else { // ...otherwise not. FirstToe = i; // Store that link number. } // Primitive params are needed in all cases. vector color = llList2Vector(llGetLinkPrimitiveParams(i, [PRIM_COLOR, 0]), 0); ShowToes += [PRIM_COLOR, ALL_SIDES, color, 1.0]; HideToes += [PRIM_COLOR, ALL_SIDES, color, 0.0]; } else if (name == "toefly") { if (ShowFlyToes != []) // Params list for fly toes not empty { // We need PRIM_LINK_TARGET... ShowFlyToes += [PRIM_LINK_TARGET, i]; HideFlyToes += [PRIM_LINK_TARGET, i]; } else { // ...otherwise not. FirstFlyToe = i; // Store that link number. } // Primitive params are needed in all cases. vector color = llList2Vector(llGetLinkPrimitiveParams(i, [PRIM_COLOR, 0]), 0); ShowFlyToes += [PRIM_COLOR, ALL_SIDES, color, 1.0]; HideFlyToes += [PRIM_COLOR, ALL_SIDES, color, 0.0]; } } uuSetToes(FALSE); // Set the switch. } touch_end(integer num) { if (llDetectedKey(0) != llGetOwner()) { return; } // Owner only! // uuSetToes(!theSWITCH); // Invert and use the switch. } }  Tested in-world. It compiles and works... fast! Just don't forget to change the toe names in the script to match your build. And reset the script if you re-link anything.

You cannot see particle informations in V2/V3 *cough* *nor V1* *cough*... Even the scripts can't read these infos... But they can set them. It's the only way.

I was desesperately bored... // 4-face cube//key TEX = "398acae7-eb03-04b6-0a9f-0f65480bc9a1";float CellWidth = 1.0; // Relatively to CellHeight: (< 1) == narrow, (> 1) == widedefault{ state_entry() { vector scale = llGetScale(); // // Faces: 4, 7, 6, 1 // llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_SIZE, <0.01, scale.z * CellWidth * SQRT2 * 2.0, scale.z>, PRIM_TYPE, PRIM_TYPE_BOX, 0, <0.125, 0.875, 0.0>, 0.00, <-0.25, -0.25, 0.0>, <1.0, 1.0, 0.0>, ZERO_VECTOR, PRIM_COLOR, ALL_SIDES, ZERO_VECTOR, 1.0, PRIM_COLOR, 4, <1.0, 0.0, 0.0>, 1.0, PRIM_COLOR, 7, <0.0, 1.0, 0.0>, 1.0, PRIM_COLOR, 6, <0.0, 0.0, 1.0>, 1.0, PRIM_COLOR, 1, <1.0, 1.0, 0.0>, 1.0, PRIM_TEXTURE, ALL_SIDES, TEXTURE_BLANK, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 4, TEX, <2.0, 1.0, 0.0>, <0.5, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 7, TEX, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 6, TEX, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 1, TEX, <2.0, 1.0, 0.0>, <0.5, 0.0, 0.0>, 0.0 ]); }} Even bored to death... // 5-face cube//key TEX = "398acae7-eb03-04b6-0a9f-0f65480bc9a1";float CellWidth = 1.0; // Relatively to CellHeight: (< 1) == narrow, (> 1) == widedefault{ state_entry() { vector scale = llGetScale(); // // Faces: 4, 8, 5, 7, 1 // llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_SIZE, <0.01, scale.z * CellWidth * SQRT2 * 2.5, scale.z>, PRIM_TYPE, PRIM_TYPE_BOX, 0, <0.15, 0.85, 0.0>, 0.3333, <-0.25, -0.25, 0.0>, <1.0, 1.0, 0.0>, ZERO_VECTOR, PRIM_COLOR, ALL_SIDES, ZERO_VECTOR, 1.0, PRIM_COLOR, 4, <1.0, 0.0, 0.0>, 1.0, PRIM_COLOR, 8, <0.0, 1.0, 0.0>, 1.0, PRIM_COLOR, 5, <0.0, 0.0, 1.0>, 1.0, PRIM_COLOR, 7, <1.0, 1.0, 0.0>, 1.0, PRIM_COLOR, 1, <1.0, 0.0, 1.0>, 1.0, PRIM_TEXTURE, ALL_SIDES, TEXTURE_BLANK, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 4, TEX, <2.5, 1.0, 0.0>, <-0.25, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 8, TEX, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 5, TEX, <-10.0, 1.0, 0.0>, <-0.3333, 0.0, 0.0>, 0.0, PRIM_TEXTURE, 7, TEX, <1.0, 1.0, 0.0>, ZERO_VECTOR, 0.0, PRIM_TEXTURE, 1, TEX, <2.5, 1.0, 0.0>, <0.25, 0.0, 0.0>, 0.0 ]); }} All that's left is to calculate the offset and repeat for each face.

If it is to preload textures, the faces really don't need to face anywhere. They can even be fully transparent. All that matters is that the objects and their textures to preload are some place within the draw distance of the audience. For that cubes are the shape with the highest number of faces. 6 for a default cube plus 2 when you cut it (a little only), plus 1 for the hollow = 9. As for showing the most faces in one direction, use a cut prism. If the textures have no alpha channel, you can go up to 5, otherwise 4. But all this doesn't change the fact that a text display that requires 70+ textures to be preloaded is --pardon my bluntness-- pure crap. Instead of that, a single texture with all the needed symbols on a grid is a much better idea. This way, the script only needs to play with offset and repeat to display one symbol on a face. (Don't forget to include the blank space in the grid.) Besides, when the single texture is rezzed, the whole board becomes readable at once and it's much easier to hide this single texture on some existing building.

If you know what it means and implies, you can get the sources from the SVN at SourceForge. To be on the safe side, I got them. It compiles and it works (on my Linux box). YMMV...

Errr... Can we have an official confirmation on this? A Jira maybe? I have this little function in a script I wrote recently: uuError(string msg, integer fatal){ if (CardLine > -1) { msg = "Notecard line " + (string)(CardLine + 1) + "\n\t" + msg; } llOwnerSay("/me \n\t" + llList2String(["WARNING", "*** ERROR ***"], fatal) + "\n\t" + msg); if (fatal) { state offline; }} It's still working on all server versions available on Agni: Second Life Server 11.09.09.240513 Second Life RC BlueSteel 11.09.16.240906 Second Life RC LeTigre 11.09.16.240954 Second Life RC Magnum 11.09.20.241144 I re-compiled the script and triggered a state change from the function on every server version. Result: It compiles and it works. So... Can anybody confirm?

The concept is interesting but the name of the function is misleading. llSetKeyframedMotion() as proposed by Void would be better... or llSetKeyframedTarget() since it's more or less a super llMoveToTarget() for non-physical objects. I would however add the possibilty to prevent this function from affecting the rotation of the object. Simple interpolated rotations from point to point are a bit restrictive. I also hope that some new event will be provided so that the script knows when the end of a non-looped list is reached and we don't have to rely on a timer (or worse) to obtain that information. What I don't understand from the blog post is why the PE system *must* be used. If the object contains no meshes, what's the use of the PE?

Never judge a book by its cover... If anybody asked me to change anything on my avatar to be taken seriously, this person would fall down at the bottom of the list of people worth knowing. Judging people by their appearance is a caracteristic of a very hollow, superficial personality... especially in SL where you can be anything you want. I would take more seriously an avatar who looks like a wooden cube with a rational discourse that another one in tie and suit who brings a PR-type behavior into SL. Avatars are like bottles... the thicker the glass is, the less contents they hold. Just keep your wings.

Altho LL says --I quote.-- [LL] does not endorse any of these resellers and accepts no responsibility for their actions. --End of quote-- the resellers listed on the following wiki page are more or less certified not to be scams. http://wiki.secondlife.com/wiki/Linden_Dollar_Marketplace As a European, I used Eldex which I discovered when the list on the wiki page was much smaller and I had zero problem. However, I must say that the benefits you will gain with a third-party reseller amount to a bag of peanuts... or two. The really good thing is that you have a large choice of methods of payment. Of course, YMMV. PS: I'm not affilated to Eldex in any way, nor one of their employees, this is just pure free advertizing from a satisfied customer.

That is not really the size of a prim but the size of an object which can be a single prim... vector uuGetObjectSize(key id){ list bb = llGetBoundingBox(id); return llList2Vector(bb, 1) - llList2Vector(bb, 0);} But, alas, llGetBoundingBox() is currently bugged. See Jira SCR-90.

This limit has been lifted a long time ago already. Physical objects can have 32 prims plus (in theory) 224 sitting avatars. I however don't know how things turn out with the new physics-less prims/meshes, i.e. if they are counted against that 32-prim limit or not. (Beware that using physics-less prims implies counting things in Prim-Equivalent.)

I stand corrected about the prim to prim chat. I must say I've never actually tested. Link messages are the obvious (and only) means of communication I've even used in between prims.

One thing that Rolig forgot to mention is that hold animations are doomed to failed. The animations imported into SL mostly all have the highest priority to crush the default animations. In other words, the first next animation to be started by the AO will cancel the hold animation. Restarting the hold animation in a fast timer helps a bit... but it still doesn't work at 100%. My (only and very frustrating) attempt in this area worked well... except when the AV started walking. And I found that trying to keep one hand of your AV closed is just plain maddening. Sorry if I'm not the bearer of better news...

I won't say I understood all that you said... but I understood that you would like to let child prims talk to each other through chat. Try this: Build and object with 2 prims, 1 with a simple listen() which repeats what it can hear through llOwnerSay() and the second one which say something on touch. What you will notice is that an object cannot hear itself... as said in the wiki. To let child prims talk to eachother and to the root, the only way is linked messages. Well, you can try http-in but this would be a bit over-kill.

With a two-state object like a curtain, checking all the touchers will result in a quick state flip if the number of allowed touchers is even. The script will open the curtain for one allowed toucher and close it for the next one, or vice-versa, and so on. It will produce the right result only if the number of allowed touchers is odd... plus some flipping before to reach this result. It would be more appropriate to react only to the first allowed toucher. touch_start(integer num) { for (--num; num >= 0; --num) { if (llSameGroup(llDetectedKey(num))) { integer i = ns; for (; i > 0; --i) { llSetPrimitiveParams([PRIM_SIZE, llGetScale() - offset, PRIM_POSITION, llGetLocalPos() + ((hi_end_fixed * offset) * llGetLocalRot())]); } offset = - offset; return; // Stop after first allowed toucher is found. } } }  That will do it.