Babbage Linden asks: what can LL change in LSL to reduce lag?

Been writing microkernel code too long myself, wasn't thinking about UNIX user space code! Tsk tsk.

I've seen no reason not to believe the Top Scripts numbers. Why do you believe the "Script time" numbers and not Top Scripts?

It's more that I see no reason to assume they're accurate, so if they're showing something that looks unlikely I'd want to verify that it's not a measurement problem.

Spent too much time micro-optimizing stuff that wasn't actually in the critical path to trust any instrumentation I haven't at least eyeballed the source for. That's why I loved ATOM, I could see exactly what I was inserting into the image.

I don't understand what you mean by believing script time numbers and not top scripts. I'm not assuming that ANY of the instrumentation is accurate.

LL surely don't believe it's especially accurate, and they can see the code!

They could eliminate the the group notice that goes to the sender .
afterall the sender knows what it says and has the landmark and or attachments, that would stop prob, a 1000 notices a day, which would free up server resorces. would it not.

If I sent out a group notice and didn't see a copy, I'd log in as an alt and make sure it went through. Even if that was how things were expected to work. That group notice to the sender is important feedback.

nevermind that it may ultimately cost more to filter it than to send it.

I have no idea how much time is spent doing string processing, but there are some string functions in the wiki being done in LSL that could be made into "native" LSL functions. That would speed them up, correct?

http://wiki.secondlife.com/wiki/Library_Combined_Library#str_replace

It's things like Trim, Replace, and so on.

There are bound to be a number of other functions in the wiki written in LSL that could be made into "native" LSL functions and speed things up.

like last index and multi find (which I added to the wiki, that are very clunky for strings and lists but about the best we have)

Didn't they already add Trim?

Replace is a good one.

How about:

string new = llRegexReplace(string old, string matchexp, string repexp);

Eg:

llOwnerSay(llRegexReplace("Torley Torgelson", "^\([^ ]*\) .*", "\1 Linden!");

Object: Torley Linden!

A bit off topic but also:
- move default camera positioning to the viewer
- support collision hulls/partially-physical objects

Both of these could be big wins for the sim CPU...

I would SO love to have Regular Expression matching, especially in a way useful for list (but that would need type inclusion, so I won't hold my breath)

the current trim only works on spaces, it'd be nice to have other character possibilities, and Get sub string already covers arbitrary trimming.

I don't know if this ever got notecarded to Babbage or not, so I'll go ahead and make a comment, just in case.

In regards to this:


The Text property of a prim is non-volitile, is 255 characters long, can be set to full alpha so it's not visible, and is easily set.

All that's missing, to make it SOOOO usable, as I and others have said for several years now (and yes, on the JIRA) is to add a llGetText command so we can read as well as write the Text property of a prim.

I never have understood why that was left out.

This thread was linked-to in a comment to his recent blog post. Dunno if he's come by and seen it, though.

agreed, no set w/o get and vice versa.... and I'd extend that to the edit UI too... I can't think of the number of scripts that set some hidden prim property that get left in doing nothing because of inexperience.... which could be eliminated by an advanced edit mode that could set it... even something as simple as a list like is done in debug for the viewer.

ETA:
I wonder if that would only require a viewer mod, or if the server is not set up to accept viewer input on those properties... probably the latter.

Yes, but each time you change it, it sends an object update to all clients. It would be better to have something purpose-made for storing data, which doesn't need to be communicated to clients.

Can't be viewer side only; the script runs on the sever. If a function ain't implemented, changes to the viewer have no effect.

For example, there's an llPointAt() function. Someone talked about fixing the viewer to support it, but someone at LL looked at the server code and pointed out that the server code implementing the function does nothing, so the viewer gets no indication.

I was wondering the opposite.. if it's only available on the server via scripting engine, or if there is instruction along with the other prim properties that could be accessed from the viewer as well.

Not sure what your question is.

We're talking about scripts. Scripts run on the server and (outside of using something like the Restricted Life bridge) don't have access to the information available to the viewer.

Many object properties live on the server but are passed to the viewers. "Client side scripting", bots, and the GUI could all make use of this information, but except for using something like RL API, it's only available to scripts in objects if it's available via LSL calls, which must be implemented on the server.

Furthermore, we'd want to be able to have objects that keep working even if no viewer is viewing. (Of course, we'd also like the ability to shut them down if nobody's nearby.)

What's the ETA on C#?

Next summer, maybe, last I heard.

I was wondering, since all those other prim properties are exposed to the viewer UI,
if some of those that weren't showing were ALSO exposed. it was part of the statement about there needing to be get/set pairs for everything, including in the UI