Honey Puddles

That's pretty much exactly what I tried.. the problem is that for whatever reason, these changed events queue up while the setting is happening, and when I go back and flip the flag to false, and end the function, the changed event fires with the queued changes. I was shocked that changing states didn't solve the problem, but I suspect there's also some latency between "do thing" and "detect change" that's allowing it to detect the changes after they've ended.

So I've got a real puzzler here. I made a script, which is supposed to work with another script. that second script, I don't have a lot of control over, but it would be able to hide or show various parts of the linkset, including what I'm going to call "straps and buckles" Now these straps and buckles, being hidable or showable on demand, presents a problem, in that I have some "lock" prims, which are hidden or shown by the script I'm actually writing. The locks attach to the buckles, and when the buckles are hidden, the locks need to be hidden too, whether the script says it's "locked" or 'unlocked". So I've written a function, which triggers on CHANGED_COLOR.. it scans the linkset for any strap prims.. and on finding them, determines whether they're visible or invisible, and then acts accordingly to hide or show the locks, based on the current state of the "locked" variable. That's all working beautifully.. but here's the problem. When the script I'm writing turns those locks visible or invisible, that linkset change is in fact, triggering the CHANGED_COLOR event again! Which results in my script checking for the presence of the strap prims, checking their visibility, and then checking for lock prims, checking their visibility, comparing that to the locked variable, and if they're the same, it does nothing... ending the loop. My problem however, is that this process is needlessly "hot". The second check is completely unneccessary. I've tried changing to a different state to make the changes, I've tried setting a variable "settingLocks" to true while making changes, and then false when done, and filtering the changed event based on that.. but no matter what I try, I just can't seem to get the script to ignore the change. My workaround (checking the current visibility of the locks before deciding if they need to be changed) is fairly rudimentary.. Is there a better way to go about avoiding this recursion problem?

The bit that gets me, is why aren't the Lindens blogging about this? Something this "Inconsistent-Experience" generating going out to the grid, without a word from the Lindens like "hey, watch out, we're trying to get this out as fast as we can to all the sims, but we need a bit more testing, please bear with us, and sorry about the vehicle problems".

thankies. :matte-motes-bashful-cute-2:

No, not quite. http://i.imgur.com/v66ul.png

I got the email, but the link to "find a gift kiosk" doesn't seem to work. I just get a broken looking Secondlife.com page, with no links (it shows my name as "Second Life Resident") Anyone got a list of Gift Kiosk locations?

Sandboxes: Excellent.. ...though I do echo the sentiments of others who have asked "Are there going to be adult sandboxes?" Some of us would like to work on things that aren't totally G-Rated now and again. It would be nice if there were places to do that without breaking the community standards. Freebies: Okay. Pretty Nice! .. Speaking as someone who sells furniture (among other things) there are literally millions of competing products on the market, of all different styles, qualities, and price ranges, and one more widely distributed freebie isn't going to destroy the entire market for furniture, or for anything. And honestly, I kind of need some new furniture for my own house. I will check this out and see if it suits my needs. It WOULD be great to know how we (as content creators) can also get this kind of awesome advertising opportunity, by making freebies for LL to hand out. Edit: It's a pretty nice couch actually, and it's nice that it seats two. The whole set's really pretty decent, but I think only the couch really suits my living space. Shame about it all being no-modify though.

keviprincess246 wrote: i have a bad internet connection, so sl crashes alot for me, which is expected. i crashed and tried to log back in when my connection perked up and sl made me install the new update. suddenly all these errors and plug-ins cane install and i'm not sure what to do. the updaate wont install SL completely at all so everytime i try logging in it forces me to install again and i go through the same issue. what do i do to stop this madness?!?! REBOOT YOUR COMPUTER. Your application crashed, and has improperly left some dlls or other services flagged as "in use". (quicktime for example?). These files cannot be overwritten, because the system thinks they are currently being used. Rebooting your computer should reset this issue. Then once your computer is back online, DON'T launch SL, instead, visit http://get.secondlife.com and download the latest full installer, and run that.

We're in a transition phase right now, coming from a time when accounts USED to have unchangeable "first and last names" where we'd pick a lastname from a list, and then make our own first names. (example: Winter Ventura.) We were then given display names, changable screen names that we can opt to change as frequently as once a week. (example: Candy Velvet). Along with that new feature, LL changed the naming convention from "first and last" to "login name" (example: lamplady2001) There was a lot of concern when this first was introduced, that people would use it for harrassment, greifing, fraud, etc.. these are fears that have for the most part, failed to materialize. The fix, was to make both names visible over the avatar, as the default setting. Each name can be independently hidden, but it's the person reading the names, who sets their own preference. So if I want to see only "usernames" I'll only see you as "lamplady2001". If I want to see only "display names", I'll see you as "Rain". If I want to see both names, I'll see both your names. Eventually, LL will no-doubt begin setting "Username not visible" as the default setting. edit: sorry was stiull waking up when I wrote this

