Sylvia Wasp

Thanks, that seems to work at least for the head skins. Still wish it were Omega though so I can have the same skin over my whole body or use my own skin. Edit: I take it back, lol. 746 results of which only a small number are actually "skins." How annoying.

that's what I'm wearing though.

Hello, Couldn't find any information on this on Lelutka's site or in-world store, or MP or blog etc. but are Lelutka heads not Omega compatible? If not, why not? Why the proprietary system? I have an Omega compatible mesh body and a Lelutka head, it's looking pretty good with the exception of the "Glam" skin (i'm more of a "low makeup" girl) , but this non-compatibility is really getting in my way. Even assuming I just wanted a skin for the new head *alone* and was willing to forget about the body for now ... where does one even get a skin for a lelutka head? I spent about 45 minutes walking around their store looking at every little thing (and there are thousands of things) and didn't see a single skin for sale by Lelutka or any of their associates. I'm confused. $5000 for a head and I can't do anything with it until I can install a nice realistic skin. It would be nice if I could do body and head at the same time too. Sylvia

I guess everyone has a different experience.

Thanks Bobbie :matte-motes-grin: I'll give it a try, although I don't see how it will work for this problem. Still searching for other heads atm. By AK I guess you mean Akeruka?

sadly, the eve-olution one looks a lot like my mum

good idea! I knew there was a reason I'm posting here, lol. yes Tonic has five different neck sizes but the range is subtle I guess, the smallest size is the one you see in the picture which is still quite a bit wider than the lelutka head. (not blaming either, just sayin). I've been having fun with checking out these Bento heads though and they are all so different! here is a picture of the way I have to deform my legacy head to make each of the bento heads look as close as I can to my actual legacy head shape. I include it mostly because it's HILARIOUS, :matte-motes-big-grin: but also it's a great insight into what the defaults that have been "built-in" to each mesh head shape are. .

I guess I wasn't that clear. I have a mesh body I've been using for quite a while and it's a really good one (Tonic). The problem is that while the neck on a Tonic body is essentially the same width as a "lagacy" neck (so the legacy heads will fit properly), the neck on a lot of popular bodies like Maitreya are super skinny. My belief is that the Lelutka head and Catwa are designing for this "thin" neck size rather than the "regular" neck size, but I admit I'm a bit hazy on the details of all this and am still learning. A picture tells a thousand words so I will attach one that covers my attemtp to recreate my legacy head with lelutka. *Note this isn't a criticism of lelutka per se, which I think is the best mesh head out there that I've tested so far, but you can see the neck is a lot thinner than the legacy one. .

Thanks for the info. :matte-motes-grin: I've got a couple of leads on Bento heads from Mesh Body Adicts, but I've been having trouble finding deomos in world or on MP. The Lelutka head for example is the best I've found so far, but it doesn't appear to even exist on MP. I have an unusual face shape that I've had for years that isn't the standard "fasion model" type, so it will likely be a while before I find a Bento head yes. To any head designers out there ... I think there is definitely a market for a more realistic looking female head. Not everyone wants to look like Barbie, etc. Also, SL has a long history of user creation and customisation. I think the Bento head that will win the market is not necessarily the prettiest one, but the one that is the most adjustable perhaps.

