List of 50-100 strings, to be sent to avatar; Best way?

[Domitan Redenblack]

Using llInstantMessage( ) would cause a 2 second delay per line, unless I append messages together up to < 1 Kb and then output chunks.

What other methods will allow me to output the set of strings to someone?

nb: the output is certainly going to be much longer than 1 Kbytes.

[Darkie Minotaur]

I guess we are talking cross sim. It's the usual suspects:

• instant message: You could get around the delay by using several scripts to send the junks
• llEmail: The delay is even longer here, but you can send up to 3600 characters
• HTTP: you can send out quite a long string, but a reply is limited to 2048 byte

The difference between e-mail and HTTP on one hand and instat message on the other is, that the latter is send to an avatar, the others to a prim

[Dora Gustafson]

A note card containing the strings would be preferable

[Domitan Redenblack]

---

Dora Gustafson wrote: A note card containing the strings would be preferable

---

I assume there is (still) no way to create the contents of a notecard to send to someone...

 

[Dora Gustafson]

You are not very generous regarding specifications on what you are doing
All you offered is."What other methods will allow me to output the set of strings to someone?"
From this "specification" I can't see what problem you can have with note cards.

Also no one but you knows if you want to send strings grid wide or within a region
If it is within region the llRegionSayTo() would be superior to anything else I guess

If you want meaningful answers you have to put meaningful questions:smileyhappy:

[Domitan Redenblack]

Dora, sorry.

The strings are collected from actions real-time within SL, and then dumped to the owner (or person clicking) on command via some method that is not typically LL constipated or truncated.

 

I do not find any info on llRegionSayTo( )...

 on the other hand, if you mean llRegionSay(channel, message), how could that send a message to me, except into a channel or other non-avatar listener?

 

[Innula Zenovka]

https://wiki.secondlife.com/wiki/LlRegionSayTo

[Domitan Redenblack]

---

Innula Zenovka wrote: 

https://wiki.secondlife.com/wiki/LlRegionSayTo



---

Thanks, Innula. The Wiki lists llRegionSay (only) under chat, so I added llRegionSayTo as well.

[Rolig Loon]

Hmmmm .... Lots of functions are not listed in the summary on the front page of the wiki --- that keeps it from getting cluttered, after all --- so I always go directly to the Functions page, where everything is laid out nice and alphabetically. :smileywink:

And no,  there is no way to write to a notecard.  Probably never will be either, considering the asset storage nightmare that would exist with many zillions more UUIDs to store for all the edited and re-edited notecards people make.

[Void Singer]

I've found that displaying that much information to a person from within SL, you really want to do it via email to account (if it's scheduled) or via http (if it's on demand), doing it via chat history is either slow, or troublesome for the person receiving it

[Domitan Redenblack]

Hmmm....

There is one way to do what I want, messy though.

1. Each time a bit of data is collected, it is sent InstantMessage to the person, who keeps chat logging enabled.

2. Each bit of data has a pattern prefixed.

3. A text editor (BBedit or TextWrangler etc) is used to turn that pattern into a tab (to split up time/date and data)

4. The result is imported into Excel and the data column can then be saved.

Messy, and a hassle, but this will work. Only has to be done 2-3 times a week anyway.

Thanks to all for your ideas and help.

 

[Rufus Darkfold]

Couldn't your SL stuff post the data via http to some place?

 

[Domitan Redenblack]

Yes, would have to write php front end etc, escape the data, make sure server is always up, etc etc

Is there a char limit on posting from SL to http?

 

[Void Singer]

just the script limit... so effectively no more than you can squeeze into 64KiB minus overhead for code...

but you don't need to go external.... you can make lists accessible in plaintext and html via LSL HTTP-in... all you have to do is plug in your variables and serve up a page.... the region stats script for Teacup is an example of doing that.

[Domitan Redenblack]

---

Void Singer wrote: .... the region stats script for Teacup is an example of doing that.

---

Teacup?

[Darkie Minotaur]

See here - I'm still no big fan of http-in solutions where they can be avoided. And in this case, there are quite a few indications that make an external storage preferable.

[Domitan Redenblack]

---

Darkie Minotaur wrote:

See

here

- I'm still no big fan of http-in solutions where they can be avoided. And in this case, there are quite a few indications that make an external storage preferable.

---

Very interesting, Darkie. I had a good look at it, but two questions:

1. Does this require Viewer 2?

2. Does this require the Media URL of a parcel to be set?

[Void Singer]

it's not designed as an end all solution, bu t more to show what's possible... it can be used as solution, but that's not really the point...

to answer your question,s no, not if you back it up with llLoadURL, but it does only work consistently in viewer, and no it uses MOAP aka shared media in general but it'll run on the internal browser too.

if you just display text info though, the setup gets much simpler.

 

@Darkie:
for static pages? sure... for things like live data? not really. for database? definitely. but LSL HTPP-in was always aimed at live data. I've actually found it quite stable which rather surprised me. http-in is well suited  for on demand live data inworld. it's only so-so for live feed aimed outside though.

[Domitan Redenblack]

How does this differ from the much-vaunted "URL on a prim" supposedly available sometime soon in SL? e.g. for more than one TV-object per parcel?

[Void Singer]

estimated variance of +/- 1e-38 from zero.... it uses the same thing (or optionally llLoadURL to the internal browser for viewers that don't support it).

and to be accurate, you could do multiple "tv's" on a parcel before MOAP/Shared media (which is already here and has been for a long time), but with MOAP you don't need to worry about updating addresses, or targeting specific avatars

[Qie Niangao]

Right, but I'm not sure this MoaP direction is taking this thread into productive territory.

As I see it, the relevance of Teacup is just that it serves up pages of information with llHTTPResponse().  Lots and lots of scripts do that, and yeah: that seems a perfect fit to how this problem was described.

If responding to another script, only 2K chars of llHTTPResponse body will make it into the other script's event handler, but (AFAIK) it's otherwise only memory-limited.  I understand that to be what Void said in an earlier response.

One thing Void said that I didn't understand, however, was "it does only work consistently in viewer."  This hasn't been at all my experience with llHTTPResponse() so I'm curious whether I've just been extraordinarily lucky or if "it" refers to something else.

[Void Singer]

"it" in that particular sentence should only be taken to refer to the Teacup set of scripts....

the reason is an because of the hack it uses to load html content, and the fact that the viewer refuses to pass that same content to an external browser.... whether that's a viewer problem, or an OS or browser problem, I'm not sure... but SL is unable to pass "data" URN's to external browsers....

but that limit only applies to html content.... plaintext content works just fine no matter where you pass it from http-in (as does the hotloaded html that teacup uses for everything except the initial page)

[Qie Niangao]

Oh, yeah, I hit that problem headfirst at one point.  Thanks for the clarification, Void.

[Domitan Redenblack]

hmmm.... pardon my ignorance, but does Teacup present the information ON the prim? or in the in-viewer Broswer (which I have never used once in almost 2 yrs) ?

 

 

[Darkie Minotaur]

You can call the information basically from any browser - teacup itself is the server. Ther client could be the internal browser, an external browser, shared media or parcel media.