Jump to content

Fenix Eldritch

  • Content Count

  • Joined

  • Last visited

Community Reputation

305 Excellent

1 Follower

About Fenix Eldritch

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. Happy retirement, Oz! Thank you for all the hard work, fixes and features over the years!
  2. That's what I'm thinking, yes. The object in question is probably an invisible attachment with a script which is in a loop, constantly checking to see if the avatar is playing the ground sit animation. When the script does detect the animation, it can change the transparency of the attachment to make it visible and play an appropriate animation to make it look like you're sitting on the attachment. Alternatively, you could set that animation to be your default ground-sit animation with llSetAnimationOverride. You can test this out for yourself with this little demo: //place the script in a
  3. Generally speaking, getting a script to react to a gesture is easy enough. One approach is to use a listen event where the script is listening for a specific keyword on a specific channel from a specific source. For example, put the following scrip into a prim default { state_entry() { llListen(-5,"",llGetOwner(),"ping"); } listen(integer channel, string name, key uuid, string msg) { llOwnerSay("heard keyword '" + msg + "' from "+ llKey2Name(uuid) + " on channel "+(string)channel); } } Then create a custom gesture that has this for the chat t
  4. From SLPPF caveats: If you want to move the entire linkset, use LINK_ROOT. I just tested this in-world with a multi-primmed hud attachment and it seems fine. Do note that if you're just using successive SLPPF calls, the functions may be too fast to get the shake movement you want. You may need to add some artificial stalls to give the effect time to be noticed by the user. Here's my quick demo: (script written/added while the object was already attached to hud center) default { state_entry() { llSetPos(<0,0,0>); } touch_start(integer total_number)
  5. I'm not familiar with the mechanics of breedables, but I presume you'll want to follow Profaitchikenz and KT's advice to maintain a list of detected objects and check against that on each iteration of your sensor. If the uuid isn't already in the list, then we assume it's a freshly rezzed object. So send the announcement out and also store the uuid in a list. The next time the sensor fires, it will follow the same sequence: for each uuid the sensor detected, check to see if it's already in the list. If so, do nothing. If it's not in the list, it's new, so announce and add the uuid to the list.
  6. Adding to Rolig's post, you can turn on a viewer debug setting to check if your object has a script in it which is producing updates - like color changes. Press Ctrl+Alt+Shift+U to turn on the "Show Object Updates" feature. Any time an update occurs, a colored particle will be emitted from the object. Press the key-combo again to turn it off. More info here http://wiki.secondlife.com/wiki/About_the_Update_Indicators Alternatively, if there aren't any scripts in the object but its colors continue to change, then it may be the result of a texture animation, which is another prim property th
  7. The trick in this scenario is to grant PERMISSION_ATTACH to the attachment object before you place it into the rezzer's inventory. That way, each new instance will be a copy of the object who already has the permission given. The state_entry event won't trigger when the object is rezzed from the rezzer, only the on_rez event. A simple proof of concept for the attachment script: default { state_entry() { //request permission when script is first started llRequestPermissions( llGetOwner(), PERMISSION_ATTACH ); } run_time_permissions( integer vBitPerm
  8. Rider Linden has a thread in the EEP forum which outlines the LSL hooks. According to that, llGetTimeOfDay should be EEP aware.
  9. Tread carefully here - because something like this can very easily venture into griefing territory. It would be advisable to make sure all who participate in this are aware of what's going on and agree to it. Otherwise you may find yourself on the receiving end of abuse reports. There are a few approaches, though all of them have different drawbacks and limitations. I don't think any of them are any simpler than what you are already doing - though I am not familiar with using RLV. llTakeControls has the ability to disable avatar movement controls depending on the value of the pass_on
  10. So if I'm understanding you correctly, you're saying you do something like this? Read a notecard line into a string. Split the string into a temp list with something like list temp = llParseString2List(notecardline,["|"],[]); Add this temp list to a combined list. You called it "Name" in your above post. Repeat steps 1-3 until you've read all the notecard lines you need. Attempt to treat the combined "Name" list as a strided list to build a menu. But you hit problems because the strides are not consistent. Is that correct? If so, you can inject a dummy e
  11. Unfortunately no, particles do not have the ability to collide with and react to solid objects in the way you are describing. The closest I can think of is PSYS_PART_BOUNCE_MASK which makes falling particles bounce off of an invisible plane set to the height of the emitter's origin. The trouble is this plane is oriented to the region's z axis instead of the emitter's. So that won't help in this case. As an aside, depending on your needs, you may be able to reduce the number of particle systems. A system with the explosion pattern and zero burst speed min/max would create multiple particle
  12. No. You've gone off the rails entirely. Forget about experiences, I regret even bringing them up. They will not help you with where you are at right now. Focus on just getting the teleport example to work. Endure the permission requests each time you reset the script. Edit: "discrimination" are you kidding me? Get out of here with that nonsense. And no, you don't need to be premium to use an experience key. Only to create one. But that's neither here nor there. You have a SLRUL. Contained within that is the name of the region. You must extract the region name from the SLURL before yo
  13. See the Knowledge Base article on experiences for more generic information. It was a passing suggestion, but if you aren't down on the basics yet, then it's probably best to ignore experiences for now. Work on getting more comfortable with the regular stuff first. As with all things, having additional llOwnerSay commands peppered throughout are helpful in debugging. Have an llOwnerSay speak the result of the parsed region name. If you're not extracting a valid name from your SLURL, then the subsequent call to lRequestSimulatorData will be using a non-existent region name, and the dataserv
  14. A teleport freezing/failing halfway might just be a generic network problem. They can still happen once in a while, though it's getting rarer in my experience. Just try again in a moment. If you are using the example from llTeleportAgentGlobalCoords, all you need to do is change the top variable simName to be your target region. In your case you would need to parse "MiddleEarth" from the SLURL. I've tried it now and the teleport works fine. The example script as written will ask you every time it is reset. You can move the request out of the state_entry to lessen the immediate ping,
  15. Sorry, I was speaking pretty loosely when I said you can plug that into the other function. I will clarify and edit the above post afterwards. llRequestSimulatorData returns a handler for the dataserver event. You actually get the information you requested in that event, not instantly from the function itself. If you look at the example on llTeleportAgentGlobalCoords, it shows the basic sequence. The script starts by requesting the data in state_entry. When the dataserver event fires, it populates the global variable with the coordinates. Finally, the teleport function is triggered on a t
  • Create New...