Jump to content

Johan Laurasia

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Johan Laurasia

  • Rank
    Advanced Member
  1. 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()
  2. 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 th
  3. 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
  4. 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.
  5. 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 poi
  6. 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 storin
  7. I'd look into llLookAt() http://wiki.secondlife.com/wiki/LlLookAt and llLRotLookAt() http://wiki.secondlife.com/wiki/LlRotLookAt
  8. 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.
  9. 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.
  10. 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 te
  11. Yeah, that's what I feared... ok, thanks. Nice to see you're still around answering questions like the old days.
  12. 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
  13. 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.
  14. 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
  • Create New...