Jump to content

Wulfie Reanimator

Resident
  • Posts

    5,725
  • Joined

Everything posted by Wulfie Reanimator

  1. The point of the test would be to figure out what (external factors) it takes for a specific notecard to get uncached. Time is very clearly not a factor we need to worry about, so I wonder if more cached notecards would push off the one that is currently cached. Worst case, I'll just wait for Tuesday. 😋
  2. The good news is that notecards seem to stay in cache for over 80 minutes when untouched. The bad news is that I can't easily test something funny like caching thousands of notecards (to see if I can force a notecard to get uncached) since the beta grid is pretty inactive. Any clever ideas for something like that? I tested the function in Leafeon.
  3. Because the function has to return immediately. If the notecard isn't in the sim's cache, the sim needs to fetch the asset first, which takes time and why llGetNotecardLine uses the dataserver event.
  4. I'm okay with those cases existing. The only thing I'd worry about is the most common one -- sim is doing operating normally, no major lag, cache isn't flooded, and the script is just looping the notecard into memory. If that's where caching can catch you out, that'd be bad.
  5. Emphasis on simple loop-read. I'd like to think that notecards are cached for longer than a few seconds -- at least 30 or 60 seconds. If they're cached for less than a second (and not "refreshed" by sync reads), to the point where an interrupted loop is enough to cause reads to fail, that would be a really unfortunate reality.
  6. That's exactly it, similar to how the little red arrow works after you teleport somewhere. You'd have to keep updating the marker's position though, which isn't as fast as the viewer's camera, but not terrible either.
  7. This is exactly right. People have already been using custom functions for this, the new function just frees us from doing the math in LSL (and is much faster as a result). The most basic use-case is an indicator on your HUD to highlight something you can see in-world. The function is useful for many kinds of interactivity between the HUD and the world.
  8. I can't imagine there's any chance a notecard could leave cache during a simple loop-read. If there is, the safe-guards we'd have to script around the loop would be a deal-breaker for using it. Someone remind me to ask during the next meeting on Tuesday.
  9. Write out an explanation and copypaste it whenever someone complains. Looking at your store, your product descriptions seem fine, not much to improve there. Customers make mistakes, you're not responsible for them.
  10. You can use CONTENT_TYPE_XHTML to respond with HTML. You have to also include the following, if I recall: <!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'> <html xmlns='http://www.w3.org/1999/xhtml'> <body> ... </body> </html> Your HTML elements can also include style tags.
  11. There's not really anything different between rezzing cars and bullets, so you're good on that front. Sounds like you're just getting tripped by math for the direction?
  12. Whether you have a graphics card by Nvidia or AMD, both of them can limit the framerate of any app (including your viewer) even if they lack a built-in setting for it. All viewers should have a Vsync option (which limits the viewer to your monitor's refresh rate, usually 60), and most third-party viewers should have a "max. framerate" slider. Higher framerates won't cause things to "slow down" or "become hard to control," but can have other effects you won't like, like heat or fan noise. While the region will update avatars/scripts/objects at most 45 times per second (also known as "server frames", "server FPS", or "tick-rate"), many things can be updated much faster than that by your own viewer: camera movement, avatar animations, texture animations, rotating objects, moving objects, particle effects... etc.
  13. Actively do anything? Nothing any other random passer-by couldn't do. Most bots, especially the ones that pop by for a few seconds, are only there to collect data. Bonniebots are a known example.
  14. This is super simple and doesn't require a lot of code, I'm not sure what you meant by "it would suck to double the amount of code" after mentioning llDeleteSubString. string truncateFloat(float f) { integer dot = llSubStringIndex((string)f, "."); return llDeleteSubString((string)f, dot + 2, -1); } Or as Bleu pointed out: string truncateFloat(float f) { return llDeleteSubString((string)f, -5, -1); }
  15. Keep in mind that notecards never change. When you edit a notecard, you're creating a new notecard with a new UUID. If you use the old UUID, you'll be reading the old contents.
  16. Firestorm has a performance tool to genuinely measure which of your attachments take the longest to render (meaning they have the biggest impact to framerate). If can be found under Advanced > Performance Tools > Improve Graphics Speed > Your avatar complexity This will show just how inaccurate Complexity (= ARC, Avatar Rendering Cost) is as a measure of how "well" or "badly" something is made in terms of performance. Just in the picture above, there are 3 attachments with 1000-2000 complexity that take significantly longer to render than an attachment with 39'000 complexity.
  17. Neat, just tried it. It's not great, it's almost detrimental. If you add an animation to the Asset Blacklist (there's a button in the Animation Explorer to do that), Firestorm will check for that animation every second and stop it. The animation plays for everybody until your viewer stops it, so it's not going to prevent griefers from playing animations on you. (Realistically there's nothing viewers can do to prevent this, because animation-state is enforced by the sim.) And while you don't see the animation playing on your screen, other people will. If a griefer plays a deformer on you and you blacklist it, you won't even know when it happens again. The "reset skeleton & animation" option is client-side, so your avatar wouldn't get fixed on other people's screens even if Firestorm did undeform the avatar while stopping blacklisted animations.
  18. Animation permissions cannot be revoked from objects attached to avatars, so the suggested option won't work if the griefer is wearing the object (which is almost guaranteed).
  19. The only things you can do is report them (Help > Report Abuse) and avoid them.
  20. Web profiles are being phased out in favor of the profiles you see in your viewer. You can't change your web profile's picture and probably shouldn't spend any effort in using it.
  21. Link for easier access: https://github.com/secondlife/viewer/blob/77395eddc911e0801e50fd693f7bbaee8046aa95/indra/newview/llviewerobject.cpp#L6907 And yeah, the problem is obvious. It's not smart to make hundreds and thousands of cumulative changes with floats. I'm fairly sure this function could be rewritten to just not track cumulative changes but always calculate the new rotation based on the original rotation + total time passed. Obviously, precision issues will never go away, but this should avoid visible drift over time.
  22. The emitter's rotation affects the direction of particles, easiest way to see that is with Angle Cone -type emitters.
×
×
  • Create New...