Don't click here unless you want to be banned.

LSL Wiki : llStringToBase64

HomePage :: PageIndex :: RecentChanges :: RecentlyCommented :: UserSettings :: You are crawl423.us.archive.org
string llStringToBase64(string str)

Converts a string to the Base 64 representation of the string.

Here is a simple example:
default
{
    state_entry()
    {
        string test = llStringToBase64("Hello world!"); //Creates a new string called test and assigns it a function, here the script will change "Hello world!" into Base 64 text
        llSay(0, (string)test); //This will make the script say the result in the local channel, result: "SGVsbG8gd29ybGQh"
    }
}
Compare with llBase64ToString.

NOTICE: Base64 is not encryption. It is very easy to decode base 64 strings.


This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

Functions / Crypto / Communications / Strings
Comments [Hide comments/form]
This function and its companion are SLOW! We're talking 300ms to convert 20 characters or so. Gah! So, if we want to transmit separator-clean strings (E.g., you can't pass "Hello, world!" through CSV routines as it'll split on the comma), we just have to put up with it? Anyone know another way that doesn't make my Commadore 64 point and laugh?
-- KralPlayfair (2004-09-09 00:56:16)
I couldn't believe this, so I ran a benchmark of my own... and found that Base64-encoding a 20-character string took about 270ms, pretty much in line with KralPlayfair's observation. (The actual number was 267.5ms when averaged over 1000 iterations and with loop overhead removed)

Base64-encoding a 1-character string took 267.8ms under the same rules: which is to say exactly the same time, the difference there has to be way under experimental error. Neither of these benchmarks made the "run tasks" number for the sim move at all.

It sounds unlikely for functions like this, but is it possible that the Lindens have for some reason decided that these functions deserve to have a ScriptDelay associated with them? Is it worth filling in a bug report to see if they'll tell us?
-- AlexanderDaguerre (2004-09-09 12:44:57)
I think so, as there's really no other way to safely pass string data (or other data encoded as a string), and I can't think of a reason why it'd be delayed. I assume they've accidently cut+paste an intentional delay from somewhere else.
-- KralPlayfair (2004-09-10 03:40:50)
I bug reported this today.
-- AlexanderDaguerre (2004-09-10 10:38:33)
I got a response today from Kelly Linden saying:

"I am not sure if this is intentional or not, so I have passed this on to the people who do know. I do not have a time frame for when it will be addressed."
-- AlexanderDaguerre (2004-10-12 18:06:19)
Just as a note, I think this was addressed at some point, since my tests show a _much_ quicker return on this function (as of 1.6). The delay to encrypt 20 characters averaged over 1000 iterations was about 14ms each, while 1 character was about 11.5ms each, so yes, I think they had a delay that was removed now.
-- AlondriaLeFay (2005-04-03 13:17:11)
It might just be the unicode functions are faster.
-- BlindWanderer (2005-04-04 14:50:03)
Attach a comment to this page: