Kaluura Boa

Huuuuu? I do not know what you did with your triangles but my numbers do not match. My frame is 32 triangles, 48 vertices (16x3 materiels) according to the uploader. (Blender agrees with the 32 triangles.) The uploader calculates a physics weight of 0.360 whatever the size. The download weight is 0.142 at 3x3x0.1 m^3, and only 0.101 if I import directly at 3x3x0.5 m^3. Once set to "prim", here is what I get in-world: I cannot say the physics cost really explodes. I find the Land Impact of 2 totally exaggerated... but that is only my personal feeling. So is my guts feeling that the multiplication factor from download weight to physics weight may cause the automatic switch to convex hull. As to using the uploader's decomposition, I wonder what special magic it could do? Re-order the triangles by color and size? :smileywink: It is impossible to do better than 32 triangles for this shape... but I would welcome gladly to be proven wrong.

Yesterday, I was working on a mesh which is --roughly-- a wall shape with a hole. I made a physics shape to be able to go through the hole, I set the physics to prim and... WTF? The hole was big enough for my avatar, the physics shape display showed a hole but it was impossible to go through. I added some top and bottom faces to my physics shape which was only like a fence around the mesh. No change. (WTF?) I re-did the physics shape in several boxes. No change. (WTF?) I uploaded and re-uploaded in several sims to be sure my problem was not caused by a special version of SL server. Still no luck. (WTF?) Several days earlier I made a sort of arch and the physics shape works fine so I made a little change to my "wall" in-world... and I could not get enough of going through that hole... Walking, running, flying, crouching... and on a vehicle. :smileywink: Today, I made an experiment to confirm what I found... and I took pictures. I made a simple frame, a shape that I could re-use as physics shape. Size: 3x3x0.1 m^3 In Blender (with some colors to looks nicer) and in world. LOD and land impact being of no importance here, I just re-used the same file in every slot: The 4 LODs and the physics shape. (LI: 0.5 PE) Of course, as expected, it was impossible to go through despite the fact that I cannot say how such a simple shape can fail. The problem is the 0.1 m. in the size. If you increase it up to 0.5 m, it works! 0.499 m. will not work. You have to go all the way to 0.5 m for the mesh itself. Enlarging the physics shape is not enough. A simple triangle hidden in a corner of the mesh can do the trick eventually. (Tested in-world already.) Here, I just resized the mesh. Finally gone through! Just do not ask why. I. DO. NOT. KNOW. If one dimension of the mesh is below 0.5 m, you can only use a convex hull or no physics at all. And now that I am done going through (square) hoops, I am going to write --a letter to Santa-- a Jira. That is definitively not a feature but a real bug.

