Johan Laurasia

You have to detect the person and compare that to the creator of the item. You can detect the client by a touch start event... touch_start(integer detected){key toucher = llDetectedKey(detected);} Then compare that to the key of the creator, or convert the detected key to name using llKey2Name()

Not really all that more complex to do lookups if an element is buried in a rotation. Say you want the 27th element in a list: There's 4 "elements" to a rotation, so... 27 / 4 = 6 with 3 remainder, so you read the next element (7th element out of the list) into a rotation, and grab the 3rd value (rot.z), a bit more complex than a straight lookup, but not that difficult to work around. That's a great method to pack a large number of floats using rotations in a case like this. Ok, got to wondering how to code it out, this is what I came up with, it can probably be written tighter, but this is what I came up with... works with 1 as the first list element returning the first entry in the list (not 0). list listOfFloats = [<1.1,1.2,1.3,1.4>,<2.1,2.2,2.3,2.4>,<3.1,3.2,3.3,3.4>];integer elementToGet = 12;float finalElement;default{ state_entry() { integer listElement = (integer)(elementToGet / 4); integer rotElement = elementToGet % 4; if (rotElement == 0) { listElement -=1; } rotation rot = llList2Rot (listOfFloats, listElement); if (rotElement == 0) { finalElement = rot.s; } else if (rotElement == 1) { finalElement = rot.x; } else if (rotElement == 2) { finalElement = rot.y; } else if (rotElement == 3) { finalElement = rot.z; } llOwnerSay ("Final Element: " + (string)finalElement); }}

Thanks for the verbose explanation Drongle, I had already figured out that I can add the extra vert offset so that the registration point is where it needs to be, I was just wondering why things had changed. My memory definitely serves me correctly though. One used to be able to simply edit a mesh and select all verts, and the move the mesh so that the object center would wind up being offset, and it did work throughout beta and even into when it was first released. I was just curious as to why that had changed. Thanks again for the info though. - Johan

link it

how to adjust the pivot point of a mesh object in blender before uploading to SL so that when it uploads to SL, it pivots at the point I set, not the center.

Ok, I've been gone a while, and I understand things change, but this is odd to me. When mesh was first brought into SL, the pivot point you defined in Blender (by editing the object in edit mode, selecting all the verts, and adjusting it's position relative to the object center) was a way to adjust the registration point. Life was simple. So lately, I'm making some things that need a pivot point located other than the geometric center of the object, and, as before, I'm editing the mesh in Blender and moving the mesh to where it needs to be to set the object center where I want the pivot point. However, when I upload it to second life, SL seems to ignore where I set the registration point and rotates the object about the geometric center. What Gives?

A couple of ways to persist data is to make http calls and store the data in a database on a website, or, a much easier way, if you're looking to store limited values, is to store them in the object description. Back in the day, you could cram 16k into the object description, but people started making "hard drives" by linking a bunch of prims together and spanning data across the object descriptions of various linked prims, but SL caught onto that and "fixed" the 16k data store that was the object description. These days, you're limited to 128 bytes, which can be useful if you're just storing a handful of variable data. For example, I make clocks, and you can set the time to any time, which internally generates an hour and minute offset, also the state of the chime feature (on or off) is saved. Hence, I need to store the offsets for hour and minute as well as the state of the chime. The code looks like this: string output = (string)hourOffset + ":" + string(minOffset) + ":" + (string)chimeState; llSetObjectDesc(output); Then when the object is rezzed, in the state entry I read in the object description, and parse out the data and cast them into the integer variables thus preserving the state of variables. As long as the data you need to store isn't too big, this system works quite well.

I'd look into llLookAt() http://wiki.secondlife.com/wiki/LlLookAt and llLRotLookAt() http://wiki.secondlife.com/wiki/LlRotLookAt

It's even a bit easier than stated above. llSetPrimitiveParams([PRIM_GLOW, 2, intensity]); ... will work if the script is in the object with the target face. Also if you need to know what face it is edit the object, select the face you want to know, then hold <SHIFT><CONTROL><ALT> + T and the face number will be displayed in chat.

