LepreKhaun

The check box is grayed until you at least scroll down the ToS a bit. It's merely a way of ensuring that you haven't clicked acceptance without at least acknowledging that there is something there that you should review first.

Griefing basically means means to cause distress or to abuse another resident. It covers anything that interferes with others from enjoying Second Life and anything that interrupts other residents' enjoyment of participating in Second Life can fall within the definition. But it is usually used in incidents that affect numerous residents, such as self-replicating objects that destroy a sims appearance or "spam bots" that clog anyone nearby with unwanted, repetitive messages. It can range from one resident harassing another to someone crashing entire sims. It can be motivated by revenge, boredom, a misguided attempt to gain a "reputation or simply pure malice.

Runitai Linden once compared the .dae file to a Photoshop .psd file, and the .slm to a jpeg. These files have your mesh asset data, as defined in the associated collada file, in compressed format.and is supposed to simplify uploading a model a second time They are made by your viewer at the time of a successful upload and may be deleted manually or by pressing "clear & reset forms" on subsequent uploads. You can also disable the viewer Importer from generating them to your hard drive in Debug settings by setting MeshImportUseSLM to false. This is recommended if one does a lot of uploading to avoid having an old SLM file used in the place of a newer, updated collada file

Maybe have the person that bought the gift for you write the review?

Since the Direct Delivery system can not handle limited quantity items, you still must use a Magic Box for them in the MarketPlace. They're available at no cost from the Linden Store, https://marketplace.secondlife.com/stores/75 .

Mainland terrain can only be edited with the terrain editor in-world. Most mainland is limited to elevation change of plus or minus 4 meters, though there are some few exceptions in specific areas.

You're using an n-gon for your roof and two of it's edges are angled off of the plane the others are. Impossible to triangulate this. Much better is to do the triangulation in Blender before exporting to your dae file.

