Jump to content

Johan Laurasia

Resident
  • Content Count

    192
  • 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 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); }}
  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 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?
  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 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.
  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 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.
  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 '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?
  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 triggers the default state to be entered which triggers the state_entry() handler. The default state IS a state... Johan
×
×
  • Create New...