O HAI THERE!
This is my first experiment in animating SVG with JavaScript! The image was created in Inkscape, then I edited the XML to add JavaScript code to adjust the arm’s rotation every 35 milliseconds. This is my second JavaScript program ever!
It should work correctly on most modern browsers. If you don’t see the arm moving, you may need to turn on JavaScript. If you don’t see the image at all, you should upgrade to a browser with SVG support, like Firefox or Chrome!
Tags: chibi
I’ve written an LSL script which “serves” custom-generated HTML via a neat trick I discovered. But don’t bust out the champagne just yet — this method is extremely limited, so I don’t expect this to revolutionize HUDs or anything like that. Still, it’s a fun curiosity.
The trick is this: If you use text of the form “data:text/html,[html code here]” as the web URL, Firefox (and maybe other browsers?) will render the HTML code as a web page. For example, visit data:text/html,<html><body><h1>Oh hai!</h1></body></html>, and Firefox will render the words “Oh hai!”. It’s not accessing a web page, and it’s not loading a local HTML file, it’s loading the HTML code from the pseudo-URL.
The same trick works in SL as well, by setting the parcel media URL to the “data:text/html” string. You can use an LSL script to generate the HTML code and set the parcel URL, or even set the URL for an individual avatar. The result is that your LSL script acts as a very simple web server!
However, as I mentioned, there are some serious limitations: SL won’t let you set the web URL to a string longer than 254 letters! That means you have to cram all the HTML code into that tiny string, which severely limits the complexity of the HTML you can display.
Another problem is that the method may not work for other web engines besides Firefox / Mozilla. Linden Lab is (or was recently) working on switching to WebKit, the engine used by Safari, for rendering HTML. That’s good news, since WebKit is some great software, but this little trick might stop working when they switch. So, I wouldn’t rely on it.
So, I don’t expect this method to be more than a silly toy for programmers to play around with. But it is that! And on the plus side, there are signs that we might get proper HTTP server functionality in LSL sometime in the future, which would be a great boon to many scripting industries in SL.
You can get a full-perm copy of the object and script in SL at my sandbox or copy the following code (below the fold, if you’re viewing this on my blog front page) into an LSL script in your own object (in which case you should apply the “*Default Media Texture” to your prim from the Library, or you won’t see anything). Continue reading »
The problem: runtime error handling in LSL is… well, it’s practically nonexistant. If something goes wrong, the script will usually shout some message to the world and then die. The obvious problem there is that you have to then manually restart the script and lose all data! Also, for the security-concious, it can potentially reveal implementation details of your script.
Idea: a new event in LSL, error, which would allow scripts to intercept and deal with error messages in a sane and consistent manner. Here’s an example:
default
{
state_entry()
{
integer a = 1/0;
}
error( integer type, string message )
{
if( type == ERROR_MATH )
{
llOwnerSay( message + "You should have paid more attention in math class." );
}
}
}
The two parameters for the error event are the type, which is one of a selection of integer constants, and the message, which is a human-readable message describing what went wrong. In this case, the type is ERROR_MATH (indicating a math error), and the message would be something like “Error: Division by zero.”. The output from this script would be a message to the owner, “Error: Division by zero. You should have paid more attention in math class.”
Some more useful (and less insulting) ways of handling errors might be to reset the script, send an IM to an assistant shopkeep, clearing some buffers to free up memory, giving a custom message on chat, or some other appropriate behavior for that particular application. If the script doesn’t define the event block, errors are reported in the default way, as they are now (e.g. shouting the error on the debug channel).
To complement the new error event, would be a new function for triggering errors: llError( integer type, string message ). When called, it triggers an error of the given type, using the given message. If an error event block is defined, the error is given to that block to be handled; if there’s no block, it’s handled in the default manner for that event type.
A second new function would be llNoHandleError, which behaves like llError, except that it always performs the default handling, bypassing the error event block if it exists. This could also be used within the error event block to “pass through” event types that it’s not intended to handle.
So, scripters: give me some feedback on this. Should we make a JIRA for this, or is it actually a really stupid idea?
Tags: scripting
void reload_vertex_shader(void *)
{
//THIS WOULD BE AN AWESOME PLACE TO RELOAD SHADERS... just a thought - DaveP
}
(Made me chuckle. From indra/newview/llviewermenu.cpp in the SL client source.)
Heya, everybody. I wrote a somewhat useful LSL function, and I wanted to stash it somewhere that I wouldn’t forget it. Then I thought, “I’ll just make a blog post, and everybody can benefit. Maybe I’ll get some suggestions on how to improve it, too.”
So, here you go: it’s a function to create a new list of a certain size, filled with zeroes. This is such a small and rather obvious function, so I hereby release it to the public domain. Yay!
// Create a new list which is filled with +length+ 0's.
list generate_filled_list( integer length )
{
list new_list;
integer counter = 0;
// Fill it up 10 at a time, until we have at least enough.
for( ; counter < length; counter += 10 )
{
new_list += [0,0,0,0,0,0,0,0,0,0];
}
// Return only the needed amount.
return llList2List( new_list, 0, length - 1 );
}
Recent Comments