KT Kingsley

I've no idea if this will work, but maybe blocking/muting them will also stop you receiving the error messages?

Essentially it's just a prim with the store graphic applied as a texture, and a script that gives the object's contents when it's clicked and then detaches itself. The texture needn't be scripted: it's something you can apply manually through the build menu. Many of those unpacker scripts you've seen are likely to do the giving and detaching you're looking for. I'd be surprised if there isn't a perfectly adequate one going for free somewhere. It's not a particularly difficult script to write. So, having found a suitable script, rez a prim, give it a suitable name, apply the store graphic texture to it, and load it up with the script and the objects you want it to hand out. Take it into your inventory and add it or wear it as a HUD (or put it on as a HUD direct from the ground). Adjust its size and screen position as required. Detach it, and it'll be there in your inventory ready to sell or hand out to your customers or friends. There are, of course plenty of opportunities for error in this process (permissions, for example) so be sure to test it out (both on friends or alts, as well as yourself) before going live.

Ansariel Hiller has posted a screenshot of the AWS health status page in another thread:

I've just been logged out and can't get back in. The outage has appeared on the status page within the last few minutes: https://status.secondlifegrid.net/.

I've just been logged out and can't get back in. The outage has appeared on the status page within the last few minutes: https://status.secondlifegrid.net/.

To add to what Profaitchikenz said, particles from other objects around you also count towards your limit. Using Firestorm you can block a particle owner and the particles emitted by their objects (both together but not separately), which may help keep things within your limit.

To be pedantic (which I just love doing), you can control the camera's roll in flycam mode using a 3D mouse like 3DConnexion's SpaceNavigator.

if ((string) ((integer) msg) == msg) might work here.

One more thing that might be useful is the PRIM_LINK_TARGET flag for llSetLinkPrimitiveParamsFast. llSetLinkPrimitiveParamsFast (LINK_ALL_OTHERS, [ PRIM_FULLBRIGHT, ALL_SIDES, TRUE, PRIM_LINK_TARGET, 2, PRIM_GLOW, ALL_SIDES, 0.10, PRIM_POINT_LIGHT, TRUE, colorpick, 1.0, 3.0, 0.0, PRIM_LINK_TARGET, 3, PRIM_GLOW, ALL_SIDES, 0.05 ]);

In Chrome there's the experimental Auto Dark Mode for Web Contents which you can find under chrome://flags/. It works ok for some websites. Unfortunately Marketplace isn't one of those.

From the photo you posted, it looks like your backdrop is set to fullbright. This means it will always be rendered full, 100% white. Try turning fullbright off for it and you should see the effect shadows from the sun and moon, and from projector lights have on it (provided you've enabled these in your graphics preferences), as well as the effects of coloured lighting and Windlight/EEP environments.

A prim – primitive – is one of the base objects that can exist is SL. Things like cubes, cylinders and spheres. You can manipulate these – change their size in each of three dimensions, variously tweak and twist them, hollow them out and, of course, change their colour and texture (independently on each individual face if desired), and you can combine them to make more complex shapes (though mesh models are more commonly used for this nowadays). The word is sometimes used to refer to almost any object in SL. For your needs, I think a good start would be to rez a cylinder, hollow it, and apply a suitable scenic texture to the inside face of the hollow. To rez (bring into being) a prim cylinder open the build window (Ctrl+B). The rezzing tool (wand with stars icon) should be selected and the mouse cursor also becomes a wand. Click on the cylinder icon just below that, then click on your land. A small plywood cylinder should appear. Hollow it out to its maximum (95%). Move the cylinder to where you want it (likely the same position as your skybox) using the position number boxes. As a start set the numbers to the same values you get in the top bar of the SL window when you're standing in the middle of your skybox, or use the numbers you see for its position in the Object tab of the build window when you right click your skybox and select edit. Change the size of the cylinder using either the numbers in the edit window or by holding the Ctrl+Shift keys and dragging the coloured boxes that appear around the prim, and make it large enough to enclose your skybox plus a bit extra. You may also want to tweak the position of the cylinder by dragging the coloured arrows. Click the Texture tab in the build window. Drag a texture with your chosen view (try the Library/Photo Album folder to begin with if you haven't yet acquired or uploaded a specific image) from your inventory onto the texture box. And there you (should) have a basic scenic surround for a skybox. Clearly there's plenty more you can do to refine it, but this should be enough to get you going. Feel free to ask more questions as you need to.

Ah yes, forgot to mention that too: the function works on your camera when it's in the default position. If you've cammed off somewhere nothing will happen until you Esc back to the default. And I think this context includes any custom camera presets you have.

