Jump to content

Jenna Huntsman

Resident
  • Content Count

    136
  • Joined

  • Last visited

Community Reputation

95 Excellent

About Jenna Huntsman

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. This is a pretty silly way of doing it, unfortunately. The best way I can think of off the top of my head (that does mean to say, there are probably better ways than this!) is to have the script do a HTTP request to a dynamic DNS address, so the URL of the domain is actually irrelevant and will always point to the correct IP of wherever the server is located. This means you don't even need to update if the backend domain changes, as long as the Dynamic DNS is kept up to date. This does, of course assume that the server is not the issue however. With that said however, it's inexcusabl
  2. Just to add on to this: What KT said is correct. RLV cannot address any given item in a folder. *but* In both RLV and RLVa, they support 'nested' folders, which means that if you have 1 item which may control attachment or detachment of multiple items individually, you can use subfolders from the #RLV folder, e.g. '#RLV/MyDevice/Item1' and '#RLV/MyDevice/Item2' which offers a convenient way to avoid pollution of the main #RLV folder.
  3. True. What is reported to any interested parties is always the memory limit, rather than the current (actual) memory size, so if you're stopping scripts to try and get around memory restrictions (e.g. orbs which will kick someone for using X amount of script memory), stopping the script won't work as the reported memory use is still the same as if the script was running.
  4. @clear=attach,attachallover:<folder path>=force Would be the correct command. Specifying attachallover twice is redundant, but specifying attach (a different command) would clear any restrictions related to attach, as well as the folder specified as part of attachallover. The =force suffix is functionally the same as RLVa's =y or =n. Both work, but it's just telling RLV to execute regardless of any other restrictions (to my knowledge).
  5. From my knowledge, they keep their reserved memory but don't take up any CPU time when not running (or at least, take up the minimum amount possible, which I think is around 0.003ms). Note that the reserved memory is either the default amount, (16k for LSO, or 64K for Mono), or whatever was last set by llSetMemoryLimit
  6. Definitely, I think my brain fried while reading that! 😅
  7. Assuming the magazine is an oversized prop item, and that the page is a mesh separate to the main model, you could probably make use of llSetKeyframedMotion to make the page turn. Might not look as natural as an animesh solution or the multiple mesh 'frames', but would be a relatively efficient way to achieve a smooth page turn without jerkiness or stupidly high LI. (The negative being that the page wouldn't bend as real paper does as you turn it)
  8. I wonder then, if you have the sleep interval at 2 seconds, and add a check before getting perms to check if the region is not the expected one (e.g. if(llGetRegionName() != myRegion)), if that passes, then request perms, if not, then jump before the sleep to add 2 more seconds, and this will repeat until the check passes.
  9. You can remove the Die() from the run_time_permissions event as that will never work (as Lucia reminded me earlier!). No idea if this will have any affect on the detach behaviour, but I wonder - if you replace the llGetAttached() call in run_time_permissions with an integer representing the attach state (so you may need to add an attach event) - so instead the if(llGetAttached()) becomes if(isAttached) - Reasoning is that llGetAttached() can return 0 if 'the object is not attached, or pending detachment', meaning the check won't pass. My gut feeling though is probably an inventory bu
  10. Not sure of how practical this is, but the idea that came to me for how to approach is: Using HTML-on-a-prim, you can build a webpage entirely within an LSL script. All you need to do is create a webpage which has a blank plate background, then using some stylesheet code load a font from a service (like Google Fonts), then generate a plate dynamically (e.g. script can retrieve data from an experience, which stores the plate number of a given vehicle). Nice thing about this is, the font is going to look higher resolution than the equivalent font table. If you wanted to get really fanc
  11. My mistake. Forgot that llDie doesn't work on attachments (oops!).
  12. Sounds like an inventory bug. Happens every so often. With that said, if you're looking for your HUD to be attached only when in region (x), why not use llDie()? This does not require any additional permissions, but functionally will detach the HUD (It would also delete it from the user's inventory, but as it's a temp attachment this does not matter).
  13. Just to add some info about how the RezBall code can use this: Essentially, the Radial (/ offset) is the length of the Hypotenuse - so using the code from @Profaitchikenz Haiku to calculate the hypotenuse between the emitter and the ground plane, you can feed the resulting hypotenuse into RezBall and it will then always rez the fireball on the ground. If you're calculating using coordinates, you can actually simplify the calculation a lot if you already know the coords of the destination using llVecDist, which will return a float value (in meters) of the non-negative distance between
  14. Chances are then that you're using an old-style AO which uses a timer to poll the server to ask what you're doing (see what Nalates posted earlier). Unfortunately with AOs there isn't always any way to tell which style you're using without opening up the scripts to look. If you're feeling adventurous, I've got an AO which I've been working on for a while if you want to do some beta testing. (Which uses the new-style LSL commands to 'replace' your system animations, again see what Nalates posted!) Alternately, see if you can learn how the AO built into your viewer works!
  15. This. Animations only really are to blame if you're seeing jerky transitions between, for example stands - this often happens because at the end of a given animation, the avatar doesn't return to a 'neutral' state, thus when the new animation is started, the avatar will jerk into place. Animations not starting is usually down to dodgy scripts within the AO. Some AOs have mod-enabled scripts which, if you're familiar with LSL, you can fix. *very* rarely you may encounter a delayed start to the animation due to the asset server being slow. Usually stopping the animation and starti
×
×
  • Create New...