KT Kingsley

Me neither, but then I did do the previous previous prepay thing at the old premium rate when the new rates were announced, and that kicks in in January. My next renewal payment is due in January 2021.

Qie mentions llSetTextureAnim. Maybe using this function in frame mode might work here if, say, 16 256 x 256 frames would make an acceptable effect.

That's a lot of sound clips, and I suspect they're not all getting downloaded to the viewer in time for them to be ready when they're needed. Note that llPreloadSound incurs a delay of one second when its called. About the only workaround I can think of is to start the preloading whenever there's avatars within range. Maybe an in-world object that continually loops the preloads (crude) or one that fires up whenever a unique avatar comes into range?

I think what I'd do is make the inventory_items list strided, with a name followed by a counter for each item. When examining items from the inventory, I'd look to see if it's already in the list and if it is just increment the counter, and if it isn't add it and a counter set to 1 to the list. for (counter = 0; counter < item_count; counter++) { string name = llGetInventoryName(INVENTORY_OBJECT,counter); integer index = llListFindList (inventory_items, [name]); if (index > -1) inventory_items = llListReplaceList (inventory_items, llList2Integer (inventory_items, index + 1) + 1, index + 1, index + 1); else inventory_items += [name, 1]; setTitle(); } This does, of course make the output code more involved: else if (llDetectedKey(i) == llGetOwner()) //owner { string text; integer length = llGetListLength (inventory_items); integer index = 0; while (index < length) { text += "\n" + llList2String (inventory_items, index) + " x " + llList2String (inventory_items, index + 1); index += 2; } llOwnerSay(text); setTitle(); } The other way might be to keep parallel lists, one with the name of the items and the other with their counters. This way the item name and it's counter would each have the same index in their own lists. But the strided list thought came to me first, so that's what I'm sticking with.

I've only skimmed this thread so I've probably missed something important somewhere, but I don't see any mention of llLinkParticleSystem anywhere.

But should you tip the creators of the freebies or the proprietor of the store? Or both?

You're right that you need to change the owner stuff to user stuff. When you give someone a copy of the bike they become the owner, so the owner stuff works ok. But when you rez the bike on the ground you remain the owner. Exactly what you need to do depends on how the script handles the owner stuff. If there's a single call to llGetOwner and the resulting key is stored in a variable then it'd be fairly easy to give that variable the key of the user when they sit on the bike: something that can be done in the changed event when CHANGED_LINK is set. If, however, the script is peppered with llGetOwner calls, you'll probably want to create a global variable with the user's key and replace all the llGetOwner calls with that variable. Also, you'll want to replace any llOwnerSay calls with llRegionSayTo calls targeting the user. There is one minor drawback to what I've described above: bicycle theft. Any user will be able to grab the bike if they sit on it before the legitimate user does. Counteracting that would require a more involved rezzing process, where the bike is sent a chat channel number via the on_rez parameter, and then listens on that channel for the rezzer to tell it the key of the intended user. Of course, these things never turn out to be quite as simple as they seem at first glance.

There's "Always show friends normally" just above "Show Friends only" in that menu, and just above that is "Avatar Render Settings" which allows you to make a list of avatar names marked "Render Fully" and "Do Not Render".

Also, if you've already pasted the code as plain text you can select it and then click the <> icon to convert it.

touch_start(integer num_detected) { ToucherID = llDetectedKey(0); ToucherOwner = llGetOwner(); if (ToucherID == ToucherOwner) { llListenRemove(listenHandle); listenHandle = llListen(dialogChannel, "", ToucherID, ""); llDialog(ToucherID, dialogInfo, buttons, dialogChannel); llSetTimerEvent(60.0); // Here we set a time limit for responses } }

In the touch_start event you're collecting two ids, that of the toucher and that of the owner. So to make things owner only you should check that the toucher is the owner before going on to open the dialog. if (ToucherID == ToucherOwner) { //open the dialog }

It's not something that's happened to me, but there do seem to have been quite of few questions about this in the Firestorm Support chat just recently.

The issues of over a year ago may not be relevant today. But, with the Firestorm Support group chat running as a sort of background music, I do have the impression that there's been a bit of a spate of "Failed to grant capabilities" just recently, though it's not something I've experienced myself.

The error, realised on line 23, seems to be an extra closing brace "}" on line 20.

You can move a linked prim using llSetLinkPrimitiveParamsFast with the PRIM_POS_LOCAL flag. You'll want to find the best positions for the maximum and minimum speeds, and interpolate the actual position based on the actual speed. Something like this, perhaps: vector emitter_pos_max = <something>; vector emitter_pos_min = <something>; vector emitter_pos_range; float speed_max = something; float current_speed; default { state_entry () { emitter_pos_range = emitter_pos_max - emitter_pos_min; } some_event () { llSetLinkPrimitiveParamsFast (emitter_link_number, [ PRIM_POS_LOCAL, emitter_pos_min + (emitter_pos_range * (current_speed / speed_max)) ]); } }

Not sure if this is helpful, but when I messed around with a variable bow wave for a boat I ended up using a linked prim as an emitter and moved that prim forwards and backwards along the keel as the boat tilted in response to its speed.

Bottom left of your wishlist page: View and share your wishlist. The link address is in the form https://marketplace.secondlife.com/wishlists/Your.Name.

Mismatched braces (curly brackets). Remove the one in line 13, and put a closing brace after line 18. You get the syntax error on the timer because that's where the compiler realises something's wrong: two lots of opening braces without their corresponding closing braces when it hits the timer event code.

Ok, but the OP used the words "menu" and "anymore", which suggests to me that they at least used to be scripted.

Have you tried clicking on the thing you're sitting on? And have you tried right-clicking it and selecting Touch? It could be that the object's scripts need resetting, but that'd be a job for the owner.

Thanks, everybody. It seems there isn't a clever trick that can be used for this, so brute force it is. And, Rolig, I remember the time before llSetRegionPos and before llGetAgentList when those drones had to scamper around in ten metre steps and you had to check the conditions for each step if you wanted to be safe.

As I understand it, just accepting the Tilia ToS doesn't require any additional information beyond what LL already have on you. It's when you "cash out", "process credit", withdraw real money from your LL account to the real world that you may be required to provide positive real life ID.

This is for any parcel, anywhere. If it were just for my parcel, the size of the llGetAgentList return wouldn't be an issue.

Also sensors have a range of only 96m.

Is there a clever way of getting the number of agents in a parcel, other than getting the list length returned by llGetAgentList (AGENT_LIST_PARCEL, []);? I want to do this in an existing script that's already using near the full memory capacity without causing a stack-heap collision.