Jump to content

Fenix Eldritch

  • Content Count

  • Joined

  • Last visited

Community Reputation

248 Excellent

About Fenix Eldritch

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Maybe I'm missing something, but doesn't the original script already do what you ask? Rolig's else-if is much cleaner logic-wise, but assuming the message being sent is either "+" or "-", the either code samples will happily add or subtract from the total and if the resulting total would be 6, it moves to the win state. Are you expecting something different?
  2. Yes, it sounds like something might have gone wrong during your upload. Maybe you forgot to select the physics model, or maybe there was some error. Hard to say, but regardless, if your mesh doesn't give you the option to set its physics type to "prim" in the build tool, then that suggests it doesn't have any physics shape of its own to begin with. As such, it must default to the auto generated convex hull. For completeness sake, regarding the three physics types: PRIM - makes the prims use their traditional physics shapes. For mesh, it makes them use the physics shape you uploaded it with (if present). CONVEX HULL - a simplified, auto-generated shape that fully encases the object based on visual appearance. Like very low resolution shrink-wrap. Useful for reducing physics land impact at the cost of covering up holes and the like. NONE - no physics shape. Can't be set on the roots of objects. And I suppose I should also mention that for mesh related questions, it's a good idea to start in the dedicated Mesh forum. To be fair, it is possible for a script to explicitly change an object's physics type, but I'd first rule out any potential problems with the mesh itself before looking at the script.
  3. Assuming you uploaded your mesh correctly, it sounds like the physics type property of the prim/mesh is still set to convex hull. Select the individual part in the build tool and check that its physics type is set to "PRIM". It should be in the Features tab of the build tool. LSL reference: http://wiki.secondlife.com/wiki/PRIM_PHYSICS_SHAPE_TYPE Edit: see this page for some additional information: http://wiki.secondlife.com/wiki/Physics_Optimization
  4. Hypothetically speaking, you could set up a system where you have a timer loop that automatically does the following: close the previous listen handler increment the target channel value open a listen to that channel (to listen for any potential response) speak the test message on the current channel repeat The idea is that you prime the test script by starting a 0, opening a listen, and then dropping into a loop governed by a timer event. That way, if you do manage to find that needle in the haystack, the target object will respond and your own test script's listen event will hear that response. Upon doing so, the test script will stop the timer and report to you the value of the channel it used. And then for the negative values, just change the channel increment to a channel decrement as Rolig demonstrated above.
  5. Do you have edit access to the other object's script? I'm guessing that either you don't, or if you do, that the script is not using a hard-coded value for the channel - but instead generating it randomly. Also, do you know how this object will react when it hears something on the channel it listens to? Does it speak? I ask because if it emits its own text chat, you can potentially automate the process and use that as a shutoff signal - stopping when you get the right channel.
  6. Granted, you don't have to cater to those people at work. Now it's during your off time. I wish I had some ice cream right now.
  7. I notice that your function uses a loop, but Haravikk's function does not. That might give their code an edge over yours, since you have to spend additional resources looping through the string to break it up. Haravikk's code on the other hand lets llDumpList2String do the dirty work. But to truly know which is better, you should do additional tests, with different sample inputs and look at the averages. You can find a speed tester on the wiki here: http://wiki.secondlife.com/wiki/LSL_Script_Efficiency#How_Fast_Does_That_Code_Run
  8. I'm being a bit slow today, having trouble fully comprehending the flow of the code. But there are a few thoughts that come to mind. Your code has three instances of calling llDie and another three instances that call llDetatchFromAvatar. Either of these will potentially remove the temp attachment. So I would suggest you add some instrumentation code to see if any of those are being called when you teleport. Basically, stick a llOwnerSay("debug message") line immediately before each llDie and llDetatchFromAvatar function call. Give each one a unique message. This will help indicate which (if any) of these lines are being called when you teleport and narrow down where the problem is occurring. Now if it turns out that none of the above are being called when you teleport, then the issue may be with the other two scripts you say are being added to the prop. You may need to examine them to make sure they're not calling their own llDie or llDetachFromAvatar.
  9. I'm not sure I quite understand what the [AV]object script is supposed to do... don't temp attached objects remain attached normally through teleports? I thought only a logoff would remove them? However, I glanced over the code and the first thing that jumps out at me is your use of llDetectedKey(0). That function only returns meaningful results when used in a few very specific events. From the wiki page: So your error is probably occurring when you try to feed it into the llRequestPermissions function inside your listen and timer events. Perhaps you could replace that with llDetectedKey in those events with llGetOwner, since an object has to be owned by the avatar wearing it. And in the case of temp attach, ownership is transferred to the new target for the duration of the temp attachment's worn existence.
  10. This sounds like it would be similar to a gun script - in that the avatar would create a projectile (bowling ball in this case) and "shoot" it forward relative to the direction they are currently facing in mouselook. The extra catch here is that you'd like to alter the strength of the throw based on how long the user holds the button before firing. Does this sound accurate? Assuming this is what you're trying to do, then you would need to study the control event, as this that would be what is responding to the user's button presses. The control event triggers whenever a button is pressed, whenever a button is released, and also continuously while a button as being held down. This can be used to suit your needs quite easily. Generally speaking, you would configure your control event to increment a "power" variable while the user holds down the desired button and then, when the user releases the button, you would "fire" the projectile using the current value of the power variable. You'd also want to reset the power variable to zero when the projectile is fired, to get ready for the next shot. Visually speaking, I imagine the avatar would wear a bowling ball as an attachment in their hand. This would effectively be the "gun". When the player "throws" the ball, the worn attachment turns itself invisible and rezzes the projectile bowling ball simultaneously to simulate the effect of them throwing it out of their hands.
  11. The LSL Scripting forum is more geared towards discussions about scripting and between people trying to write scripts themselves. If you wish to hire someone to write a script, you'll get better responses by asking in Inworld Employment forum.
  12. OP's question has been answered, but I'd like to add one last bit of info for completeness sake. As we can see in the wiki page Qie referenced above, there are a number of internal animations in SL that have additional effects associated with them. In this case, playing the "away" animation will also trigger the "Away" status to be displayed in an avatar's nametag. These additional effects are hardcoded into the viewer (and server?) and not contained within the animation file itself. As such, if you download the animation files and try uploading new copies, they will not trigger those additional effects as listed in the wiki page. Only the internal animations already built into SL will trigger the additional effects. But you can reference them by name without needing to have the assets in your object's inventory (as Qie demonstrated above).
  13. There was a similar problem reported on the bug tracker a few days ago. Though that user had problems removing interests which contained quotation marks. Even so, your problem could be related. https://jira.secondlife.com/browse/BUG-228079
  • Create New...