Quistess Alpha

FWIW, here's the function I use to push things to discord's webhook: uSendDiscord(string content,string name,string hook) { list lst = ["content",content]; if(name) lst+= ["username",name]; string send = llList2Json(JSON_OBJECT,lst); llHTTPRequest(hook, [ HTTP_METHOD, "POST", HTTP_MIMETYPE, "application/json" ], send); } which usually works well enough for most things (there are more usable json fields in the documentation, but I haven't had much need of them). I know I could "optimize" it, but it's not something that's to be run frequently (by 'things that should be optimized' standards).

Thank you for your hard work making that a thing without whatever black magic the other viewers are still using!

Not to belabor the point, but yes there are optimizations you can do depending on context, (I.E. use global variables for list literals) and how you shuffle the (in)efficiency around between execution speed and memory usage is also context dependent (that said, if you want to be space-efficient, I'd argue you shouldn't be trying to make dictionaries in the first place)

You can look in the environment section of the 'about land' window, but that obviously doesn't apply to personal environments.

There might be viewer-specific possibilities, but the easiest solution would be to sit on something that has defined camera position prim properties. (FOV isn't changeable by script though :/) // usage instructions: // - put the script in a prim, and make sure it is set to running, then sit on the prim. // - move your camera to somewhere of interest. // - say "setCam" (one word, with a capital C, no quotes) // - stand up, then sit back down on the prim. // - for as long as you are sat on the prim, pressing 'escape' willrestore your camera to where it was when you said "setCam". integer ghListen; default { state_entry() { llSetClickAction(CLICK_ACTION_SIT); llSitTarget(<0,0,0.25>,ZERO_ROTATION); } changed(integer c) { if(c&CHANGED_LINK) { key av=llAvatarOnSitTarget(); if(av) { llRequestPermissions(av,PERMISSION_TRACK_CAMERA|PERMISSION_TRIGGER_ANIMATION); ghListen = llListen(0,"",av,"setCam"); }else { llListenRemove(ghListen); } } } run_time_permissions(integer perms) { if(perms&PERMISSION_TRIGGER_ANIMATION) llStopAnimation("sit"); } listen(integer Channel, string Name, key ID, string Text) // { if(llGetTime()>3.0) { if(llGetPermissions()&PERMISSION_TRACK_CAMERA) { vector myPos = llGetPos(); rotation myRot = llGetRot(); vector camPos = llGetCameraPos(); rotation camRot = llGetCameraRot(); llSetCameraEyeOffset((camPos-myPos)/myRot); llSetCameraAtOffset(((camPos+llRot2Fwd(camRot))-myPos)/myRot); llRegionSayTo(ID,0,"Camera changed. Try unsiting, then re-sit and press escape."); } } } }

If you need to do it in such a way that users can't pretend to be someone else (at least not without that person's cooperation), you need to use encryption. This is exactly the scenario for which I ported the XTEA algorithm to LSL: (quoted to minimize long code spam)

I think the best way to do it would be to have the form send back the user's key* with the form data. There are multiple ways to achieve that, but if it were me, I'd add the user's key as part of the form url's query string when generating the page's (X)HTML. *Usernames are changeable; keys are not. Best practice is to use a user's key to identify them, not their name. Use names only for presentation to users.

Oops, and my push_to_JSON_LSD function has a few errors as well ( need to use the values in the separators parameter instead of literals, and llParseString needs an extra empty list parameter ). If/when I need to use JSON I never write the literal string anyway, it's safer to generate it with llJsonSetValue or llList2Json. string message; message = llJsonSetValue(message,["command"],"CMD"); message = llJsonSetValue(message,["param1"],"value1"); // etc. JSON seems very 'love it or hate it'. I used to rather dislike it, but I've come around slightly. If you need a key-value store within a string, using native LSL functions is more "natural" than making user functions, and if you're looking for efficiency, the comma-sepparated-value (CSV) conversion functions are pretty robust (correct handling of 3 or 4 valued vectors (vector/rotation), even though they contain commas), if you can handle a fixed argument order.

Not relevant to this discussion, but as an aside, llDialog ( and llTextbox ) responses come with the sending object as the avatar, but the sending ~location as the object which called the function. In practice, this means that if the object making the llDialog call is the same one that is listening for the response, it will always be heard as long as the avatar's viewer is able to send the response* . dialog boxes on channel 0 could be used for (very loud) role-play telephones. *sometimes works for a few seconds after tp to a very distant region, local distance is loosely related to the viewer's draw distance.

For what it's worth, gmail is quite nice for spamming different addresses for accounts: You can add a "+tag" to the end of your address, so myEmail+secondlife@gmail.com and myEmail+secondlifeAlt@gmail.com both get routed to the owner of myEmail@gmail.com. Some sites don't think '+' is a valid character in email addresses. To bully them, you can infix '.' anywhere in the address before the '@': like my.Email@gmail.com or m.y.e.m.a...i.l@gmail.com .

Presuming you have a choice over the message protocol, it's probably better to leverage built-in functions for JSON: // if you're being really persnickety about execution time, define all static lists in global variables: list gCOMMAND = ["COMMAND"]; list gPARAM1 = ["param1"]; list gPARAM2 = ["param2"]; //... // presumably, you get the message from a listen event, or possibly http communication: string message = "{COMMAND=CMD,param1=value1,param2=value2}"; string CMD = llJsonGetValue(message,gCOMMAND); if(CMD=="Command1") { string param1 = llJsonGetValue(message,gPARAM1); string param2 = llJsonGetValue(message,gPARAM2); // and so on, then do something with the parameters. } https://wiki.secondlife.com/wiki/Json_usage_in_LSL You can even convert to JSON from |, = format: integer push_message_to_JSON_LSD(string message, list separators); // { string message = "CMD|param=value|param2=value2"; integer ind = llSubStringIndex(message,"|"); string command = llDeleteSubString(message,ind,-1); // if the message has no "|", the final character will be deleted. message = llDeleteSubString(message,0,ind); if(message) { message = llList2Json(llParseString2List(message,["|","="])); llLinksetDataWrite("Dict:"+command,message); return TRUE; } return false; } string read_JSON_LSD(string cmd, string param) { string ret = llJsonGetValue(llLinksetDataRead("Dict:"+cmd),param); if(ret==JSON_INVALID) return ""; return ret; } //example usage: string message = "CMD|param=value|param2=value2"; push_message_to_JSON_LSD(message,["|","="]); string value = read_JSON_LSD("CMD","param"); // should == "value" from the message. (not debugged) Something like that might be a medium between your method 1 and 2, slightly less efficient than 1 on the read, but possibly more efficient than 1 on the write.

you'd need to research the specific head in question, each of the common head brands is slightly different. If you mean you meshed the head yourself, that's a bit more work than just dropping in a script that 'makes it do the thing you expect it to'.

did you try llKeyframeMotion? it's a bit harder to get a handle on for things like this though.

On android, there's a wonderful keyboard app called "unexpected keyboard" that can type pipes and other fancy symbols easily. As for the script, in situations where exactly one animation is supposed to play, it's usually best to just have a global variable set to the running animation, so you can run_time_permissions(...) { if(perms&PERMISION_TRIGGER_ANIMATION) { if(gAnimOld) llStopAnimation(gAnimOld); if(gAnimNew) { llStartAnimation(gAnimNew); gAnimOld=gAnimNew; gAnimNew=""; } } } or so. (pro-tip: set the old animation to "sit" to stop the default sitting animation) setting a global variable to the anim you want to play and requesting permissions every time, stops your script from complaining if a sitter uses "reset skeleton and animations".

I was using packets in an anecdotal sense, no clue about server implementation either...

IIRC, LSL http stuff still has occasionally frustrating low character limits. Hmm, reading the wiki, so, the messaging protocol for maximum data transfer is a little convoluted.

A few months ago, if this is the one.

Some outfits from Meli Imako, but they might be a bit too formal: https://marketplace.secondlife.com/p/MAITREYA-FULL-PERM-FITMESH-Working-Woman-Character-Outfit/17839264 https://marketplace.secondlife.com/p/Full-Perm-Female-Waitress-Uniform-Slink-Maitreya-Legacy-Belleza-Tonic-Ebody-Ocacin-Classic-Body/11291431

my point was that, if you link them, the LSD becomes merged, which if you figure out the caveats, might bypass the need for communication.

I usually figure out the technicals before deciding on the UI. probably too much hassle if you're only slightly over 1024, but having the object rez and then link the "backup disk" then unlink it and present it to the user to take, doesn't sound too unfriendly, especially if actually using the backup is less common than creating one. . .now I think on it though, scripted backup seems pretty silly unless the object is no-copy.

If I needed to do that, I've tossed around the idea of linking and breaking in my head a few times, but not actually tried it. that requires special permissions and is a tad slow though.

AFAIK, no. if sending large amounts of data in 1024 length packets (as you alluded to in another post) and you really need to keep the order, you might have to add some book-keeping to your conversation protocol. For example "0,some data","1,some data","-2,some data" using the sign to indicate it's the last transmission in the group, receiver stores everything and interprets only after a negative index, and number_of_received_packets+1==llAbs(the_last_negative_index). sending acknowledgements from the receiving object, (transmitter 'sends the next packet' when it hears "ack" from the receiver) if it's not mission critical, llSleep(0.2); between each message is probably good enough for most use-cases)

