Fenix Eldritch

Yeah, despite the name, llInstantMessage doesn't actually send the text to a private message window. However there are some other options you may want to try. Firstly, you can add some formatting to the message sent such that it stands out a little better in the chat window. For example, you can preface the message sent with "\n". That will cause any text after that to appear on a new line. You can use that to separate it from the sending object's name. For example, the string: "********\nThis is a test.\n********" Will appear as: ******** This is a test. ******** Alternatively, you could try sending the message via llDialog or llTextBox. This causes a little popup to appear along with whatever text you want (up to 511 and 250 bytes respectively). The text can be manually selected and copied.

Have a look at key framed movement: https://wiki.secondlife.com/wiki/LlSetKeyframedMotion You can use that to create smooth motion/rotations as slow as you like.

Are you also setting the script itself to use the new experience? At the very bottom of the script editor, there's a checkbox "Use Experience" and drop-down list containing all the experiences you own or are allowed to collaborate for. Make sure you set that as well if you're trying to use a different exp.

By itself, no. The LSD store is effectively a primitive parameter in the sense that it will persist once set and does not need a script to sustain it. Having said that, if the script in question does something that affects the datastore on startup, like calling llLinksetDataReset, then yeah that'll obviously wipe the store. Edit: as an aside, while llLinksetDataReset is them main way of clear a datastore, you could also do it by unlinking the object's original root. Technically speaking, the datastore isn't wiped: it stays with the root. So in effect, the old linkset will lose its datastore when the root object is taken out of the linkset. This isn't the case if you keep the old root and link a new root. In that scenario, the datastore is migrated to the new root (and merged if they both had a datastore).

The llAtan2 function can be useful here. And it just so happens that an example exists on the wiki that is pretty much the application you're looking for. https://wiki.secondlife.com/wiki/LlAtan2#Examples

Huh, I assumed the auto scale parameter would account for that... but apparently not. If all the images are the same size, you can probably get away with just altering the prim face's vertical scale (repeats) from the build tool texture tab until it aligns with the desired aspect ration of the prim/image.

I started typing up a response, but had a strong sense of deja vu... I don't think HTTPRequest will be of much help much here, because the end goal is to display content from the web on a prim's face. The only way to do that which I'm aware of is to turn the prim's face into a mini web browser by way of the Prim Media functions like llSetLinkMedia. The last time this was suggested, you seemed to have trouble getting it to work. Here's a slightly more automated demo. It cycles on its own as soon as the script is compiled. If you have Media-Auto Play enabled, it should just work, otherwise you must click on the target prim face once to initialize the mini browser. This demo uses face 0, or the top face of the default cube prim. /* Display images randomly from a given website directory. Assumptions: 1. All images have the same base URL,name, and file extension. 2. All images are differentiated by numerical suffix. 3. Users must have Media enabled in preferences. 3. Users must also have Auto-play Media enabled in preferences - otherwise they must click the prim's media face once to enable it for their view. */ string baseURL = "http://www.6dfgs.net/Gallery/Originals/DR2_6dFGS_view"; //the static portion of the image's full url (including the first part of the file name) string ext = ".jpg"; //extension for image file integer img_count = 5; //number of images in directory default { state_entry() { llClearPrimMedia(0); llSetLinkMedia(LINK_THIS, 0, [ PRIM_MEDIA_PERMS_CONTROL, PRIM_MEDIA_PERM_NONE, //hide control bar entirely PRIM_MEDIA_FIRST_CLICK_INTERACT, FALSE, //disable first click interaction PRIM_MEDIA_AUTO_PLAY, TRUE, //auto play PRIM_MEDIA_AUTO_SCALE, TRUE, //auto scale PRIM_MEDIA_CURRENT_URL, baseURL+(string)1+ext //initial url to display ]); llSetTimerEvent(10.0); } timer() { integer x = (integer)llFrand(img_count)+1; //generate random number from (0 to img_count-1) + 1 llSetLinkMedia(LINK_THIS, 0, [PRIM_MEDIA_CURRENT_URL, baseURL+(string)x+ext]); } } The example here uses a random website I found that had a gallery of pictures that followed a similar naming convention as your art files. The files are all named DR2_6dFGS_viewX.jpg where X is a number 1-5. Edit: It was also pointed out in the previous thread that this is a rather expensive way to go about displaying images, as each instance is its own web browser. That's a lot of overhead for a jpg. It will work, but it would be advisable to not use a lot of them in a single area.