Coding is much the same. At times, I've looked back at code I wrote a long time ago, and think to myself, what was I thinking? Then I'll go through the code and rewrite it and it'll be much easier to write and tighter, more efficient code as well.

The trade off is efficiency. Mesh is more efficient than SL prims. The reason SL prims are less efficient is because of "ease of use". Take a cube for example. One can create a cube by defining 8 vertices. In a program like blender, you can unwrap the UV map and make it flat, texture each face, and bake 1 texture to skin all 6 faces. SL on the other hand allows in-world editing, so to be able to reference a single face, you need to define 4 verticies per face (times 6 faces = 24). So an SL prim has to manage 24 prims, and up to 6 different textures, whereas Mesh has 8 vertices and 1 texture. You also full vertex control with Mesh, and you don't with SL prims, so you (at times) have to use more than one prim linked to other prims do create a shape that, in Blender, can be done by pushing around verticies.

Yeah, that's what I feared... ok, thanks. Nice to see you're still around answering questions like the old days.

This is one of those "I've been gone for a few years and now I'm back" posts... and I'm having an issue with a script I'm working on. The script is based on this code snippet that I pulled from the wiki show(string html) { html = "data&colon;text/html," + llEscapeURL(html); llSetPrimMediaParams(0, // Side to display the media on. [PRIM_MEDIA_AUTO_PLAY,TRUE, // Show this page immediately PRIM_MEDIA_CURRENT_URL,html, // The url currently showing PRIM_MEDIA_HOME_URL,html, // The url if they hit 'home' PRIM_MEDIA_HEIGHT_PIXELS,512, // Height/width of media texture will be PRIM_MEDIA_WIDTH_PIXELS,512]); // rounded up to nearest power of 2. } default { state_entry() { show("<h1>This is a test</h1><h2>This is a test</h2><h3>This is a test</h3>"); } }When I run it, it works, but not until I interact with the prim by clicking on it. It doesn't print immediately. In the script I'm working on, I'm refreshing the display every 5 seconds, but it still doesn't display text until you click on the display face, then the next time it updates, the text shows. Anyone have any ideas?

Well the default state is assumed, additional ones are not and need to be mentioned. What was being discussed was when to use on_rez() vs state_entry(). The information I gave didn't mention any states, so the default should be assumed, no mention of other states was given. Therefore... in the interest of completeness, When a script is reset, should a state_entry() exist within the default state, it will execute when the script is ran, on_rez() will not. No other state_entry() handlers in states other than default will be triggered.

I disagree. If you make a prim, click new script, open up the script, and start pounding on the reset button, it will print "Hello Avatar!" each time you hit reset. therefore, since the llSay(0,"Hello Avatar!"); function is in the state_entry(), then the handler must be triggering. I don't know any other way to say it, when you reset a script, state_entry() in the default state is triggered. Try it if you don't believe me, I've been scripting in LSL for quite some time. What you're saying is true, it's just that when you hit reset, if the script is set to run, then it begins running which triggers the default state to be entered which triggers the state_entry() handler. The default state IS a state... Johan

on_rez() should only be used when you want to do something at the point at which the object is rezzed. state_entry() when you want the function performed every time the script is ran. In this case it would be proper to use state_entry, not on_rez. While both would work, the on_rez version would break if the script was simply reset. For any script where you're grabbing keys it's prudent to grab them each time the script is ran, not rezzed, hence, use state_entry().

I was going to suggest learning Blender over using Sketch Up. Sketch Up is easier, but at the expense of create a proper model for SL. Blender isin't so tough really. There's quite a few tutorials on YouTube and Vimeo, and BlenderArtists.com is also a great learning resource. Forum members are as eager to help out as you'll find here in the SL forum. I have a few different tutorials myself including a beginner tutorial, and I highly recommend Andrew Price's blender tutorials. Most of them are on YouTube, but are best accessed though his website Blenderguru.com. If you're already pretty good with Sketch Up, getting into Blender won't be that bad. Yes, Blender is more complex, but you can still do simple stuff quite simply. As time goes by and your abilities grow, you'll be able to use the more complex features of Blender. There's also a phyics engine within Blender, so you can, for example, make a tablecloth by dropping a cloth on a plane, allow it to setlle, then apply the cloth modifier and export the resultant shape to SL. My tutes are available on http://youtube.com/johanlaurasia

Well, thrird grade for me was 1971/1972, and believe me vertex, edge and face weren't taught in geometry. We used pencil and paper and the only terms we worked with were point, line, curve and graph (what can be called a face today in 3D modeling was simply referred to as area in graphing). Maybe today third graders are taught basic 3D modeling terminology, but in my day, they most certainly were not. Secondly, with nearly 8 years in SL, I don't need you to quote me what proper terminology is, I probably have much more time in SL than you. My point was about clearing up confusion between textures, faces, and materials, especially amongst newbies. When I see this forum, I see this confustion all the time. I don't "use terminology as I "see fit", I use terminology that's accepted convention within the world of 3D modeling. I understand that SL has it's own terminology, and I think it goes back to the days before mesh and sculpted prims when the only option was in-world building with SL prims. I think LL wanted to simplify 3D modeling and perhaps though using non-standard industry terms would make things easy for the non-professional. "Phantom" properties of a prim is a good example, the industry calls it no-clipping, but phantom is a good description of what the function does. However, over time, things have changed, and it would be in everyone's best interest if we moved towards more standard terminology since content creation is using traditional modeling tools now. The fact that there are so many questions about this stuff within this forum drives home the fact that SL's differing terminology is at least part of the reason some people are confused.

Right, the thing about confusion towards newbies was my whole point, thanks.

Heh, perhaps the reason I'm pushing my point is tied to being used to conventional terms!

You can have separate time events, they just need to be in different states. http://wiki.secondlife.com/wiki/State

Gaia, I see where you're coming from, but alot of people here in SL are newbs to 3D modeling, you one of the biggest educators and contributors here most certainly know that. I think teaching is wonderful too which is why I pitch in whenever I can, but you certainly can see that it's confusing and misleading to refer to materials as "texture faces". Also, as far as SL lingo goes... when specular and bump maps were introduced, Linden Lab themselves call it "Second Life Materials". Years ago, when I first started, I had a difficult time understanding the difference between textures and materials, and I think if we're educating people, we should be using the proper terminology. That's all.

Yeah... I know the multiple meanings of the word face, and specifically, within the realm of 3D rendered objects, the word "face" refers to the area within 3 or more verticies. Never the material applied to it. Are we officially "facing off" here?

All materials are not textures..... 1) All materials are comprised of a series of one or more of what is called a shader. 2) One type if shader is called a difuse shader... this refers to the color of the material. 3) A difuse shader can be either one solid color, like red, green, yellow, bright orange or dark green, or, it can be a bit mapped image like a photograph, typically refered to as a "texture", or a series of colors like a bitmapped image created with a paint program, again generally referred to as a texture. 3) Other types of shaders within SL are specular (often refered to as gloss or glossy) and bump map. 4) Other shaders include glass, ambient occlusion, translucent, transparent, sub-surface scattering, emission (light source), anisotropic, refraction, etc. These shaders can be mixed together using a mix shader as well. All the shaders used add up to what's refered to as a material. So, you see, I can have a glossy red face that has no texture applied to it, yet it's still a material, (and it has no texture).

What you're saying makes no sense. She's talking about faces, I'm talking about faces. SL faces are only "different" from mesh in as much that each prim "face" in SL has it's own set of vertices so one can texture faces individually from within the SL environment, otherwise, SL prims and mesh objects are identical. Making the statement "texturable faces" is not correct terminology for what's being discussed, which is what's called materials. Properly stated. The question should be how many materials can a mesh object have. And, as was stated, the answer is 8. A mesh object can have 10,000 faces, all of which can be set to one of 8 materials. To make the statement "8 texturable faces" is just flat out wrong. People confuse textures and materials. Textures are but one component of a material. A material can be a simple color, or a texture. A material can also contain a specular map, and a bump map. Textures and materials are different things, that's why they have different names, and refering to a material as a texturable face is incorrect no matter how you slice it.