joeyblueyes wrote: Sorry for my delay in getting back... Thank you all so much for your help and examples..... Seems I was mainly missing the .x & .y LepreKhaun, thank you so much for the detail as well! I will be also be adjusting Offset & rotation, so seems like the list format will be best.... If Repeats uses .x & .y, then what would rotation and offset call? Thanks again... Giving some thought to your question and reviewing others you have raised in your posting history, I have become aware of what the problem is here: You apparently are trying to move too fast into coding, No biggie really, I'm certain everyone does this at first, becoming too focused on completing a program before taking the necessary time to understand the basic building blocks one uses in its construction. But this approach will not only add time to the writing of a program (as you waste a number of hours trying hit-or-miss blind guesses to try to jimmy everything into working order) but it also leads to unnecessary frustration which may cause you to give it all up entirely. Rolig says "When in doubt, read the wiki" which is very good advice but, at this point for you, reading isn't enough- you must study the wiki. Not only is everything there but the knowledge is presented in a way that a complete understanding of it all is possible. Allow me to show you how you can study the wiki and increase your coding skills. In your original posting in this thread, you used "list params = llGetPrimitiveParams([PRIM_TEXTURE,0]);": Let us open the wiki page for llGetPrimitiveParams ( http://wiki.secondlife.com/wiki/LlGetPrimitiveParams ) and I'll try to show how this must be studied for full benefit. First of all, you'll see at the top "Function: list llGetPrimitiveParams( list params );", which tells you that it is a Linden Scripting Library Function that expects a list and returns a list.. But, here's where the study part comes in! Before going any further down that page, be certain you know and understand each of the underlined words in that phrase, which are (in this case) Function and list. They are underlined because they a links to pages in the wiki that define those terms and, to understand the basic building blocks, you must follow those links down and study the material there until it is completely understood before proceeding further. And when you go to http://wiki.secondlife.com/wiki/List you're going to be confronted not only with a lengthy page of explanation regarding lists but a great number of underlined links throughout it. And they should be opened and studied as well as any new links found as you go deeper down the rabbit hole. And, frankly, it may take a week before you surface again. But, it will be a week well spent! I say that because not only do you need a thorough understanding of lists to use llGetPrimitiveParams and llSetPrimitiveParams properly but lists are everywhere in lsl, being the closest we have to the arrays that are offered in more civilized sophisticated programming languages. There's simply no getting away from lists. And reading about them once won't help; you have to learn to manipulate them, access their elements, convert them into other forms, etc. A week spent mastering what lists are about will, in the long run, save months of frustration while you agonize over your own or some other's code trying to pinpoint something. Besides, once you have studied lists, you won't have to again! It's a one time chore that may, at the most, require a little brush up every once in awhile. And, when you first encounter vector, you'll find a short, concise definition of it that shows you how to access the elements within it using the .x, .y and .z suffix notation. And, after a few minutes of study at http://wiki.secondlife.com/wiki/Vector , everytime you encounter a vector in code, you'll know what that's about. Anyway, there really is no substitution for study and the wiki is written in a way to aid you if you so choose. I encourage you to do so since you seem serious about learning programming and have some great ideas to implement. Stick with it and if something you encounter needs clarification, someone here will be glad to help.

http://community.secondlife.com/t5/English-Knowledge-Base/How-to-report-a-bug/ta-p/733545#Section_.3

Open Windows Explorer. Upper Right corner is the search option. Enter "SecondLife.log" (w/o the quotes) and search your C: drive. It's there somewhere.

Not familiar with your program but the log the error message is refering to is named SecondLife.log and (on Windows) can usually be found in C:\Users\<YourSystemUserName>\AppData\Roaming\SecondLife\logs\SecondLife.log This contains a verbose description of your last session, including many silent warnings and errors. It's a plain text file so any text reader can be used to open it.

See http://wiki.secondlife.com/wiki/LlAttachToAvatar and http://lslwiki.net/lslwiki/wakka.php?wakka=llAttachToAvatar .

greek Wingtips wrote: I have to admit when I do start a thread in the forums its sometimes is a moan or a dig or a complaint, ... So, which is it this time? Nevermind, I could care less... I just envy your all-over-tan from having the sun revolve around yourself.

http://www.metabolt.net/metaforums/ Good luck with your project and let me know when you're done- I'd love to see that! And if you do have any problems or specific questions regarding lsl scripting along the way, this is the forum to bring it to.

Ronald Greybeard wrote: which of these would cause a high land impact, a high vert count or a high face count? say i have a model with 4000 vertices and 3000 faces which would cause the land impact to go up? There is no answer to the question as you word it. Land Impact is neither dependent on of the number of vertices nor the number of faces in a model. Land Impact is simply the highest of three factors which are independently computed; Download weight, Physics weight and Server weight. To illustrate- here's a cube subdivided to have 12,888 faces and 6,534 vertices. It's Land Impact would be 0.5 (which would be rounded up to 1 inworld as long as it wasn't linked into anything else). That is being set by the default Server weight, which predominates in the way I have chosen to define the LOD's and Physical model. Why is the Server weight setting the LI? Because I've stomped on the medium, low and lowest LOD's, smushing them to 2 triangles. And, the rule is- the lower the LOD- the greater it contributes to the Download weight. Since it's only my highest LOD carrying any complexity of geometry, it has very little influence, not enough (in this case) to nudge it up past 0.5. Of course, if I had scaled up my model, the Download weight would've increased because that's another factor being considered here- the size of the model, along with the geometric complexity of it. I also stomped on the physics model (shown within the preview) to match two triangles, keeping the Physics weight below 0.5 as well. So, the highest factor of the three, in this case, is Server weight and that determines my Land Impact. It's a juggling act, trading off one thing for another to arrive at workable combination of values that gives one the best Land Impact for the best inworld representation of your model. And clothing, attachments, furniture and houses all have differing considerations. There is no one size fits all- each model must be individually worked with. A good mesh craftsperson is simply one that has learned to properly juggle the geometry of their model (making it where every face counts and there are none unnecessary), the textures applied to it (to give the illusion of depth or geometric complexity where none exists) and the numbers available to them at the time they upload it (realizing, for instance, that an interior wall will never be seen at its lowest LOD). There is no and never can be a simple answer that fits all cases.

If your objects are found not to be phantom, then it is possible that your avatar itself has been set that way (according to the best authority). If you're using the firestrom viewer, use CTRL + Alt + P or or you can go to Avatar >> Movement >> Phantom to toggle yourself back on. If you're not on Firestorm and the objects aren't phantom, then try sitting on something and then stand back up. Of course, if your objects have all gone phantom on you, Open your edit window and do mass box selections and set the groupings to not phantom (may require 2 clicks if some objects aren't phantom, one to set the grouping and another to clear it).

joeyblueyes wrote: Hi All, In a menu, I'm trying to be able to get and adjust the Horiz & Vert Face Repeats! So far, here is what I've done: vector scale_vector = llGetTextureScale(0); (string)scale_vector Results: <0.50000, 0.30000, 0.00000> OR vector repeats; list params = llGetPrimitiveParams([PRIM_TEXTURE,0]); repeats = llList2Vector(params, 1); llOwnerSay((string)params); Results: 5748decc-f629-461c-9a36-a35a221fe21f<0.300000, 0.200000, 0.000000><0.000000, 0.000000, 0.000000>0.000000 -------------------------------------------------------------------------- My question(s)? 1) Is it possible to get "either" Horiz or Vert parameters separately? 2) Is it possible to increase/decrease Horiz or Vert separately? 3) While using llScaleTexture((float)repeats_u, (float)repeats_v, ALL_SIDES); I am able to change the values, but just "SET" the values! If the prim already has existing values, how can I first get the current values (such as i did above), and adjust those numbers up or down individually? Thanks in advance..... :-) If all you plan to do is change the repeats of the texture, then it would be preferable to use your first choice, llGetTextureScale, avoiding the overhead of dealing with lists. However, if there's a chance that you may at some point decide to change other parameters as well, such as the offset or rotation, it may make more sense to use your second choice, llGetPrimitiveParams, avoiding having to modify your code very much to accommodate that. Alright? 1.) Both choices return the horizontal and vertical repeats in a vector, but you can access them each separately. The first number in the vector (known as the "x component") is for horizontal(U), the second (the "y component") is vertical(V) and the third ("z component") is unused in this case so it will always be 0.0. So, to access each separately, you'd have: // these variables should be global, since you'll need them before// calling llDialog (to show current values in your menu)// and again within your listen() event, when you'll be setting the new // values according to the menu choices madefloat U; // variable to hold horizontal repeatsfloat V; // variable to hold vertical repeatsvector repeats; // using this for the variable name in both examples to avoid confusion// Use this line of code (within state_entry of default) if all you // ever plan to do is change repeatsrepeats = llGetTextureScale(0); // was "scale_vector" in your first example// OR use this if you're to change more than just the repeatslist params = llGetPrimitiveParams([PRIM_TEXTURE,0]);repeats = llList2Vector(params, 1);// in both cases you'll now pull the horizontal and vertical repeats // out using the followingU = repeats.x; // the ".x" suffix accesses the first, "x", component of any vectorV = repeats.y; // And we ignore repeats.z, since it is unused in this case 2.) Within your listen() event and in response to whatever menu choice is made, you'd simply subtract or add to the U (horizontal) or V (vertical) variable. Then you'd plug the new values in using: llScaleTexture (U, V, 0); // not ALL_SIDES unless you want to change the// entire prim and not just side "0", which is all you've queried for before// OR use the following if you've decided to change offsets or rotation as well as repeatsllSetPrimitiveParams([ PRIM_TEXTURE, ... Parameter list as given at http://wiki.secondlife.com/wiki/LlSetPrimitiveParams ... ]); In either case, you'll need to update the repeats variable to reflect the change being made using: repeats = <U, V, 0.0>; as well as rotation and offset variables in the event those are changing as well. 3.) That's, hopefully, clear in the above examples. It's a three step process; get the current values, determine what needs changing and then set the new values. And, even though only one may be changed, you still must deal with both in the vector format. OK? However, if you have further questions or need clarification on anything, do ask. The only dumb question is the one not asked.