hello, like many people I've been testing out Bento heads lately and while I haven't found any yet that are capable of replacing my SL legacy head (most simply can't adjust enough) there are some that get so close that I could see them working some day. The big problem I've found with the current batch however is the neck. It seems that both Catwa and Lelutka (the two currently most popular), are designed specifically for the very narrow neck of Maitreya Lara and cannot be fitted on another mesh body, let alone a legacy avatar. Maitreya Lara is possibly the most popular body in SL of course, but there are gazillions of people who don't use it as well. So my question is about whether or not anyone is aware of other mesh heads that have The same size neck as a standard or legacy avatar, or if there are plans at Lelutka in particular to issue some sort of "neck fix". Please note that this is not a slider issue I'm talking about the shape of the mesh used and the choices of the designer. Thanks for any help, Sylvia

Rolig Loon wrote: Yes, as long as you don't do it as you are defining the global list. You can't calculate things as you do a global declaration. Can you say that again in English? lol. Edit: nm, I've figured out what you mean ... I think.

I don't know if anyone is stil interested in this but I think I've started to work it out. A question I have though that doesn't seem to be answered by the LSL wiki is about how to write the rotations in the strided list, and what kind of entries are allowed or not. In the original script for rezzing a single object, I define the rotations like so: llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>); because they are all 90 degree rotations and I don't have to manually figure out quaternions (as if that's gonna happen). So a rough of my strided list for the new script I get something like: list vendorList = ["leb_vendor 1", <2.625, 1.27887, -1.225>,llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>), "leb_vendor 2", <2.525, -1.265, -1.215>,llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>), "leb_vendor 3", <2.625, -1.375, -0.25>,llEuler2Rot(<PI,PI_BY_TWO,PI>, "leb_vendor 4", <1.78, -1.375, -0.75>,llEuler2Rot(<PI,PI_BY_TWO,PI>), "leb_vendor 5", <2.041, -1.375, 0.3547>,llEuler2Rot(<PI,PI_BY_TWO,PI>), "leb_vendor 6", <2.626, -1.375, 1.1454>,llEuler2Rot(<PI,PI_BY_TWO,PI>), "leb_vendor 7", <1.78, -1.375, 1.1454>,llEuler2Rot(<PI,PI_BY_TWO,PI>), "leb_vendor 8", <2.041, 1.40387, -0.75>,llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>), "leb_vendor 9", <2.625, 1.40387, -0.25>,llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>), "leb_vendor 10", <2.625, 1.40387, 0.75>,llEuler2Rot(<PI,PI_BY_TWO,PI>), "leb_vendor 11", <2.041, 1.40387, 1.1454>llEuler2Rot(<PI,PI_BY_TWO,PI_BY_TWO>) ]; is it actually kosher to use 11Euler2Rot like that?

Good advice, thanks. I tend to disagree about comments though. I find that the popular advice to add lots of comments to scripts much more of a hinderance than a help. It should (to my mind) be clear what's going on for the most part if the script is succinct and well laid out (again, I'm talking about vidual clutter here). I've rarely found a script yet where I couldn't rip out literally 90% of the coments and yet make it much clearer what's going on as a result. But then, I only deal with simple scripts.

Ela Talaj wrote: There is no reason to hardcode position/rotation offsets in a list. In fact it is bad programming because not data driven. I would've (and did in this product) rezzed all objects from the list of their names originally in the center of the rezzer, then I would've manually positioned the objects correctly around the rezzer and recorded (via on-touch menu button) their positions/rotations relative to the rezzer. After positions/rotation are stored in the script, on subsequent rezzes the objects would be rezzed in the positions/rotations last recorded. Of course I didn't invent a bicycle here, most commercial rezzers work this way. Well, this is kindof what I did, except I didn't do it with a commercial rezzer, I manually figured out all the offsets and rotations. the reason for the list is also as you say, which is that I want them to rez at the same spot every time. Basically the initial object is rezzed, you click it, and then the eleven other objects (vendors basically) rez around it in various locations. So, it's hard coded into a list in order that they always rez in the same spot in the same way, relative to the original object, no matter how the original object is rotated or positioned. Each object (vendor) has a "die" script inside so a second click on the original object puts them all away. I realise this is an awkward way of rezzing eleven vendors but it's a peculiar and unique situation/object.

As sad as it may sound, I'm leaning against using the strided lists because of "visual confusion" The list of eleven object names eleven vectors and eleven rotations would wrap around the page so many times it would just look awful. I'm more of a visual person and it's important to me to have the code clutter-free and easy to read. I find that when the code is poorly formatted or has lines that are too long to fit on my screen that it gives me a headache, lol. :smileyhappy:

Thanks, It's interesting that an array can be "faked" that way, but it seems a bit confusing to me and the list would be terribly long. I guess three lists are the way to go for me.

Thanks for the replies, What I have already is a script I made for a fireplace that works for rezzing single objects (in this case the burning firelog in the grate). It seems short and efficient. Let me know if you see anything wrong with it. The trouble is this new project is eleven objects and currently I have hacked it by simply having eleven scripts in the "master" object, which is at best clunky. A second click de-rezzes the objects, so when there are eleven scripts like this the chance that they get out of sync is pretty high. There are also a lot of pauses and pinwheeling. I'm really not sure where to put the loop (that would access the lists and cycle through rezzing the eleven objects) or how to code it. // ===================================// fireplacer script by Sylvia Wasp // ===================================integer _fireOn;vector _currentPos;vector _fireOffset;vector _rotPoint;vector _newPos;rotation _currentRot;rotation _fireRot;default{ on_rez(integer start_param) { llResetScript(); } state_entry() { llWhisper(59,"poke"); _fireOn = FALSE; } touch_start(integer total_number) { if (_fireOn){ llWhisper(59,"poke"); _fireOn = FALSE; } else{ _currentRot = llGetRot(); _currentPos = llGetPos(); _fireOffset = <0.0, 0.1, 0.0>; //change f/pos of log from root _rotPoint = llGetPos() + _fireOffset; _fireRot = llEuler2Rot(<TWO_PI,PI,PI_BY_TWO>); //the rotation _newPos = _currentPos - ((_currentPos * _currentRot) - (_rotPoint * _currentRot)); llRezAtRoot("firelog w/fire", _newPos, ZERO_VECTOR, _fireRot * _currentRot, 42); _fireOn = TRUE; } }}

Hello, I'm trying to write a script that makes an object rez a bunch of items from it's own inventory at various specific locations around itself. I have all the off-sets and rotations for these objects and I can make one of them appear easily enough, (I have my own working script for that) but I don't quite know how to make them all appear simultaneously. My preferred method would be to declare an array of the necessary data at the top and then have a loop at the part of the script that rezzes the object, that queries the array so that it can quickly and recursively rez them all, essentially (but not actually), simultaneously. It's the "exactly how to do this" part that I'm not too sure of. Are llscript lists always one dimensional? (meaning I can't actually make an array)? If they are, that means I would presumably need a list for each vector and each offset? There are eleven objects to be rezzed and I want to make it as efficient as possible and not use fifty global variables or whatever if I don't have to. I have an understanding of basic scripting and of LL script but it isn't my "thing" so someone who dreams in code and wants to help would be appreciated. Thanks, Sylvia

