KT Kingsley

A JIRA for this issue appeared today: Error when retreiving grid statistics page via llHTTPRequest.

I've tried it with both the http and https versions, neither of which now work for llHTTPRequest, but both of which work in my browser. I'm not sure why I'd want a URL for my script; an llHTTPRequest call generates an http_response event without that. (You need to get a URL so that external callers can generate an http_request event, to which the script usually responds with an llHTTPResponse call.)

For a while I've been using llHTTPRequest ("http://secondlife.com/httprequest/homepage.php", [], ""); to get the current SL usage data. This has, sometime in the last few days, stopped working, and now returns a status of 499 in the http_response event. The URL works fine in my browser, though. What's changed, and what should I be doing instead now?

There was this thing a while ago where empty regions would get put to sleep. I can't remember the term used for the process and I don't know if it's still in operation. It did, apparently, cause some distress to Meeroos, the breedable de jour. I did publish a script (a dummy HTTP call every 5 minutes, or something), that circumvented the region's automatic downtime. Seeing as how Meeroos are now, apparently, extinct, maybe my script turned out to be ineffective, wasn't taken up by breeders, was in its turn circumvented by LL, or people just got bored with Meeroos. But let this be a lesson from history.

You could get the legs to detach automatically using LSL, but not reattach themselves. Once they're inactive in inventory, that's it as far as LSL is concerned. One way using just LSL would require you to have rez rights for the land you're on at the time (which will probably be only very occasionally). You'd need a script in a HUD or other attachment that'd re-rez the legs and a script in the legs that'd reattach them. However, were you to use a third-party viewer with RLV enabled the process would be fairly straightforward. Have a HUD script polling llGetAnimation to spot a change from sitting to standing and then use RLV commands to detach and reattach the legs. Not knowing anything about your legs though, have you tried the reset skeleton option on your avatar's right-click menu?

How are you testing this? I ask because waiting through the SL four hour day cycle can be a bit tedious, so the temptation must be to take a short cut and manipulate the time of day manually. Now, I don't think that using the basic time of day settings will work here. I think you'd need to actually switch Windlight day settings to have an effect. Haven't actually tested this, so I'll log in right now… ETA: OK, what worked for me was to wear the scripted object as a HUD and then TP to some fixed sun regions that were either always day or always night, and one that had a contrary day cycle completely out of sync with the SL default. The script then correctly identified day and night. Sundarban - always day. Selidor - always night (just the night side of sunset) Skye Neist Point - has it's own idea of when night and day are I think to shortcut the testing you need to be able to set the Windlight for the region you're in, which means being the owner or an estate manager there. Any other setting will be viewer-side only.

Yes, particles are generated relative to the whole prim. To make flame particles originate from the tip of a candle you'd have to add a prim for each source. If you link them all and set them all to convex hull, you'll end up with an LI of 3 or 4, depending on the LI of the lantern itself. You can use llLinkParticleSystem set to LINK_ALL_CHILDREN or LINK_ALL_OTHERS to keep the script count down. So it's bad news, I'm afraid. One thing you might try is adding a "flame face" (something like two intersecting rectangles using the same material and UV mapping) above each candle and using an animated flame texture on it.

Are scripts allowed where you're trying this out? Is the "Running" checkbox in the script editor checked? Are you getting an error when you try to save the script, or does it save ok, but then nothing happens?

Infohubs usually get clogged up during restarts when the locations people try to log in to are offline.

At first glance it looks like there's three lines for each item. The first is the name of a texture in the vendor's inventory, the second is the name of the item being sold and the third is the price.

Also, you can make as many email addresses as you like on most free email services, and usually you can then link them to a single main account, or automatically forward them to a single email address on a different service.

I did pay $10 for an alt account back in, I think, 2005, before free accounts became a thing in, I think, 2006.

It's not stated whether the object is intended to be worn, so don't forget that if you do change the description of an attachment it will revert to the original when it's detached.

I think if you replaced the colour vector <0, 0, 0> with this: llList2Vector (llGetPrimitiveParams ([PRIM_SPECULAR, ALL_SIDES]), 4) you'd get what you're after.