Kwakkelde Kwak wrote: I didn't mean to offend you in any way ... No offense taken then. All good in the neighborhhod.

First of all, my initial posting in this thread was being prepared while you posted yours, so I was unaware of your proposal. Your reply to me seemed to be out of line since I was answering not only the title of the thread but the OP's wish to "... make it so that when light is shined on the walpaper, in SL, the patter would reflect the light in a glossy way", which we both agree will not be possible until the materials project comes to be. Secondly, "objects in front of it" may well become an issue if, say, a potted plant is placed within the room. Third of all, you're incorrect in saying "Two walls in prims will add up to a landimpact of 2". Within a link set with mesh, where everything comes under the new accounting, 2 (untortured) boxes will, at most, have a LI of 1, and may well add nothing to the land impact of the object if Download weight is setting LI.

By definition, deprecated functions are both unreliable and may be removed completely at a future date. In other words, though we have had llSetLinkPrimitiveParamsFast since SL 1.38, Linden Labs still fully supports the older versions of the function and plans to do so in the forseeable future.

Kwakkelde Kwak wrote: LepreKhaun wrote: Until we get materials (whenever that might be!) SL isn't able to do glossy, We've had "shininess" for ages.....but it's a "per texture" feature. That's why I suggested the double plane. Unsure why you said that, but in no sense can SL's poor implementation of "shininess" be mistaken for the glossy obtainable with specular mapping. [ Illustrative picture is credited to Tiffy Vella, who is using the SL Mat projects viewer ]

