Wulfie Reanimator

Just guessing, but I can't imagine the bot runners are picking any specific landing zones if they're scraping hundreds of sims. I can't imagine it's a small task to hand-pick "safe" locations for what's basically a blink in that sim. That they land in your parcel is probably related to the location of that parcel within the sim, or whatever other factors LL uses to determine where avatars should arrive.

The original comment I responded to was implying that events could come in and interrupt the loop, which we all now know is not the case.

This blocks events just the same as any other loop/sleep.

Overall CPU utilization doesn't mean much, because SL will not use all cores in your CPU. What does your individual core usage look like?

Noticed really annoying (but consistent) behavior I never knew about. If the last line of a notecard contains text but no newline, trying to read that line will return EOF instead of the text. This happens with Sync/Async and applies even to notecards that only contain one line of text, but no newline. The line cannot be read because the result is EOF. I'm sure someone has to have filed a jira about it, but what's the current status?

Does this actually happen, though? This sounds like a hypothetical that no one has mentioned in the past 15 years. This wasn't my experience while testing, I had to async the notecard first. (Also, the notecard stayed in cache for over 9 hours, even though I deleted the object with the notecard. 😄)

There's no limit, aside from the total memory limit.

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. 😋

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.

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.

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.

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.

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.

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.

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.

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.

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.

"Requires ChatGPT Plus"

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?

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.

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.

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); }

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.

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.

Script time is an average over the past 30 minutes.