That avatar visibility project on BlueSteel looks pretty sweet. Pocket universes, at least in terms of avatars and local chat. Finally we can have a little privacy by going into the next room. (assuming we parcel off the room). /me starts rethinking her house's layout with this feature in mind.:matte-motes-big-grin-wink: One question: How will the parcel settings affect talking/shouting objects and attachments?

see "Communications" which *is* on the front page http://wiki.secondlife.com/wiki/Category:LSL_Communications or "Text > Chat" http://wiki.secondlife.com/wiki/Category:LSL_Chat

Check your viewer's graphics settings, and make sure you have "Terrain" detail turned to "high".

I can't beleive I didn't make a whole run of 20 x 32 x ___ prims. The default size of a 512 parcel.

It was a compromise. There was a lot of back and forth over this single issue by the Mesh beta testers. Powers within SL wanted to keep it 10m forever. Others wanted sim-sized prims (256) or larger. What we got instead, was a prim large enough to tile a whole sim, with only 16 prims. But a prim that can only overhang 32m into a neighboring sim (unless linked to another prim but that's besides the point). Why 64 and not 60 or 65? Because the minimum parcel "block" is 4m x 4m. So having a maximum dimension that was a "power of 2" (4, 8 16, 32, 64, 128, 256) was a good and logical thing.. something that people have been complaining about at least since 2006 when I joined SL. (why limit us to 10 and not 8 or 12 or 16 when our land is always in multiples of 4?). Now we get 64. And 64 is the minimum draw distance. And 64 is a good and responsible size. Not so large that you can rez it and not be able to see it cause your draw distance is too low. Not so large that a griefer or a noob can disrupt a whole sim just by rezzing one. and still large enough to create really beautiful sky domes, and very useable platforms, and really dramatically reduce the number of prims used in roads, sidewalks, and buildings. 64m is really just about perfect. And presumably, old megaprims >64 will continue to work.

if you're asking from the perspective of a builder... use smaller textures. There is almost no circumstance in SL that requires a texture larger than 512x512. In fact most textures, particularly for attachments, can top out at 256x256. Skins and clothing textures should NEVER be larger than 512x512. Because the client loads all the layers, and then "bakes" a flattened composite image that it sends to the server for distribution to everyone around you. That composite texture is 512x512, so using higher resolution clothing/skin textures REALLY is just wasted effort that makes loading those textures take longer. Similarly, the largest a sculpt map should ever be is 64x64. (oblong sculpts should be 128x32 or 256x16 or 512x8, etc) You gain absolutely NOTHING by making your sculpt maps 128x128 or larger.

Can scripts in child prims animate the avatar? I seem to recall there was some oddness with child prims in attachments requesting permissions. What you are doing, is wrong. it is bad. I can't begin to tell you how wrong and bad it is. For one, your entire project SHOULD be able to be one script. You're telling me it's 10. Secondly, if you really want the end user to be able to modify it, then maybe you should pass this stuff to a notecard system. Thirdly, your use of buttons is kind of pointless, because all it does is make it HARDER to modify, and increases lag by a factor of 10. Try this instead. Create a notecard. In the notecard, make a list of animations, like so disco|disco1 disco|disco2 disco|discorage waltz|waltz1 Then have your script parse the notecard line by line, splitting the line up by the "|", it can determine which group the animation should be added to, and can keep a running list of the active groups as well. Let's say we make a max of 11 groups (+1 for STOP). list group0; list group1; list group2; ... list group10; list groups; Now as you go along, you check the group name of each line in the notecard. is it in the list of groups? if so, use that group number, if not.. add it to the list of groups, and then use THAt group number. When you're done, you'll have list of groups, and the number of that group name in the list of groups, will be the same as the number in the grouplist's name... for example... llListFindList(groups, ["disco"]) will equal 0, and coincedentally all the disco animations are in group0. so in a listen for the dialog... integer groupNum = llListFindList(groups, [message]); Then we do an if tree.. if (groupNum == 0) dowhateverwith(group0); else if (groupNum == 1) dowhateverwith(group1); else if (groupNum == 2) dowhateverwith(group2); At this point, you now have a list of all the animations in the selected group.. say we have a 10 item limit, saving 2 buttons for STOP and BACK. So you have your list of groups, that you can use for the main menu, and you have an easy way to determine which group list to use, based on which group is selected from the main menu. Note.. you will have to deal with the issue of "what if the group or animation names are longer than button names". That;s not an easy issue to solve though. You could stride the list, and then apend the notecard linenumber that goes with that button, and then when that button is pressed, read the notecard line number, then pass that to a function that reads the animation name directly from the notecard, and plays it.

Blaise Mistwalker wrote: The problem is still in using llGetLinkName and converting it into the appropriate dialog button to correspond to the specific link message. Why is that a problem? If you don't explain the problem, no one can help you.

Since you're using animations here instead of radio URLs, the process gets weirder. On one hand, you could have your script just use llGetInventoryName(INVENTORY_ANIMATION, 0) to get the name of each animation in the object. You could then in theory, use llSetLinkPrimitiveParams in a similar loop to the one I showed you before, to have it go through the linkset and SET the name and description of each button in the linkset. Moreover, you could just have prims named "button" and then JUST use their descrptions to store the proper names of the animations. the button prim names don't NEED to be unique. default{ state_entry() { integer animCount = llGetInventoryNumber(INVENTORY_ANIMATION) - 1; for (i = llGetLinkNumber() + 1; i <= llGetNumberOfPrims(); i++) { if (llGetLinkName(i) == "button") { if (animCount >= 0) { llSetLinkPrimitiveParams(i, [PRIM_DESC, llGetInventoryName(INVENTORY_ANIMATION)]); animCount = animCount - 1; } else llSetLinkPrimitiveParams(i, [PRIM_DESC, ""]); // not enough animations, blank this button } } } changed (integer change) { if (change & CHANGED_INVENTORY || change & CHANGED_LINK) { llResetScript(); // animations or number of buttons may have changed.. reset. } } } Something like that SHOULD work, setting the description of every button prim to either the name of an animation in the parent prim, or setting it blank. I'm sure you could work out other ideas like setting that button invisible, or turning it dark grey Of course this idea is totally dependent on linkorder, and that can be touchy sometimes. But it's an idea to get your mind working on your project. You might consider, for example, having a texture with the same name as the animation... and then loading that texture as the texture for the button. Or you could chop up the button prims so that they display their hovertext right on the surface of the button, and then you could use PRIM_TEXT to display the animation name on the button itself. Just some ideas for you to play with.

Why are you using a dialog at all? Why not just use the touch event? My Radio Hud name: punk | desc: http://punkurl name: rock | desc: http://rockurl name: latin | desc: http://latinurl Now use something super simple, like this default{ touch_start(integer touches) { if (llDetectedLinkNumber(0) != llGetLinkNumber()) // it's not THIS prim, let's continue { list touchedButtonData = llGetLinkPrimitiveParams(llDetectedLinkNumber(0), [PRIM_NAME, PRIM_DESC]); string touchedButtonName = llList2String(buttonData, 0); string touchedButtonDesc = llList2String(buttonData, 1); // now do whatever you want with the name and description returned. for example: llSay(0, "This is the name of the button that was just pressed: " + touchedButtonName); llSay(0, "Its description is: " + touchedButtonDesc); } }}

While I'm thinking about it, allow me to show you the world's simplest HUD script. default{ touch_start ( llSay(0, llGetLinkName(llDetectedLinkNumber(0))); )) This will say, on channel 0, the name of any prim in the linkset that you touch.

The command you're looking for is llGetLinkName(0) or (string)llGetLinkPrimitiveParams(0, [PRIM_NAME]) - where 0 is the linkset address for a given prim. Linkset numbers can be a little tricky, because the rules are a little funky. A single prim's linknumber is 0 The parent prim, in a multi-prim object, is 1 The child prims in a multi-prim object are always greater than 1 As single avatar sitting on the object will add 1 to the total number of prims but will be the largest number (so a 13 prim object, becomes 14 prims when 1 avatar sits on it. Prim 14 is that avatar. llGetNumberOfPrims() will return the total number of prims AND avatars connected to the object. llGetObjectPrimcount(llGetKey()) wll return the total number of prims, UNLESS the object is a worn attachment, in which case it will return 0. So a script to do this might look something like this list buttons = []; // a global list. you could put a "default list" here, it will get overwritten if the linkset has more than one prim.default{ state_entry() // run on script save/reset { integer primCount = llGetObjectPrimcount(llGetKey()); // no avatars, but 0 if attached if (primCount == 0) primCount = llGetNumberOfPrims(); // if it's an attachment, it can't have seated avatars if (primCount != 0) // if it's still 0, there's only one prim, so this function will fail, so we'll just skip it entirely then { buttons = []; // we blank the list each time before we load it integer i; // this is a throwaway integer, we only use it for parsing lists for (i = primCount; i > 1; i = i - 1) // start at the end and work back to "2" (use >= to include 1) { buttons = (buttons = []) + buttons + llGetLinkName(i); // this is the old way of adding things to lists, it was slightly more memory efficient when scripts were compiled in lsl. } } if (llGetListLength(buttons) != 0) llSay(0, llList2CSV(buttons); // list has entries, so list them in chat else llSay(0, "This object is just one prim, and has no buttons"); // list is empty, say so }} Important notes: state_entry is not the same as "on_rez". Functions placed in the state_entry event will only trigger once in a single-state script, unless another event calls llResetScript, or some outside avatar forces the scripts in the object to reset. If the object's buttoms are intended to be modifyable, this function should be called "as needed" (on demand), rather than once at startup. Changing the name of a child prim does not (I beleive) trigger the "changed" event, so using that to refresh the list would not work. Assuming the item was modifyable, I would put a function like this into the menu-triggering event itself, so that each time the menu was called, it would generate it's current set of buttons. One fancy idea though, assuming we're talking about a radio here, is to store the URL for the station stream in the description of the child prim. So name = button name and description = url. In that case, I'd probably make a couple of changes... namely reordering the list so that the button names are in the same order as they appear in the linkset, and counting down all the way to 0, then deleting 0 and 1 from the list when displaying. something like this list buttons = []; list getButtons(){ integer primCount = llGetObjectPrimcount(llGetKey()); // no avatars, but 0 if attached if (primCount == 0) primCount = llGetNumberOfPrims(); // if it's an attachment, it can't have seated avatars if (primCount != 0) // if it's still 0, there's only one prim, so this function will fail, so we'll just skip it entirely then { buttons = []; // we blank the list each time we reload it integer i; // this is a throwaway integer, we only use it for parsing lists for (i = primCount; i >= 0; i = i - 1) // start at the end and work back to "0" { buttons = (buttons = []) + llGetLinkName(i) + buttons; // this is the old way of adding things to lists, it was slightly more memory efficient when scripts were compiled in lsl. } } return buttons;}integer handle; // used for controling the dialog listens.default{ touch_start(integer touches) { llListenRemove(handle); // close any open listens handle = llListen(-84, "", llDetectedKey(0), ""); // open a listen JUST for this person. llDialog(llDetectedKey(0), "Pick a station", llDeleteSubList(getButtons, 0, 1)), -84); // delete 0 and 1 from the list, when displaying in the dialog } listen(integer channel, string name, key id, string message) { llListenRemove(handle); // close that listen now. integer address = llListFindList(getButtons, [message]); // where in the original list, is this button? if (address != -1) // heard button name exists in button name list { llSay(0, llList2CSV(llGetLinkPrimitiveParams(address, [PRIM_NAME, PRIM_DESC]))); } else llSay(0, "button missing?"); }} Now, chances are good, the above code won't compile on the first try. I'm doing all this scripting in the forum here, and there's no compiler here to check for missing ;s or unclosed )s. But the basic framework here should be enough to get you looking in the right directions. Edit: fixed an issue where the buttons list would get longer and longer each time

According to the breadcrumbs at the top of the page, it is. Forums > People Forum > Forums Feedback 

if I go here: http://community.secondlife.com/t5/Forums/ct-p/Forums or here: http://community.secondlife.com/t5/People-Forum/ct-p/PeopleForum I don't see a "Forums Feedback" forum. Yet if someone else posts to it, the posts show up in the "Recent Posts", and I can access it. Should this forum be invisible?

I'd rather have a fake Facebook or Google+ for SL, than have SL people getting in trouble for using fake names on Facebook and Google+. I'd rather LL brings facebook functionality to SL, than drags SL users kicking and screaming to Facebook to use their functionality there. Honestly.. I'm not sure I have any USE for the technology, but it's nice to finally have a place where I'm allowed to use it as Winter Ventura. I like Twitter, so this isn't that big of a change really. So far it's actually proved to be kind of entertaining, although only a small number of my friends are using it yet. But the technology is still in it's infancy, and it's way too early to start calling it "useless". Admittedly, there are some issues about whether the system allows users you've muted to post comments on your profile, and some small bugs relating to it's crossposting-to-twitter function works. But I think, given time to work out the kinks, we'll find that there probably *is* a place for this technology in our Second Lives. The "Reccomendations" function that matches you up to people who share your interests is probably the coolest part of this, but it's quickly becomming obvious that we need to be able divide up our friendlists to make "groups" or "circles" of friends. (hopefully with the ability to overlap circles for friends in multiple subsets). I'd like to be able to make an "Interesting people" group, and a "people I actually care when they log on or off" group.

Ther latest viewers and web-based profiles use square images.