My first guess is that the method you're using to get an avatar key into the script isn't working properly. This is where llOwnerSay debugging is needed. When you get stuff like the avatar key put in an llOwnerSay debug, along the lines of llOwnerSay ("Avatar: " (string) avatar_key + ", " + llGetDisplayName (avatar_key)), and similarly for its position llOwnerSay ("Position: " + (string) avatar_position);. Scripts and viewer code are completely different things. The server sends data, such as avatar positions, to the viewer so the viewer knows where to draw an avatar, or position the camera to look at that avatar. That same data is made available to scripts through the LSL functions. Scripts run entirely on the simulator, and their effects are notified to whatever viewers might be affected by them.

Oops! Yeah, the return from llGetObjectDetails is a list, so you have to extract the value from the list using one of the llList2* functions. Sorry, my bad. Compacting things (so only one call to llGetObjectDetails): list details = llGetObjectDetails (target_key, [OBJECT_POS, OBJECT_ROT]); vector target_position = llList2Vector (details, 0); rotation target_rotation = llList2Rot (details, 1);

I usually handle this by extracting the target position and rotation and use the position (plus maybe a little upwards when the target is an avatar so the target becomes its face rather than its crotch) as the focus and then use the target position plus your viewing offset adjusted for the target's rotation as the camera position. vector camera_offset = <1.0, 0.0, 0.0>; //1m may be a bit close: you can make the offset larger or smaller, and you can use the y and z values to move the viewing position up or down, or off to one side. Also, you may want to make the z value the same as what you use for adjusting the target position so the view is straight and level key target_key = however you're identifying your target; vector target_position = llGetObjectDetails (target_key, [OBJECT_POS]); rotation target_rotation = llGetObjectDetails (target_key, [OBJECT_ROT]); llSetCameraParams ([ CAMERA_ACTIVE, TRUE, // TRUE == 1 is active, FALSE == 0 is inactive CAMERA_FOCUS, target_position + <0.0, 0.0, 0.5>, // region relative position and 0.5m higher CAMERA_FOCUS_LOCKED, TRUE, // (TRUE or FALSE) CAMERA_POSITION, target_position + (camera_offset * target_rotation), // the offset adjusted to take into account the direction the target is facing CAMERA_POSITION_LOCKED, TRUE // (TRUE or FALSE) ]);

I've seen references to work being done on improving ARC calculations in some of Inara Pey's user group meeting reports, so it's possible you were in a region with a simulator using some experimental code. @Maitimo, I think the issue is the complexity value of 132 632 at the bottom of the window.

For stuff that doesn't render you can try turning wireframe mode on and off: Ctrl+Shift+R, twice. This works for things the viewer knows about but has forgotten to draw, but not for things the server hasn't told the viewer about, possibly due to the information getting lost in transit.

Also, note llGetDisplayName, which will return the display name immediately, but only if the avatar concerned is in the region.

Continue your code in the dataserver event once you've got your data. You wait for your data by waiting for the dataserver event. It'll fire automatically once the data is available. string displayName; default { state_entry() { llRequestDisplayName(llGetOwner()); } dataserver(key queryid, string data) { displayName = data; llOwnerSay("DisplayName1 "+ displayName); llOwnerSay("DisplayName2" + displayName ); } }

Events are processed in their entirety when they are triggered, so in state_entry the llOwnerSay call is processed immediately after the display name is requested, without waiting for the result of the request. The result of the display name request is placed in the script's event queue, and is processed when all the other events there, and the current event, have been dealt with. The requested data is only available in the dataserver event until it's saved to a global variable, when it becomes available to any subsequent events that might be triggered. The llRequest* functions are, effectively, call-back functions. You make your request, and sometime in the future, once the relevant databases have been queried, the result is posted back to you, appearing in the dataserver event.

When I add llOwnerSay for debugging I put the statement flushed left and unindented, which helps it stand out from the main code. Except for all those pesky wrapped lines of code. When I do use a debug llOwnerSay wrapper function, I usually make its parameter a list, which cuts down on the explicit typecasting needed. Debug (list message) { llOwnerSay (llList2CSV (message)); } Debug (["counter", counter, "value", value]); Though sticking lists in there is less tidy.

I think the OP was about the Destinations window in the viewer (World/Destinations - at least it's that in Firestorm) which used to have an "Adult" category, but doesn't appear to any more. I suspect that none of the destinations now listed there are on adult rated regions either, though my research into that supposition has been somewhat limited: hampered, as it was, by my lack of interest in the feature, given that for any destination the only information provided is an often truncated description with no way to find out more (such as by opening the world map) before teleporting there.

I guess llGetObjectMass might be part of what you're after. I can't help you with the physics maths, though.

Try clicking the object you're sitting on. Failing that, you could stand up and sit down on it again.