Firestorm, and maybe others, has save and restore camera position buttons in its Cameratools floater. It would be nice to have them as separate entities, maybe as toolbar buttons.

Firestorm (and perhaps other TPVs) have a keyword alert feature that plays a sound in your viewer and displays the message in a distinctive colour whenever specific words appear. Perhaps this in conjunction with IMs might help you.

In state entry, llListen (PUBLIC_CHANNEL, llGetObjectName (), "", ""); then in the listen event, llShout (PUBLIC_CHANNEL, "That wasn't me!, That was a device owned by " + llKey2Name (llGetOwnerKey (id)) + "!"); The listener is created to listen only to objects with the same name as the "official" device, but as it can't hear itself anything it does hear will be from a different object that has the same name. Edit: Uh oh... a second look at the question shows that this won't work because everyone has their own dice HUD. Back to the drawing board. Sorry. I guess one way to go would be to have individual HUDs communicate with a central dice server which sends the result back to the HUDs.

This script, knocked up using the Firestorm particle editor (so many of the parameters are superfluous or inappropriate), is one way it might be done. I've bolded the essentials: the pattern (angle and its values) and the acceleration. The acceleration vector is modified by the object's rotation, and this needs to be updated as the object is moved around, hence the timer. Just drop it into a box to get the general idea. You'll probably want to knock the box over onto its side, too. default { state_entry() { llSetTimerEvent (0.5); } timer () { llParticleSystem( [ PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_ANGLE, PSYS_SRC_BURST_RADIUS,0, PSYS_SRC_ANGLE_BEGIN,0.1, PSYS_SRC_ANGLE_END,0, PSYS_SRC_TARGET_KEY,llGetKey(), PSYS_PART_START_COLOR,<1.000000,1.000000,1.000000>, PSYS_PART_END_COLOR,<1.000000,1.000000,1.000000>, PSYS_PART_START_ALPHA,1, PSYS_PART_END_ALPHA,1, PSYS_PART_START_GLOW,0, PSYS_PART_END_GLOW,0, PSYS_PART_BLEND_FUNC_SOURCE,PSYS_PART_BF_SOURCE_ALPHA, PSYS_PART_BLEND_FUNC_DEST,PSYS_PART_BF_ONE_MINUS_SOURCE_ALPHA, PSYS_PART_START_SCALE,<0.500000,0.500000,0.000000>, PSYS_PART_END_SCALE,<0.500000,0.500000,0.000000>, PSYS_SRC_TEXTURE,"", PSYS_SRC_MAX_AGE,0, PSYS_PART_MAX_AGE,5, PSYS_SRC_BURST_RATE,0.3, PSYS_SRC_BURST_PART_COUNT,5, PSYS_SRC_ACCEL,<-0.500000,0.000000,0.000000> * llGetRot (), PSYS_SRC_OMEGA,<0.000000,0.000000,0.000000>, PSYS_SRC_BURST_SPEED_MIN,0.5, PSYS_SRC_BURST_SPEED_MAX,0.5, PSYS_PART_FLAGS, 0 ]); } }

How do you sustain a business model in which users don't pay for your service?

My emphasis. Now this would be really nice to have.

So, if by "specific character" you mean this only happens when she's wearing a particular outfit, I'd guess she may be wearing a scripted attachment that manipulates her camera view. Try removing individual attachments, and you may find one that's causing the problem.

Try resetting the debug settings FocusOffsetRearView and CameraOffsetRearView to default. In Firestorm use Ctrl+Alt+Shift+S to open the Debug Settings floater, type "rearview" in the search box and then click the Reset to default button for each of the two settings.

Use... llRequestPermissions(llGetOwner(), PERMISSION_ATTACH); The function llRequestPermissions() requires the key of an avatar and the permissions being requested. In the case of a HUD the avatar wearing it is always its owner, so llGetOwner() will return the key of the avatar wearing the HUD. The name "attached", in your script, has not been defined so it's causing the error you see.

I've not looked at your post properly, but I did wonder if you could use the RLV adjustheight command as a work-around.

That's a transcript of Ebbe at VWBPE (Virtual Worlds Best Practices in Education) conference. Inara usually posts a summary of the Third Party Developers meetings, but I don't think she's done so yet.