EDIT: You may want to replace llSetLinkPrimitiveParams() with llSetLinkPrimitiveParamsFast() if the 0.2 sec. delay freezes your script at the wrong moment. From what I see in your script, it looks like you are trying to rotate child prims a quarter of turn if colormenu is set and to rotate them back otherwise. Your scripts fails for two reasons: First, llGetLocalRot() returns the local rotation of the prim in which it is called from. I assume your script is in the root... which does not rotate. So... Second, to add more rotation to a current one, the right "formula" is more_rot * current_rot. And third, not a reason for failure but a question that crossed my mind. The way your script is written, the same rotation is applied to the 3 child prims. Is that what you want? If yes, here is what I would write: integer colormenu = TRUE;integer ColorMenu(){ colormenu = !colormenu; // if (colormenu == 1) { colormenu = 0; } else if (colormenu == 0) { colormenu = 1; } rotation quarter_rot = llEuler2Rot(<0.0, 0.0, PI_BY_TWO>); // 90 * DEG_TO_RAD == PI_BY_TWO rotation child_rot = llList2Rot(llGetLinkPrimitiveParams(3, [PRIM_ROT_LOCAL]), 0); list params; if (colormenu) { params = [PRIM_ROT_LOCAL, quarter_rot * child_rot]; } // Turn one way... else { params = [PRIM_ROT_LOCAL, child_rot / quarter_rot]; } // ...or the other way. llSetLinkPrimitiveParams(3, params + [PRIM_LINK_TARGET, 4] + params + [PRIM_LINK_TARGET, 5] + params); // Synchronized rotation return 0; // Do you really need to return something?}default{ touch_start(integer num) { ColorMenu(); }} If the prims do not turn the right way, just move the line colormenu = !colormenu; to the end of the function (before the return). If the child prims all have different original rotations, things are a bit different: integer colormenu = TRUE;ColorMenu(){ colormenu = !colormenu; rotation quarter_rot = llEuler2Rot(<0.0, 0.0, PI_BY_TWO>); list child_rot = llGetLinkPrimitiveParams(3, [PRIM_ROT_LOCAL, PRIM_LINK_TARGET, 4, PRIM_ROT_LOCAL, PRIM_LINK_TARGET, 5, PRIM_ROT_LOCAL]); list params; integer i = 0; for (; i < 3; ++i) // 3 prims { if (i) { params += [PRIM_LINK_TARGET, i + 3]; } // Link numbers: 3, 4, 5 if (colormenu) { params += [PRIM_ROT_LOCAL, quarter_rot * llList2Rot(child_rot, i)]; // Turn one way... } else { params += [PRIM_ROT_LOCAL, llList2Rot(child_rot, i) / quarter_rot]; // ...or the other way. } } llSetLinkPrimitiveParams(3, params);}default{ touch_start(integer num) { ColorMenu(); }} (I removed the return which seems very superfluous to me.) Both scripts tested in-world. They work whatever the rotation of the root prim.

[ tl;dr version: Let's switch to Display Name only and have the viewers replace on-the-fly any of your known names with your Display Name or else.] (First, to make clear where I stand, I must say that I am... was?... a big supporter of the return of the Last Names on the registration page.) Last night, I had one of these moments of drug-induced absolute clarity (100% pure melatonine, the sleep hormone.) :smileywink: and I saw some light at the end of the tunnel. It should be obvious by now that Rodvik is not a big fan of the return of the Last Names so let's turn the page and start afresh. What do we have and what can we do to make everybody happy? And, more importantly, what do we want? On the left, we have the Legacy Names (Kaluura Boa), the old-style SL names with family names --which include the Resident last name to the displeasure of a lot of people. In the middle, we have Usernames (kaluura.boa). On the right, we have Display Names. (Like a lot of old-timers, I use Display Names to show only my first name, so: Kaluura). For the best or the worst, we have Display Names and it is unlikely they will suddenly disappear. Let's just use them. Let's make the switch to use only Display Names in-world. There are a few arguments against the whole idea. Confusion and impersonation. Display Names are not unique. So what? That is the same thing than in the real world. Not everybody has a unique name so that they can google it and count the Internet pages dedicated to their very own person. Merchants who still have an in-world shop can eject and ban avatars who carry their brand name on their land. Scripts can do that and more, like recognize names which only ressemble through the use of various Unicode characters. Such a system would not be perfect but if people do not try to impersonate merchants, they should not be worried of being injustly banned. Sometimes, we also need really unique names to make white lists or black lists. This is only a problem of terminology. Scripts in such cases should ask univoquely for Usernames and not confuse their users with vague expressions like "avatar's name". Using Usernames also applies to any accountance situation. If your scripter is stupid enough to want to store Display Names, change of scripter. Period. As a scripter, I will not bother storing anything but UUIDs. They are the really unique "name" of an avatar and from that, a script can show any of the related names --including the Display Name of the week-- when a Human needs something a little more readable. Legibility. It is too much true that some people cross the line of the readability with their Display Name. In such a case, you can just say "Hey you!" or, if you are so inclined, tell the person that you cannot read their name, open their profile to get their Username. Whatever. An unreadable Display Name is not a wall of bricks across the whole world or a mountain higher than the Everest so that you cannot go around. The Resident Legacy Name. If I am not mistaken, Rodvik promised to remove it as much as possible from the viewers. If Linden Lab does so, the Third Party Viewers will follow sooner or later. However, that is not enough. Viewers should take the next logical step and intercept any name addressed to you and replace it with your current Display Name. To make everybody happy, this should be an option set by default on Display Name but which should allow you to be called by your Legacy Name or even Username. Your choice. And suddenly all the objects of SecondLife would call you the way you want. The replacement system does not need to be perfect. If people misspell your name, no replacement will occur and you will see it. That is all. It would apply only to your name on your screen. You might still see objects calling other avatars with something else than their Display Name... but is it a problem? I do not think so. LL's job in the matter would be minimal but very important: To make sure that Display Names are and stay reliable. And to burry the Legacy Names! As the name suggests, they are a thing of the past. People who think that Display Names are the absolute abomination should not have changed their Display Name and it should still match their Legacy Name. No real change for them. No change to do on the name tags. People see others' name the way they want and they can call them the way they want or can. The others' viewer will intercept the chat and eventually modify it to use their Display Name or whatever is set. Now we have the cake and we can eat it! :smileywink: Such a system would allow everybody to have a Legacy Name, a single name, a middle name, a Japanese-alike "inverted" name. Anything you want! This Display Name switch revolution will not happen in a day but it is not so unrealistic, is it? Can we do it and move on? PS: Dear LL, if you think the whole idea violates the concept of "shared experience", look another way. You do not want to pour gazoline on this fire, do you?

If you installed the client system-wide (with root priviledges), a desktop file can be found in /usr/local/share/applications. If you install in your home, the file will be in ~/.local/share/applications (which is a hidden folder). This desktop file says that the SL client should appear somewhere in the big desktop menu. If not, take that file and link it onto your desktop or drop it onto a panel. Edit: And leave the Wine in its cellar! The Linux native client is the most stable...

Definitively not! Using prims to make walls is definitively not the way to go! When you upload your model give it a physical shape. That's the way to go. As a test, you can use the model you upload as physical shape too. Note that in your case, the windows will also be holes. (Note for the future: Think of doing a much simpler shape to reduce Land Impact.) Once your model is rezzed, go to Features tab in the Build floater and change from "Convex hull" to "Prim". Et voilà!

This is usually caused by m*r*ns who find it amusing to select or edit your vehicle to block you because --you know-- vehicles using physics create lag. However this "feature" was fixed a long time ago, if I am not mistaken. Any way, I still use a trick from before the fix in all my vehicles: llSetStatus(STATUS_BLOCK_GRAB_OBJECT, TRUE); Note: STATUS_BLOCK_GRAB_OBJECT, not just STATUS_BLOCK_GRAB which is not very useful, to say the least. IIRC, it prevents anybody from blocking your vehicle through grabbing or edition... except yourself and those who have edit permission.

@Fluffy Sharkfin: Thank you! The control freak in me is happy. :heart: Now, I spend hours arranging every triangle... but I like the result, especially when I play with some shine. @Chosen Few: Realism... Hmmm... We're in SL and I'm building steampunk dirigibles. I think I threw realism out the window a few years ago. :smileywink:

Irrelevant. You can upload super-crappy-bloaty BMP, it will be slow to upload but, in the end, all textures are converted to JPEG-2000 and that's what SL feeds the viewers with.

@Luc Starsider: Multiple meshes...That is something I have not tried yet. Starting Blender! @Rival Destiny: Mega-meshes... Well, it is all relative since now prims can be up to 64x64x64. @Min Barzane: I was about to say "No can do" but I will check the LOD formulas first. I already go without a real lowest LOD, maybe I can remove more. @Thinkerer Melville: Thank you. You made me laugh. :smileyhappy: I really wish it was the problem... but my graphics are set beyond ultra, with shadows and everything.

How to do that? So, I'm making dirigibles (blimps, whatever, like the Hindenburg minus the fire hazards) and my problem is the land impact. I can do super-smooth round small objects but at the scale I need, all I get is big, smooth... and octogonal, or else the land impact turns into an extinction level event. (Land impact, crater, meteor, sorry...) Hence the question: Is there a trick to make a huge spheroid (like 50x20x20m) which looks as smooth as a real prim but without the insane land impact? I'm talking only about the building part because I use a simple cube as physical shape and that's already more than I need. (Excuse me if I am not super clear but my blood pressure is hitting the roof and I am super close from the giga-rant about land impact.)

First thing that comes to mind: Are all the LSL functions used in the scripts supported by the OpenSimulator? And the second one: How are handled the textures? Hardcoded keys will always work in SL but definitively not anywhere else.

Typical case of overheating graphics card... Some ppl will suggest to use carrots to lure the dust bunnies out... :smileywink: but I'd rather advice to disassemble and to use a vacuum cleaner.

Everything is possible... The real question is: Do you want your doors to just slide sideways or to fold like an accordion? Both cases require rotation experts... The latter even needs a rotation mad scientist. :smileywink: But if you want a finished script instead of writing it yourself, this post belongs to the "Wanted" forum.

That is the question. Is there some hidden contraindications against crossing faces? Let's take a (stupid) example to illustrate my question: I made a nice heart and I want to add an arrow across it. I have 2 solutions: I can make 2 objects in one mesh where some faces of the arrow will cross some faces of the heart, or else I can add vertices, edges and faces to join the heart and the arrow into a single "inflatable" object. I checked in-world already and crossing faces come out right visually. That makes me wonder: Why should I make a heavier object if I can just let the faces cross?

I don't really remember where I read about SL for the first time. It was in 2007, somewhere on Internet for sure, most probably some tech news feed. I found the idea of a totally new world to explore absolutely fascinating. I checked that a client was available for Linux and I was in... Well, certainly after a looooong time spent creating my name. I had some real fun on the Orientation Island altho everybody --including me-- was a bit shy and didn't talk much. I only regret I didn't keep the snapshot I made on my first day. I also remember that I didn't actually finish the Orientation Island before TP'ing away. I was in a hurry to start exploring. The really funny thing that I remember from this time is that it took me a week to rez my first cube altho the big "Build" button was right under my nose. A script in it and I turned from hooked to addict... Aaahhhh... Good ol' time of money trees, camping spots and casinos. :smileywink:

I said somewhere else that I won't speak about this subject any more, so... A picture. :smileywink:

To be continued... here! This will be my last post on the subject. Rod's post really infuriated me. I knew from the beginning that the Lab would follow its usual pattern: "You don't like what we propose, let's discuss". Long silence while the whole issue inflates beyond all proprotions. Then: "Here is what we will do, just get used to it". But it this case, things are worse because what the Lab will do is nothing. How lame!

(I removed the part about the loss of the old frontier feeling which would have derailed the thread.) I must say that I am not even remotely concerned about the whole last name issue, I already have a "real" name --and a stock of "real name" alts. However, I deeply sympathize with all the members of the Resident family. Still, it seems to me that the whole issue was sumed up into the phrase: Bring back the last names. Not everybody would be happy but that would have been a step in the right direction, i.e. to undo the big mistake of the previous management. In SL, "real names" have always been "First_name Last_name". When I created my acount, I was midly satisfied with the choice of last names but I didn't think a second it was weird or anything. That's the way it was. And the very important thing is that is was obvious that this name would be visible to others. There was no need for big signs with huge red letters as it seems to be needed nowadays. I wasn't 100% satisfied but now I wouldn't change anything. It's my name and it is so from the very beginning: the login page. (One more reason for me to hate V2/V3 clients which slaughter my name into lower case with a dot in the middle.) I usually happily sit on any tradition but this one should be maintained, reinforced, even celebrated. The "real names" are something that set SL apart from the rest. The new-comers now have to deal with a login name, a somewhat arbitrary name (with an unpleasant touch of noobiness) imposed to them for a reason they can't understand, and a display name. They will never be able to feel the attachment we, old-timers, feel towards our unique name. Bringing back the last names would mean to restore a tradition that has existed since long before the previous management. It isn't the miracle solution but anything is much better than nothing... because the new management wants to screw the system in its very special way to be remembered for eons of internet years. (Did I say that out loud?)

On 03-01-2012 04:15 PM, Rodvik wrote: Hey folks, firstly thanks for all the discussion in this thread on my my.secondlife profile. I had more to say on this than would fit in there, so I’ll post it here in the forums but will link back so we can continue the conversation there. It’s kind of morphed into a sort of unofficial roundtable discussion. It’s been enjoyable and even though this one has not brought about a change many of you would like its been a good process. Low key and direct feedback off the radar, I like that. So when it comes to last names, I have spent a lot of time going through all your comments and chatting with the team here. I learnt a lot. Firstly, as I already knew identity is very important, and the last name issue is extremely polarizing. What I didn’t know was how big a negative impact it used to have on new users signing up (the data is startling at how much friction it added). Folks just wanted to create their own name; they became even more annoyed if there was a pre-done last name that could fit but that had already been taken. The namespace hijacking issue was not solved by pre done last names. But that’s the downside. The upside? It’s just great to be able to have a last name as your master identity. Rather than “horationelson” people want “Horatio Nelson.” Not least because although display names give you complete freedom to choose whatever you want, we still reference “.resident” in a few places. This is just the functional benefit though, I would argue an even greater benefit is the bonding those fixed last names gave people. The shared last name kinda made you “family”, it was a unique system, and I don’t like losing unique systems. Tangled up in this is something that has been gnawing away at me for some time. (...) [Off-topic part removed] But back to the matter at hand. As I promised if we couldn’t figure out a way that was a win/win for folks who want complete freedom vs. a list of last names, we wouldn’t do it. We couldn’t, so we wont. However what we will be doing is adding in at least one and maybe more special characters like a dash when you signup so you can make a more normal looking name. So you can have “horatio-nelson” for example, which is impossible now. Work will begin on this as it slots into the task list. Secondly we will be taking steps to remove more places where the dreaded “resident” last name appears inworld. If you have any places where you see it often that we might have missed it would be good to hear. Thirdly I will be kicking off another monthly roundtable (probably Monday) to chat about getting that family/frontier feel back with an eye to some area-like project, although some of the early ideas (like you get to pick a prefixed last name after you are a resident for say six months) can also be chatted about. Thanks again for all these comments and discussion. It’s a pity that the first one couldn’t come up with a clean solution that solved all the world’s problems (or cats’ problems) but it was valuable nevertheless. ------------------------------------------------------ No comment allowed, so... here we go!

To be sure an object you rez is in-world, use the object_rez() event. In your case, you will be able to remove the sensor and all the delays since you get the UUID of the object which gives you access to all the informations you want with llGetObjectDetails().

You can invert the axis of rotation: llTargetOmega(<0, 0, -1>, PI, 1.0); Or negate the spinrate: llTargetOmega(<0, 0, 1>, -PI, 1.0); Buth not both at the same time! :smileywink:

Quote from Rodvik found on SLU: "heh, nope been very engaged on the issue. I will respond tomorrow in full. I have learnt a LOT about the naming issue why things were changed. It is a very polarizing issue and finding a win / win for those who love naming freedom to those who love the bonding nature of pre picked names has proven impossible to do well. However I do have one feature we can commit to and a discussion going forward about another way to skin the cat. Will update tomorrow in more depth." I can't say if it's a tweet or a feed post. (I do neither of them.) Can somebody confirm with an URL? In the meantime, I have a large stock of first aid kits, picks, forks, barrels of natural tar, poultry feathers... and all the brands of popcorn available on Earth and on orbit. 75% discount on March, the 2nd! Seriously? The lab is about to lose another spokesperson... I tried every possible way to read this and all I understand is: "Nothing has be done yet. We will throw you a bone to calm you down and you can start arguing... again!" I'm taking a first aid kit already. Not for the spokesperson but for me. My head hurts. The walls around me are really hard. Still, I'm totally hooked. What can be that "one feature"? Hmmm... [insert ROFL hysterical smiley]

Write it in your next letter to Santa and send a copy to Linden Lab. :smileywink: In other words: Clean up your profile it's bleeding out on the whole web and there's nothing you can do.

Finally, february comes to an end. As promised by Rodvik, the big boss himself, the plan for the return of the last names should be "baked" this month. Hence, we should expect some big announcement tomorrow, last day of february. Errr... Wait! The tweet didn't say february of what year. Go back to sleep! In fact, I don't think anything will be announced by the Lab in any foreseeable future. Things have a tendency to explode in their face as of late and they are running out of spokespeople. [/sarcasm] (Damn! No popcorn-eating smiley!)