New ll functions coming soon

Strife, is there any way to tell who was involved in the addition of llTextBox? I'd like to call their attention to the jiras, and to this thread, before llTextBox makes it to actual officialdom.

Some thoughts:

The wiki speaks of 'the listening prim' and 'the sending prim', and the distance between them. Using these definitions, the script that contains the llTextBox command is contained in which prim, the listening prim or the sending prim? Surely (using a survey as an example of use) the llTextBox command and the 'listen on channel xxxx' commands are in the same script, in the same prim (unless there is the 'a prim cannot listen to itself' restriction of llSay)??

The wiki says the message is limited to 512bytes, but says nothing about any limitations concerning the text entered into the text box. Is this, essentially, limitless, or will it have the same restriction as llSay (1024 bytes)?

I wonder if 'key avatar' can be extended to 'key group'?

Front

Unless there's some dialogue with the Linden Developers about this I'm not sure this thread will achieve much. Although, perhaps some Lab employees do take an interest in what's said here. Who knows! I have seen a Linden in this forum before, but then I am quite old.

For my part I'm a little bemused that the Lab should introduce new LSL functions without actively soliciting comment from the user community - maybe they have and I just don't frequent the right nooks and crannies.

I do know that Winter has created this Jira entry . I'd suggest any comments should be added there.

I also notice that Strife has now linked several prior 'New Feature' Jira entries to SVC-2406 (some of them with quite a few votes). So, again, I think if you're interested in seeing something happen then you need to head off over to the Jira.

Well, it also made me thing about how we were told LSL was being frozen until after Mono's Release (which is now looking to be in July). So i have to wonder if there is some confusion within LL about this, or if these new funtions are not actually coming until after Mono.

This function could be usefull, but I think they would get far more value out of:

llGetParcelAgentCount( );

there are 10's of thousonds of scanners out there doing nothing more than counting how may people are currently in a club or mall. Add to that all the support scripts that are used to overcome the 16 agent scaner limit and one function could go a long way to both redusing lag and improving a bussiness owners accuracy of information.

Any idea if they'll ever consider optional direction of dialogs/textboxes etc to the link message system instead of chat, or even incorporating a prefix on returned dialog input to reduce the need to statefully manage it?

I put a comment in SVC-1630 to this effect, primarily to reduce the load on 'scripts using other scripts' as I've recently started rebuilding my scripts with a component model and the mixture of chat and link messaging is clumsy at best.

Rather than have llTextBoxDialog() or llRadioButtons() why don't we cut to the chase and ask for llHtmlForm()? It would take a string containing the HTML for the form and return a request ID. When the user clicks OK your script would get a http_response event. You could style it with embedded CSS and pre-populate form elements as you wish. We would need some helper functions for extracting data from the response body.

These look pretty nice. Of course, I could make a list of much more demanded functions which are really higher priority..

llTeleportAgent
llGetAgentKeysInParcel / sim
llGetLinkPrimitiveParams
anything to control agent rotation
llApplyLayer
llStopLag

the last one is a joke, of course..

This one is redundant, my Avitar "stops and lags" every time it enters a venue with more than 20 people

On a more serious note, I am supprised that no one else has commented on the llGetParcelAgentCount( ); as opposed to llGetRegionAgentCount( ); post that I made earlyer. Am I the only one that sees the need, or do others have a beter solution?

I think the problem is, that a lot of that stuff is easier to deliver on a "region" level, and the parcel level is kind of server intensive. I WOULD personally have liked to see a "UUIDS" option for the agents in a region, which could then EASILY be cross-connected to a "llIsOverMyLand function.

llAddToEstateBanList()
llRemoveFromEstateBanList()
llAddToEstatePassList()
llRemoveFromEstatePassList()
llRegexFind()
llRegexFindReplace()
llRegexParseList()
llOwnerSensor() (scan for objects owned by...)
llOwnerSensorRepeat()
...

Ohhh yes, Regex would be sweet I haven't thought about that algorithm in years, thanks for tweaking my brain...

We are unlikely to see regex functionality until Mono. Why? Because .Net regex syntax is different then PCRE. When Mono roles around, I will be the first one nailing a function specs to the door of Linden Lab.

I'm sure these will all come in handy.

Thanks for the Heads up, Strife

Two months and I haven't seen anything about this. Anyone know any newer information? Have we received an updated release estimate anywhere that I've missed? (Sorry, impatient mood this morning. Heh.)

Last I heard they would be in the 1.21 RC client. But don't know if that's still the plan.

They is a good chance we will see them eventually. They have already made it in the compiler on the release branch and the server code. It was mentioned on the blog that llGetAgentLanguage was functional with supporting clients in the latest server release. There has also been some bug reports with regards to the llDetectedTouch* functions with regards to the beta grid. For the llDetectedTouch* functions to be added the other functions had to be placed in the compiler (or the function ID numbers would collide or not mach up properly resulting in broken scripts and a huge mess).

http://svn.secondlife.com/trac/linden/browser/release/indra/lscript/lscript_library/lscript_library.cpp#L440

I hadn't heard about any bugs with the llDetected touch, they seemed working to me when I tried them this weekend.

I took the Preview viewer from the beta grid to the Main grid, while it would compile scripts with the new functions, they wouldn't run, giving a "Bounds check" error. So it seems there is still something missing on the server side in 1.23.

I love the idea of llTextBox - it will allow many user interactions to proceed much more cleanly.

It will allow dialog selections to prompt directly for additional infomation (rather than the present messy system of soliciting responses through chat channels).

BUT: I would like to propose something for consideration: Adding a "prefix" string which is passed out and then returned along with the user's text.

This would allow context information to be associated with the reply - allowing the script to action it without needing to maintain additional state information.
This is especially useful when a script can support simultaneaous dialogs with multiple AVs...

Second Life Service - SVC > LSL: Add "prefilled" string to llTextBox
https://jira.secondlife.com/browse/SVC-2406

Second Life Service - SVC > LSL: llTextBoxDialog
https://jira.secondlife.com/browse/SVC-2405

Please vote.. and if you know a Linden.. tell them about these jiras.

I would like to vote
But how do I do that?
I visited the JIRA but found no field for voting

You have to login to jira with your SL username & password to have the vote option.

And when my account name and password 'can not be determined to be authentic', what do I do then? (same account name and password I use every day to log in to SL)
(Christ you know it ain't easy...)

LL was having login problems that might have affected the jira login as well.

The "'can not be determined to be authentic" probably has nothing to do with your account in particular, and most likely you will be able to login when the system gets back to normal.

Excuse me for being so helpless.
The jira just seems so overwhelming.
Thank you for your time and advises.