Rolig Loon wrote: "Don't blame it on the prim grass or the falling leaves. They aren't going to do much, if anything, to create lag. There's something else going on. You might get a clue by looking at the Statistics Bar ( Shift + CTRL + 1 )." Actually this is FALSE. Second Life "grass" does indeed cause lag. This "grass lag" is well-known and has been around as long as the grass has been available. I've experienced it myself and heard about it from my friends for years, across multiple viewers and using multiple computers. The effect is easily testable and completely repeatable. Example: I have a great, almost new computer, all my settings are on "Ultra" or above and I generally don't have any problems at all until ... I face a field of grass. Then my FPS drops precipitously, usually down to less than 1FPS! If I turn even slightly so the grass isn't in my field of view, the FPS goes right back up again. Coincidence? I think not. So, I have the same question as the orignal poster, which I believe (between the lines) is something like "what can I do to my settings to counter this effect." All the replies that claim the problem isn't real or merely state the obvious (reduce your graphics settings) are really no help at all. The real question is whether or not there is some graphics setting that affects this or whether it's just a "grin and bear it" situation. If anyone has an answer I'd appreciate it, as I'm sure the OP would as well.

Exactly. For example I used to make a TV set for sale on MP, it had 60-70 prims but it was beautiful. I got endles compliments on it. It's just a little jokey thing that plays animations and costs only 10L but now ... no one wants this. If your entire house is only one mesh object and you are a nooob living on a tiny plot of land, why would you want to have a 70 prim TV set? Also, a lot of things like railings, stairs, etc. simply can't be done with prims becuase then the build would be hundreds and hundreds. So the old way was to make some crappy texture of railings or stairs and apply it to a single prim. Mesh is necessary and rapidly taking over. LL needs to give peope the tools to work with it.

re: "why not build with prims?" Because no one wants a build that's made out of a dozen prims and has a land impact in the high 90's when they can get a mesh object with a land impact of one or two to do the same job.

I don't know why you bothered to spend the time replying here. You've added nothing but som snarky insulting comments. My point was that to offer a non-functional product for sale is (technically) criminal fraud. This is a bit beyond simply buying the wrong size panties on MP.

I've been thinking of buying Mesh Studio for a while and I finally went to MP to put down my $5,000 and its seems the product is not only broken (the servers are down and have been for a long time), but the reviews state that the server is literally "never coming back up." Yet the product is still for sale in MP for waht amounts to about twenty dollars in real world money. Now since this would basically be a case of criminal fraud if it's true, making both Mesh Studio and Linden Labs legally liable for class action suits and even possible criminal prosecution ... I kind of doubt it. On the other hand, when you go to any of Mesh Studio's web presences you can't find any information on this at all and no way to even contact them over any issues you might have with their product. So before I throw away twenty bucks on a non-working product I have some questions: 1) Does anyone really know for sure if the server will ever come back up again? 2) What happens if it doesn't? 3) Will Linden Labs refund our money if the servers never come up again? 4) Why doesn't Mesh Studio offer any information or help on this topic? (what are they hiding?) 5) Why doesn't Linden Labs remove the non-functional product from MP if the servers are non-functional for so long? 6a) Why isn't there at least a warning on the product on MP? 6b) Why do you have to go to "reviews" to find out you are about to be completely ripped off? Finally, why the heck doesn't Linden Labs produce a similar tool? There is obviosuly a huge demand for such tools, and there must be many other Second Life users out there like myself who are "masters of the prim" but don't have the skills to use 3D programs like Blender, or the money to pay for them. Are we supposed to just wander off into the sunset and die? Second Life has a huge legacy of fantastic prim builds that will soon be lost forever if a reliable "prim-to-mesh" tool is not introduced post haste. So many fantastic builders have already left Second Life over this issue. Isn't it about time this whole thing is fixed "from the top" at Linden Labs? Sylvia

I'm trying to find out "How to Make a Book Page Turn" in Second Life and all I get are pages that point to the question as "Answered," (officially) but the answer is actually an answer to a completely *different* question. That question being: "Where can I purchase a book manufacturing system in SL?" So the real question is never answered. What I want is to find out ways to make prim pages turn in SL. Does anyone have an actual answer to this question? Are there any scripts floating around that could be examined or modified? Any examples or general advice? Sylvia

Replying to myown question as someone gave me the answer. flexi objects in SL alays point correctly in the SL wind, so the answer is to rez a flexi object and use that as an indication of the actual wind direction.