Join us in Outworldz at www.outworldz.com:9000 or follow us:

Search dozens of selected web sites for OpenSim and LSL script

New! Script Meta-Search will search thousands of scripts here and at other sites for LSL or Opensim scripts.
Loading

Want to add a script or a project? Upload it and a half million people will see it and your name here this year.

Home   Show All
Category: Description: Creator:
Viewer 2 Although the 'XMLHttpRequest' Javascript function does not work across different domains, the following LSL Script below gets around this problem! // By using Javascript and HTTP-In, the Javascript calls the prim HTTP-In URL. The LSL script (http_request event) then calls to another website to return data from it. When the website returns the data, the "http_response" event it sends a page response back with the data via the HTTP-In method. The response contains the Javascript function to be called with the data to be shown in the webpage. // // The script below obtains the latest Moon information. If you press the Click Me button every one minute, the information will be updated.
Viewer 2 What it does is to show a web page with a button and field. If you click on the button it shows the latest Unix Timestamp in the field. // // The web page is produced via the LSL script. The Javascript function calls the prim HTTP-In URL to return a function with the Timestamp. // This is not the usual way of doing Ajax, as I had some problems using the 'XMLHttpRequest' object approach. I believe it could be a cross-domain issue. This alternative way creates a HTML Script element tag, and references the prim URL for the Source code. The code calls a function back in the main Javascript code to return the data. // // I'm sure there could be other uses of Ajax in LSL. But have to be careful of the 1024 character URL limit. // // Thanks to Tali Rosca for getting the ball rolling on using Javascript to get around limitations!
Viewer 2 DESCRIPTION: []::Bootstrapping_HTML_on_a_prim
Viewer 2 Press enter to accept Project Name or type a new descriptionalling_external_JavaScript_functions
Viewer 2 The browser will add scroll bars if the rendered HTML doesn't fit within the specified PRIM_MEDIA_* size.
Viewer 2 Tali Rosca made this code to render the output of HTTP-In directly. Kelly Linden wrapped her magic into the build_url and build_response functions in the example below. This example renders a page that is around 3.5k bytes - well past the 1k limit of urls. // Pros: // // * Navigation is much smoother and feels more natural // * Only limited by script memory // // Cons: // // * Links are extremely large: 296 bytes for a link to just the base http-in url.
Viewer 2 Method #1 — using CSS in a style element in
Viewer 2 Method #2 — using background attribute in
Viewer 2 Method #3 — using style attribute in
Viewer 2 Display_an_image_works_with_animate
Viewer 2 Press enter to accept Project Name or type a new descriptionDisplay_plain_text__XyText_replacement
Viewer 2 The text of the data URI will be %-hex-escaped automatically for you, so there's no need to use llEscapeURL(). All you need in the data URI is the prefix data:text/html, plus your HTML.
Viewer 2 The following LSL Script reads a notecard that is over 3300 characters in size, and renders the HTML. // // How might this be possible? This is basically using a combination of Javascript and HTTP-In. // // * The script reads the notecard into memory. // * The script also gets a HTTP-In URL. // * It then displays a webpage that contains 2 DIV tags, and automatically runs a Javascript function on Body load. // * A Javacsript function creates a SCRIPT tag inside the first DIV tag which points to the HTTP-In URL to request the first 1900 characters from the script. // * The script responds with the data, and a different Javascript function dumps the data into the first DIV tag. // * The Javacsript function then creates a SCRIPT tag inside the second DIV tag, and gets the next 1900 characters. // * The process is pretty quick and you will see the HTML data straight away. // // If you are creating a webpage that is over 1000 charaters in size, and want to use this way of rendering it, then you will have to check the characters around the 1900 character mark. If its in the middle of a HTML tag block, the end part will not used, because it will be placed inside a DIV tag. // // With further tweaking, you could use a For Loop to create several DIV tags and show even more data.
Viewer 2 Example notecard, text copied from Wiki (http://en.wikipedia.org/wiki/Second_Life), adjusted to fit 255 characters per line, with some HTML tags added.
Viewer 2 Force_a_page_reload
Viewer 2 The Limits // // * 1024 bytes per url // * llEscapeURLs means non-alphanumeric characters are 3 bytes (ouch) // o I'm actually not clear on if this is really needed. I seem to sometimes get blank pages if I don't but some pages render fine with out it. Maybe there is a subset of symbols that must be escaped and escaping only those would ease some of the space constraints? // * Must force another page view after form submission since HTTP-In can't generate HTML // * No real way of knowing which avatar is interacting with the HTML // // The Tricks // // * // o HTTP-In urls are long, especially if escaped. In a page that includes more than a single link back to the script, or more than a single form, this can save a lot of space. // * Tiny urls // o You can use url shortening services to create short links to long data urls. In theory this should let you get past the 1k limit quite nicely, however there is overhead in setting up the tiny url.
Viewer 2 Google_Chart_demo
Viewer 2 This script puts the data in the URL, and can render the HTML tags from the notecard. Note, the URL limit is 1024 characters. This script below does not need HTTP-IN to work, and is much simpler.
Viewer 2 Notecard text I used to render the text in the image:
Viewer 2 Javascript_boot_strapping_method
Viewer 2 Link_to_external_CSS_file_forms_example
Viewer 2 llSetPrimMediaParams
Viewer 2 Paste the below into your browser's address bar. // // data:text/html,

This is a test

This is a test

This is a test

// // llSetPrimMediaParams for data: urls // // * Thus you can build arbitrary html in your LSL script and display it on the face of the prim
Viewer 2 llSetPrimMediaParams_using_HTTPIn
Viewer 2 Log_chat_to_a_prim
Viewer 2 * Any URL or data URI can be mapped to a TinyURL. The example above reduces an assigned HTTP-in URL, which is a long one such as: // http://sim4605.agni.lindenlab.com:12046/cap/2b9f06f7-431e-5b0f-9271-2d03bd15370b // // into a TinyURL this size: // http://tinyurl.com/y9etul3
Viewer 2 For people who want to play with the Shared Media feature in LSL, I have developed a script that basically reads a Notecard and outputs the text on a side of a prim. It uses the new "llSetPrimMediaParams" function, plus HTTP-In. So its like a basic in-world mini web server! // // This script is only for demo purposes, so if things like the Region Restarts, the script would need to be reset to get a new HTTP-In URL. // // To set this up you need to do the following: // // * Rez a normal prim on the ground. // * Create a Notecard with some text and place it inside the prim. // * Create a New Script. // * Copy the code below and paste it into the New Script. // * Save and run. // * The web page will appear on Face 0, which on top of the prim. If you do not see the page, click on the top side and it will render. // * If you still do not see the page after a while, try setting the Texture > Media functionality on the top side of the prim. // * If you edit the notecard inside the prim, the script will re-read it, and refresh the URL. // // I added a "?rand=" (with time value) parameter to the URL so that it makes the prim think its a new page and refreshes. // // This new LL function is not officially released, so things may change on it. // // Shared Media does open up many possibilities.
Viewer 2 # This "server-push" technique using long-polling gives an LSL script the ability to modify the web page displayed on a prim. The Javascript side always keeps an HTTP GET open to the prim's HTTP-in URL, and the LSL side responds whenever it wants to with a response consisting of strings of Javascript to be executed by the web browser. For example, this LSL code causes an alert box to pop up on the web page: // // sendMessage( "alert()" ); // // # In the LSL listing above, the yellow highlighting shows the most important parts of the HTTP long-polling mechanism. The green highlighting shows the message buffering on top of that. The blue highlighting is the application code that uses long-polling. To use long-polling for a different application, replace the blue parts. The rest is glue. // # To avoid some subtle WebKit problems when dynamically appending or replacing the first-level child nodes in or , we've made two special
elements on the bootstrap HTML page. The first surrounds the script#sc element that we replace for each GET. The second is at the end of as a convenient place for the application to insert new content that would otherwise go in . // # To make sure that there is nearly always a valid GET request open, the Javascript side starts a new GET after receiving a response, or just before the last unanswered GET times out. // # There are two timeouts hard-coded in the bootstrap data URI: // // 1. The "20000" is the timeout (20 seconds) for when an open GET expires, and should be set to a little less than the minimum of the WebKit outgoing GET request timeout, and the SL-LSL incoming GET timeout. This ensures that GETs are nearly continuous, and the LSL side can always respond to the most recent GET request. This page says the timeout on the LSL side is 25 seconds. // 2. The "500" is a throttle that sets an upper limit to how fast the Javascript re-polls HTTP-in to prevent hammering the simulator. It's a half-second delay after receiving a GET response before starting a new GET. // // # If there's a little gap between two GETs, or if two overlap a little, the sendMessage() message buffering will compensate by queuing up messages to be sent when the next GET arrives. If there are multiple messages in the queue when a GET arrives, the LSL side will concatenate as many messages as possible and send them together. // # On the Javascript side, the GET is not triggered until the