Jump to content

Fenix Eldritch

  • Content Count

  • Joined

  • Last visited

Community Reputation

301 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. Rider Linden has a thread in the EEP forum which outlines the LSL hooks. According to that, llGetTimeOfDay should be EEP aware.
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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,
  8. 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
  9. Re-read the specification for llTeleportAgentGlobalCoords again (I'm assuming that's what you meant to say, as there is no llTargetAgentGlobalPosition function). It tells you right at the beginning that the function targets the destination region by using global coordinates and that you can discover any region's global coordinates via llRequestSimulatorData(region_name, DATA_SIM_POS). If you have the SLURL, then you have the region name. Parse it out and feed it to the other function. Edit: ok, you can't feed it in directly. You need to go through the dataserver event, as that is where th
  10. The wiki page for llVolumeDetect I linked above has more details (and examples on how to use) but generally speaking, llVolumeDetect works similar to phantom. The object becomes non-solid and avatars and physical objects pass through with ease. Unlike phantom, the server still keeps track of collisions with llVolumeDetect objects. So when something moves through, it will trigger collision_start and collision_end events for any scripts within the object.
  11. Essentially, you want to play the sound on a collision_start event. Phantom objects do not raise collision events, but llVolumeDetect ones do.
  12. That's pretty much using llSetLinkTextureAnim() as Lucia and Rolig mentioned. But also careful mesh design, particularly with the UV mapping and splitting up of multiple material slots. Most of the signs in that video seem to share some common design element in that each letter (assuming they are separate links) likely has at least two material slots: one for the outline, and another for the solid fill. Take the third sign, "Sarah's Technic Corner" for example. The effect of snaking the light around the letter's outline could be done by unwrapping the outline material slot to be a contigu
  13. You cannot build past 4096 meters in elevation, so I can't imagine a skybox being in excess of 7000 meters high. Having said that, there are a few options for positioning yourself. When an avatar sits on an object, it becomes part of the linkset and can be moved around with the llSetLinkPrimitiveParamsFast function. You could potentially do that to shift the avatar's position and the unsit them. But I believe the practical limit is 1024 (at least that's what I saw testing vertically just now). Alternatively, you could surround the sign with a transparent prim that when sat upon,
  14. By "one system", do you mean a single call to llLinkParticleSystem? If so, that is not possible. The particle system functions are not like the llSetPrimitiveParams functions which can let you target multiple discrete prims at once via the PRIM_LINK_TARGET in the parameters list. There is no equivalent for llLinkParticleSystem. Your only options for that are to use the single link number parameter which can be a specific number or one of the special LINK_* flags. If you want to turn link #3 and #5 into particle emitters, then you need two separate calls to llLinkParticleSystem, specifying the
  • Create New...