I guess it depends on what you're trying to optimize. A single loop means the function itself will take up, maybe 10~50 bytes less script space? but will run incalculably slower. (because you're checking something you already know, for every character) ETA: Also, I liked the first one better. % and / are both slow. Preffer &1 and >>1 (or *0.5 for floats) respectively . (n/2)*2 == n&(~1) == n&(integer)(-2)

Good job! Some really minor suggestions, but wouldn't flipping the conditional save doing a negation operation for every character? if(iDir) instead of if(!iDir). Come to think of it, you could just place the conditional outside the loop, and if I'm being over-optimizationalist, overload the input parameter as the loop variable: string MemComp(string sInput, integer iDir) { //Compress 2 UTF-8 chars into UTF-16, or decompress UTF-16 to UTF-8. Credit: Jenna Huntsman, Mollymews string sOut; if(iDir) // decode for every non-0 value. { //Decode for (iDir = 0; iDir < llStringLength(sInput); ++iDir) // overload iDir to be a loop increment. { integer c = llOrd(sInput,iDir); sOut += llChar((c >> 8) & 255) + llChar(c & 255); } }else // idir==0 { //Encode for (iDir = 0; iDir < llStringLength(sInput); ++iDir) // overload iDir to be a loop increment. { sOut += llChar((llOrd(sInput,iDir) << 8) | llOrd(sInput,iDir+1)); ++iDir; //Iterate i by 2 and not 1 on encode. //(if you wanted to be fancy could embed ++ in the += line, but that would be harder to read and debug given lsl execution order, and no more efficient.) // something like llChar(llOrd(sInput,++iDir) | (llOrd(sInput,++iDir) << 8) ); with the increment removed from the for construction and initialize to -1. } } return sOut; } again though, really minor nitpicks!

actually forum software deletes it, or at least I was able to copy the character from Wikipedia but not Invision forums.