Quistess Alpha

And adding on to that, since the hovertext font is not monospace (Every letter has a slightly different width), the ability to have per-letter rainbow colors and the ability to change the text arbitrarily are (more or less) mutually exclusive, not to mention the letters won't fit together horizontally nicely unless it's a HUD or you're looking at it straight on.

They let you, if you enable the right setting, but that doesn't mean it can't be problematic. The worst that could probably happen is a corrupted cache, but still I generally have my alts logged in on a different viewer in an abundance of caution.

All you have to do is sign up for another account at https://join.secondlife.com/ the hard part is keeping them all logged in simultaneously.

Seems it's not released on the main grid (or at least not whatever sim version my house is on), and I'm too lazy to check the beta grid.

not a recommendation, but: https://marketplace.secondlife.com/p/Multi-Love-Pose-MLPV24/11023468 (documentation) https://wiki.secondlife.com/wiki/MLPV2

Just for my own fun, I wrote a slightly different script that does the same thing. The only difference that should actually matter is that I synced to llGetTime() rather than an incremented global step variable: float time = 6.0; float height = 2.0; float angle = .5; integer isRunning = FALSE; vector gPosA; vector gPosB; rotation gRotA; rotation gRotB; vector cosInterp(float time, float rate, vector posA, vector posB) { float ct = 0.5*(1+llCos(time*TWO_PI/rate)); return ct*posA + (1-ct)*posB; } rotation cosRotInterp(float time, float rate, rotation rA, rotation rB) { float ct = 0.5*(1+llCos(time*TWO_PI/rate)); return <ct*rA.x + (1-ct)*rB.x, ct*rA.y + (1-ct)*rB.y, ct*rA.z + (1-ct)*rB.z, ct*rA.s + (1-ct)*rB.s>; } default { state_entry() { gPosA = llGetPos(); gPosB = gPosA + <0,0,height>; gRotA = ZERO_ROTATION; gRotB = llAxisAngle2Rot(<0,0,1>, angle); //llSetTimerEvent(0.044); } touch_end(integer n) { llResetTime(); llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POSITION,gPosA, PRIM_LINK_TARGET, 2, PRIM_ROT_LOCAL, gRotA ]); llSetTimerEvent(0.044*(isRunning=!isRunning)); } timer() { float t = llGetTime(); vector pos = cosInterp(t,time,gPosA, gPosB); rotation rot = cosRotInterp(t,time,gRotA, gRotB); llSetLinkPrimitiveParamsFast(LINK_THIS, [ PRIM_POSITION,pos, PRIM_LINK_TARGET, 2, PRIM_ROT_LOCAL, rot ]); } }

I'm not seeing that when I just put the script in 2 linked cubes. Perhaps you could share a video of how it looks to you?

Yeah, that's how Google/Bing hook you. It's "free" to just type whatever in their search engine and have it translated, but to translate more than just small snippets or integrate it with your program (Secondlife) automatically, you need to pay the piper.

Only in Belisaria (the continents with all the mostly identical houses). For the rest of mainland, it's anything goes.

Nobody but you* is able to change your inventory. You probably just misplaced it. *linden lab employees can change resident's inventories in very limited circumstances.

string mySound; integer isOn; // script is 'active' integer isWalking; // owner is currently walking. key owner; default { state_entry() { mySound = llGetInventoryName(INVENTORY_SOUND,0); owner = llGetOwner(); } changed(integer c) { if(c&CHANGED_OWNER) { owner = llGetOwner(); } } touch_start(integer n) { isOn = !isOn; if(isOn) { llOwnerSay("Walking sound on."); llSetTimerEvent(0.5); }else { llOwnerSay("Walking sound off."); llSetTimerEvent(0.0); llStopSound(); } } timer() { integer walking = llGetAgentInfo(owner)&AGENT_WALKING; if(walking!=isWalking) { isWalking=walking; if(isWalking) { llLoopSound(mySound,1.0); }else { llStopSound(); } } } } If all you're doing is turning it off and on again, why do you need a dialog box?

Yeah, we need a better system than expecting residents to flag items as 'Dissallowed listing practices'->''demo not linked to full version'; incorrectly listed demos should be removed automatically after some reasonable timeframe, but they aren't and so flagging is the best we can do.

FWIW, if you buy a piece of furniture that attaches "props", then you (the owner of the furniture) can pull out a transferable and copyable copy of the prop from the furniture's inventory, then give it away to your friends and such. You probably ought not to, but the permissions system is such that in order for the furniture to function at all, the creator can't stop you from doing it.

typecasts and function calls don't work in global variables. You can of course do it in state_entry() but if you're making a script in which you expect people to edit variables directly, it's good and common practice to place the 'configuration variables' at the very top of the script, rather than expecting people to scroll down.

I haven't tested it extensively, but this should work:

A basic example of a TV that should stay relatively in sync between everyone watching, as long as they use the provided controls on the object and ~not the media controls on the media face itself. The script as written only plays one movie/video (specified in the script), and expects named links to be used as control inputs. (different faces would be more efficient for land impact, but would make setting up and using the example from the script alone more confusing) There are plenty of things that could be added or improved, this is mostly just a minimum working example for demonstration. string gMediaFile = "https://ia800204.us.archive.org/25/items/Maniac1934/Maniac1934_512kb.mp4"; integer gFace = 2; integer gTimeStart; integer gTimePause; string gsURL; key ghRequestURL; string gXHTML() { return "<!DOCTYPE xhtml> <html xmlns=\"http://www.w3.org/1999/xhtml\"> <script type=\"text/javascript\"> function setTime(){ var vid = document.getElementById(\"vid\"); vid.currentTime=\""+(string)(llGetUnixTime()-gTimeStart)+"\" //vid.requestFullscreen + browser specific variations don't seem to work. } </script> <style> body {background-color:black;} </style> <body onload=\"setTime()\"> <video id=\"vid\" controls=\"\" src=\""+gMediaFile+"\" autoplay=\"\" style=\"width:100%;height:100%;\" /> </body></html>"; } integer gIncrement; set_media() { string s = (string)((++gIncrement)&7); llSetLinkMedia(LINK_THIS,gFace, [ PRIM_MEDIA_HOME_URL, gsURL+"/home"+s, PRIM_MEDIA_CURRENT_URL, gsURL+"/home"+s, PRIM_MEDIA_AUTO_PLAY, TRUE, PRIM_MEDIA_PERMS_CONTROL, PRIM_MEDIA_PERM_NONE, // don't show nav-bar. PRIM_MEDIA_PERMS_INTERACT, PRIM_MEDIA_PERM_NONE ]); } default { state_entry() { ghRequestURL = llRequestURL(); gTimeStart = llGetUnixTime()+5; llOwnerSay("debug"); } changed(integer c) { if(c&(CHANGED_REGION_START|CHANGED_REGION)) { llReleaseURL(gsURL); ghRequestURL = llRequestURL(); } } http_request(key ID, string Method, string Body) { if(ID==ghRequestURL) { gsURL=Body; llSay(0,gsURL); set_media(); }else { llSetContentType(ID,CONTENT_TYPE_XHTML); llHTTPResponse(ID,200,gXHTML()); } } touch_start(integer total_number) { if(llDetectedKey(0)==llGetOwner()) { string what = llGetLinkName(llDetectedLinkNumber(0)); if("start"==what) { gTimeStart=llGetUnixTime()+5; gTimePause=0; set_media(); llSay(0,"Starting movie"); }else if("play/pause"==what) { if(gTimePause) { llSay(0,"Resuming playback."); gTimeStart += 9 + llGetUnixTime()-gTimePause; // the '9' skips back before the pause gTimePause=0; set_media(); }else { llSay(0,"Movie paused."); gTimePause=llGetUnixTime(); llClearLinkMedia(LINK_THIS,gFace); } }else if("skip-"==what) { llSay(0,"Skipping back."); gTimeStart+=60; // Yes, increment start time to go back is a bit counterintuitive. set_media(); }else if("skip+"==what) { llSay(0,"Skipping forward."); gTimeStart-=60; set_media(); }else { llOwnerSay(what); } } } } ETA: This rather simple script only accounts for people entering late, pause/resume and seeking through the video. It doesn't take into account the possibility that someone's connection might not be fast enough to play the video continuously without pausing or stuttering. the video file needs to have low enough quality that everyone can watch it comfortably. (if you're watching through SL, you're probably not ~that concerned with video quality anyway.) Also, the video needs to be a literal video file (any commonly supported format should work) and not a page that directs to a video file player, even if that page is confusingly named with a misleading extension. This means you can't watch videos from <insert common streaming service here>. (unless you rip it and re-upload it to a file sharing site. )

It's a bit buggy last I checked, but you can set media on a prim to the discord web-client and have everyone watch through someone casting their screen that way. The problem is, SL doesn't pass through media itself, it just hands off the URL for people to look at themselves. most "good TVs" seem to rely on an external server to forward to everyone , and media streaming is very expensive server-side which equates to more RL cost than can be recouped from the sale of SL tv's. It might be possible to sync everyone with old parcel media commands, but that requires access to raw video files hosted somewhere. most streaming sites nowadays have made it impossible or technically difficult to rip the raw file rather than going through their proprietary player, so a TV that worked on that principal wouldn't have much content available to view.

Technically, I think viewers are free to interpret the folder name as a path if they want to, as RLV viewers add folders to a subfolder under certain conditions. I don't think many or any viewers support interpreting "mything/extrastuff" as a path rather than a literal folder-name outside of a RLV context though. ETA: llGiveInventoryList(llGetOwner(),"#RLV/~Test/ing",[llGetInventoryName(INVENTORY_OBJECT,0)]); even gives a folder 3 levels deep (given RLV is on, viewer supports it). The possibility is there, just viewers haven't implemented it.

The "inventory asset" of an object in your inventory isn't easily modifiable, so SL doesn't let you do anything that could potentially change an inventory item's permissions (for example, adding a no-mod item to an otherwise modable object) while attached rather than rezzed. It is indeed possible if everything is created by you, and possibly in other full-perm combinations of ownership.

Short answer is no, long answer is it's possible if your mesh were built specially to purpose, longer answer is you can do it using math, but it would probably look bad (pieces moving not exactly in sync with each-other) and cause more lag for the region and anyone around it.

A) High Cost. Hypothetically, even if it were that simple, if all the alternative providers cost too much, and the service isn't really making much money or providing enough value to the owner/operator, it might be an easy excuse to call it quits. B) No Backup. If he didn't keep copies of important scripts/data and the now-dead service deleted them, he's very SOL. C) API compatibility. If his scripts for telling the server what to do included instructions specific to the now-dead service, it would be a pain to translate that into something a different service could understand.

That should have the same probability of a collision, but since we have llHash, we might as well use it. On another tangent, I vaguely remember reading somewhere on the wiki that someone found an example of a linden and a resident who's UUIDs differed by only one or two hex characters. I don't know if there are any known examples of two avatars who's UUIDs hash to the same value.

A little off-topic, but llAttachToAvatar is a bit tricky to use correctly, because it does not automatically transfer ownership like the temporary version. The only clean way I know of to transfer ownership (via script) other than temp-attach is to set the object for sale and have the new owner buy it. It might be interesting to try and see what happens if you try to llAttachToAvatar an object which is already temp-attached.

You rez the object with the start parameter as the llHash of the person to attach to, then the rezzed object does a llSensor or llGetAgentList in on_rez and searches for the avatar who's hashed key matches, then requests permissions and attaches to them. Roughly (I'm too lazy to test and debug): //Rezzer: llRezAtRoot(myObj, rezPos, rezVel, rezRot, llHash(whoToGiveTo)); //Rezzed object: on_rez(integer hash) { list nearby = llGetAgentList(AGENT_LIST_PARCEL,[]); integer i = llGetListLength(nearby); key agent; while( (llHash(agent=llList2Key(nearby,~--i))!=hash) && (i>-1) ); // empty while loop convenient for variable filling. if(agent) { llRequestPermission(agent,PERMISSION_ATTACH); llSetTimerEvent(15.0); // in the timer event, die because nobody attached the object. }else { llSay(0,"Warning, agent to attach to not found, destroying."); llDie(); } } timer() { llSay(0,"permission not granted, dieing."); llDie(); } run_time_permissions(key who, integer perms) { llSetTimerEvent(0.0); // don't die. llAttachToAvatarTemp(who,0); } Alternatively, you could store the key to attach to in the the description or invisible hover text of the rezzer, which you could fetch from the rezzed object with: key parent = llList2Key(llGetObjectDetails(llGetKey(),[OBJECT_REZZER_KEY]),0); string parent_text = llList2String(llGetObjectDetails(parent,[OBJECT_TEXT]),0); string parent_desc = llList2String(llGetObjectDetails(parent,[OBJECT_DESC]),0);

From the wiki: https://wiki.secondlife.com/wiki/LlAttachToAvatarTemp