Spinell wrote: Well, the problem with SL is just you never know when things are gonna be released. I mean, is the deformer project still going at all? I've heard LL dropped it, some say it's comming soon. You just never know. I'm not going to just wait idly; I think the best solution is to go ahead with the building and then, when the materials part come around, I'll just update the build. It's not for sale, it's for me, and I don't mind. The main reason why I was asking if it could (at the moment) be done inside blender was simply for prim management, so I don't go over my limit. That said, I will try out the trick with the prims. Now, about the alpha mask: which part should look black in the alpha chanel? The invisible background or the part with the pattern? As long as your build is just for personal use, the 'shininess' hack may be workable. You won't have any problem with z-fighting if your planes are adequately separated and the alpha sorting bug is something we all have to live with in SL so that may be a non-issue for you. And you can set your parcel to always be daytime to avoid the effect from blacking out on you. As far as using prims in your link set with mesh, since the mesh LI will most likely be set by its Download weight due to scaling, prims (specifically boxes, cylinders and prisms) can be used in those cases w/o adding to LI. But discussing the pros&cons of the mesh/prim hybrid in architectural builds has come up before and might be best left to its own thread.

Drongle McMahon wrote: ... Everything will be better with materials (we hope!) True that! And with the release of the project viewer, we may well soon see an entirely different world here. Or, at least, a different set of kludges one must master to create within SL.

Drongle McMahon wrote: Here is a linkset of two cylinders at the same location. The inside one has dimensions 0.005 less than the outer one, and is a solid black colour on the blank texture with shininess set to medium. The outer one has an alpha texture with appropriate repeats. Alpha textures can't be shiny. This is with advanced lighting, but it works without it too. May I remind you that SL's "shininess" illusion only works when the world sun is up. At night, even under pinpoint lighting, one will see this, possibly undesirable in interior decor:

Until we get materials (whenever that might be!) SL isn't able to do glossy, though the effect can be faked. If I'm not mistaken, you're wanting to do Victorian flocked or velvet wall paper on a metallic base ( such as shown in http://fabricwallpaper.blogspot.com/2012/04/velvet-wallpaper.html ). Though Blender can bake specular maps ( see http://www.sluniverse.com/php/vb/tutorials/31727-tutorial-baking-specular-blender.html for one of a number of ways to do that ), it is more effective with 3d surfaces. Since wallpaper is basically a flat surface, I'd make such patterns in Gimp or PhotoShop. In the image program, you'd have a solid flocking layer in the darker of the two colors. For the second, metallic layer, I would go lighter, black on black will not show very well in SL. Perhaps the color combination shown at the top of the illustrations in my first link or a bit darker. On this metallic layer do lighter streaks across it to fake reflections. If you have wall sconces, have halo areas surrounding their location to give the illusion of light reflecting from it. The streaks and light areas should be separate layers for greater control of the effect. Then, it's simply a matter of having a mask layer with the pattern the flocking is applied to the metallic sub layer(s). Make the resulting texture tile-able in the horizontal and you're good to go!