As per the caveats on the wiki page for llGetObjectDetails, this function doesn't return information about items within an inventory. Unfortunately we don't have access to that kind of metadata directly. However, you can indirectly access an approximation by keeping track of when the notecard's UUID changes - as it will get a new one when you save any edits to a notecard. default { state_entry() { llOwnerSay("pre-edit uuid: "+(string)llGetInventoryKey("test") +"\npre-edit time: "+llGetTimestamp()); } changed(integer change) { if (change & CHANGED_INVENTORY) { llOwnerSay("post-edit uuid: "+(string)llGetInventoryKey("test") +"\npost-edit time: "+llGetTimestamp()); } } }

Via the official Map API, yes. You could make an http request to a utility URL specifying the global coordinates and the response (after some formatting) would be the region name. See https://wiki.secondlife.com/wiki/Linden_Lab_Official:Map_API_Reference#Utility_URLs Note you would need to divide the value returned by llGetRegionCorner by 256 to get the proper region offset. Once you have the region name, you can construct a SLURL or a clickable chat link with the Viewer URI formatting. Edit: Played around inworld and I think it's quite doable. Here's the basic idea: given any arbitrary global coordinate, use the map api to get the region name. find the region's region corner (can use the other utility url, or llRequestSimulatorData with "DATA_SIM_POS". subtract the region corner from the arbitrary global coordinate to get the local position within the region. use the discovered (escaped) region name and the discovered local XYZ position to create the URI link.

Asking for finding existing products should be done in the Wanted forum. Although what you are seeking can be accomplished with the command llSetScriptState. One of the caveats is that the function can only target scripts in the same prim. So you need to set up a communication framework between the HUD and the script that uses llSetScriptState - which in turn will set the state of the target script. Here is an extremely quick example using 3 scripts: // Object A // cotains this script. Touching it will broadcast the START or STOP message integer toggle = FALSE; default { touch_start(integer total_number) { if(toggle = !toggle) { llSay(1, "STOP"); } else { llSay(1, "START"); } } } . // Object B // cotains this script and the "target script". // Receives the start/stop message and sets the state of the "target script" accordingly default { state_entry() { llListen(1, "","",""); } listen(integer channel, string name, key id, string msg) { llOwnerSay("received signal: "+msg); if(msg=="STOP") { llSetScriptState("target script",FALSE); } else if(msg=="START") { llSetScriptState("target script",TRUE); } } } . // Object B // The target script that will be set active/inactive by the other scripts. // For this example it's just the default hello world script. // But make sure to rename this script to "target script" so the other one can find it. default { state_entry() { llSay(0, "Hello, Avatar!"); } touch_start(integer total_number) { llSay(0, "Touched."); } } Drop the first script into object A, and the other two into object B. Make sure to rename the 3rd script to be "target script" since that's what the 2nd script is looking for. When you click Object B, it should say "Touched." as per usual. Clicking on object A will send the START or STOP signal which will be heard by the 2nd script in object B. When the STOP signal is sent, you will notice that clicking on object B no longer does anything - because that script has been suspended. Clicking object A again to send the START signal will reactivate it.

That is... less than optimal. You can (and should) combine all of those into one script per button. Heck, you honestly can (and in my opinion really should) combine everything into a single HUD script. It isn't as daunting as you may think. Yes, that is precisely what I was going to say. You can simply add a new set of variables for additional links/faces/whatever and reference them in the new messages following the original. That is a better way than essentially duplicating the script for each message. Going a few steps further, you can further combine everything into one script in the HUD root. For example, suppose you name the buttons on your HUD to something like "Button1", "Button2, "Button3"... and so on. Then you could but a script like this in the root and it would react to whatever button was clicked (providing the name matched) : default { touch_start(integer total_number) { string buttonName = llGetLinkName(llDetectedLinkNumber(0)); llOwnerSay("user clcikd on "+buttonName); //debug readout if(buttonName == "Button1") { //do stuff for button1 //you can put you messages for button1 here } else if(buttonName == "Button2") { //do stuff for button2 //you can put you messages for button2 here } else if(buttonName == "Button3") { //do stuff for button3 //you can put you messages for button2 here } } } You could then take those llSay commands you have in each button and instead copy them to the appropriate sections in this script instead. Make sure you also define all the needed variables as well.

Your HUD script is basically constructing a custom message to send to the receiver. So sure, you could alter it to include additional link and face numbers in a single message. However, in doing that you would need to similarly alter the receiver script to understand the new message format and parse out the multiple link/face values from the single message. Alternatively, you might be able to just send extra messages for each link and/or face depending on the situation. That would probably work without needing to modify the receiver, providing you maintain the same format. As an aside, you can't define multiple discrete values into a single integer variable. Well... I mean you could encode multiple values into the integer (deep down it's just 32bits of data) but I imagine that's overkill for an application like this. The typical approach would be to use a list or some other kind of delineated string. Generally speaking, when you have a function that takes a link number as an input parameter, you are limited to either the specific individual link or a handful of special LINK_* constants that can define certain links or a limited range (self, root, the entire linkset, everyone else, or all child links). For faces, it's even more limited: you can only specify the single target face or ALL_SIDES. In order to target an arbitrary subset of link numbers (that aren't covered by the LINK_* constants) at the same time, you would need to use PRIM_LINK_TARGET. That signals that all the parameters that follow will apply to whatever link you specified there. You can have multiple PRIM_LINK_TARGET instances in the same parameter list to target other links in this manner.

Down the rabbit hole we go! I also created a test plane in Blender and uploaded it with the following traits: highest LOD was the model (default Blender 2x2 meter plane: 4 verts, 2 tris, no UV) all other LODs used "use LoD above" physics shape used high LOD, did not analyze or do anything else rezzed plane is using PRIM physics type (and I scaled the size down slightly to better fit in my raytracer scene) I then sat it down in front of my in-world raytracer and performed some visibility tests. The raytracer can "render" what is sees in terms of physics shapes. Colors for the backdrop walls and floor are hard-coded, but anything else in the viewfinder has a random color based on uuid. The grey prim in the background registers as a mirror when rendered. My avatar is also in the frame for reference (it appears as a purple coffin-shaped thingy). The raytracer shoots 1 primary ray into the scene and then shoots a secondary ray from the point of impact to the light source to determine shadows. Both rays have a maximum hit count of 1. Picture 1: the plane is facing the raytracer's camera (highlighted by me in edit mode). I would have expected the plane to render as a solid color. The speckled dark spots you see on it are a known issue. Basically, the ray did in fact hit the plane's surface, but the secondary ray that tries to rebound to the light source got interrupted, so the raytracer thinks that point is under shadow and shades it as such. I've seen this occur on torus and sphere prims under certain conditions. See BUG-202695. This seems to be a problem specific to my use case, but the important part is that the primary ray did in fact hit the plane at all points sampled. Picture 2: Oh... what? Those previously shadowed points are gone and now a lot of rays are shooting through the plane entirely and hitting the scene's backdrop behind it. What changed? The "thickness" of the object. Notice the Z component of the size in the edit tool: I reduced it to the minimum 0.010m. For some reason, this is now allowing many of the rays to punch clean through. Picture 3: Same as #2, but rotated the object 180 degrees to have the backface pointing towards the raytracer. Same results as #2. Picture 4: Repeating test#1 (front facing the raytracer's camera, default prim "thickness" as 0.75m) but with the physics shape type now set to convex hull. Now THIS is what I would have expected for all the other tests: a clean render with all rays hitting the surface and rebounding to the light source. For the sake of brevity, I'll skip the rest of the pictures and just report that repeating the other tests but with convex hull produced the same results: when the prim thickness (z size) was reduced to 0.010, some of the rays would manage to punch through the plane. Now this was with the physics model being the high LOD itself without any other options like analyzing, converting to hulls, or simplifying in the uploader. Sooooo.... Re-uploading the same plane, setting physics to highest LOD and analyzing using solid method, normal quality, no smooth and checking the close holes box (not that close holes should matter in this case). The results shown by the analyzer report Triangles: 2, Vertices: N/A, Hulls: N/A. (which were the same as the original plane I uploaded too). Interesting to note that the simplification section was greyed out at all times - perhaps this model is too simple? All tests using this model produced identical results as with the first model - except the new plane rendered in a stylish red color. Here's the older thread Wulfie referenced. And if anyone wants to experiment, I've left my raytracer rezzed in my workshop - see profile for slurl.

Hard to say without more info... What are the actual llCastRay command parameters you're using? What is the physics shape type of the plane? And as a sanity check, what does the plane's physics shape look like? You can get a quick visual by going to Develop > Render Metadata > Physics shapes. You'll want to probably do this in the sky to reduce visual clutter from nearby objects.

By detect, I presume you mean something to the effect of whether your avatar is currently in or under the water. The only command that deals with water is llWater. It returns a float which is the height of the water level at the object's current position plus an offset. Since the object is an attachment, its position is the same as our avatar's position, so we can just specify ZERO_VECTOR as the offset. To tell if your avatar is "in" the water, you would want to compare the value returned by llWater(ZERO_VECTOR) with the Z component of your avatar's current position vector returned by llGetPos. (you can access the individual X Y or Z components of a vector by appending .x .y or .z respectively when referencing the variable). If your vertical position is less than or equal to the water level, then you can conclude that you are in the water. Note that the position returned by llGetPos relates to the "center" of the avatar which is about waist-high. So if you want to get the coordinates of say, your feet, you would need to compensate for that. One way is to subtract half the avatar's height from its current position. Something like this: default { touch_start(integer total_number) { vector av = llGetAgentSize(llGetOwner()); //get (approximate) size of avatar vector p = llGetPos()-<0,0,(av.z/2)>; //get our position & subtract half avatar height from z component. (this will give the position of our feet) float w = llWater(ZERO_VECTOR); //get water height at our position w = p.z-w; //subtract water height (w) from our feet height (p.z) if (w <= 0) { llOwnerSay("you are in water"); } else { llOwnerSay("you are "+(string)w+"meters above the water"); } } } To have your attachment react to the avatar contacting the water, it would need to be running that check on a repeating timer. Perhaps with an interval of once every second or greater. Note that this is only viable for "Linden Water"... it won't work for user made prims that are meant to look like water.

Yup, there are several caveats to KFM, and that is one of them (see the wiki page I linked above for all of them). You can't use scripted commands to move any part of the linkset while the KFM is going. You need to wait for it to fully complete or stop it with one of the KFM commands. In fact, that's how several of the smooth door rotation examples work if I recall correctly.

Key Framed Motion my be another option, depending on the scenario. float rotationtime = 2.0; default { touch_start(integer total_number) { llSetKeyframedMotion( [llEuler2Rot(<0,0,90> * DEG_TO_RAD), rotationtime], [KFM_DATA, KFM_ROTATION] ); } }

If you do happen to get your hands on that lamp post, shoot me a copy. I'd love to have a piece of history like that.

Hmm, well that rules that out then. I just realized how I could find the answer! Since all icons are in a single atlas file, then either the html or css of the web profile should have some definitions to reference them. Saving a local copy of the page, I found some familiar strings buried deep in the css... (repeating the imge for reference) icon-beta_resident icon-charter_member icon-concierge icon-lifetime_member icon-linden_lab_employee icon-premium icon-resident (these were mixed in with all the other icon references, but they appeared in the same order as the icons visually) So Lindal was correct, #7 wasn't for mentors as I had guessed earlier. It turns out to be an abandoned regular resident badge. And Premium members also at one point were indented to have a badge as well - but that too apparently was abandoned, confirming Rowan's remarks. The Knowledge Base article for Accounts makes a passing reference to Concierge and that residents who have access to it can get special live chat. So I'm guessing this badge would have been for those concierge agents. Thanks for everyone's input!

Ok, I found another one I the wild. The key icon (#4) represents "Lifetime Member". I forgot about that one! I also found a screenshot of the lime person icon (#7) circa January 2011 here https://danielvoyager.wordpress.com/2011/07/03/look-back-at-previous-redesigns-of-the-second-life-profiles/ Viewing the same profile today does not show the icon. So I'm thinking it might have been either the default resident icon, or for mentors, as the screen shot does reference them being an ex-mentor. Can anyone recall if mentors, greeters, live helpers, etc had any kind of special account status?

If the icon is displayed, it'll be to the right of the avatar's name on the web profile, just above the gear options button. I found the set of seven by viewing the image in its own tab, only to discover it was a texture atlas of all buttons/icons in the same png file. Very odd that you found a Charter account that doesn't display as such... Unless there is a way to suppress that?

LinksetData has arrived!

I've long known that there are various kinds of SL accounts (not talking about premium vs non premium), but was recently reminded of them having special icons identifying them on the web profiles. I did a little digging and pulled out what I think are seven different icons. I recognize some of them: Beta Resident Charter Member Concierge* Lifetime Member Linden Lab Employee Premium* Resident* Does anyone know what the other ones are? I don't believe they're for regular or premium residents, as that doesn't show in the web profiles (unless it's since been deprecated) Edit: identified Concierge, Lifetime Member, Premium, and Resident by looking at the web profile's CSS file.

My guess is that it is another example of objects that were created during the alpha/beta phase of SL which were then migrated over to the main grid. The metadata references the creator, whose same account was recreated on the main grid and thus has a newer creation date than the object itself. The same thing can be observed with "The Man Statue". https://secondlife.com/destination/the-man As it happens, the creator of the lamppost referenced in the OP is listed as one of the Beta Contributors on the monument in Plum.

Just to be clear, when you say "20 list entries" are you talking about the individual elements in the list, or the strided "records" that are comprised of 4 list elements (timestamp, avatar name, online_status, previous_timestamp). Because I also tried removing 10 records (40 list elements) and that still produced a crash when the memory limit was 6k. When you're pruning the list, make sure you're doing the proper amount.