Honey Puddles

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.

I'm going to assume that you already have some kind of inworld store. If you want to sell items on your webpage, what you'd need is a way to accept money. There are really two ways to approach this. Accept an outside payment like Paypal (for example) Allow the user to pay with L$. If you're going to accept an outside payment, you'll need some way for your server to know when it's been paid. Email often works well for this, and there are processes you can use to identify a properly formatted "you've been paid" email from sites like paypal. From there it's a simple matter to automate delivery. Your mail processing script sees a "you've been paid" email, and then sends a separate email to a prim inworld. A script inside that prim then reads the information in the email, and delivers the product specified, to the person specified. There are other variations on this theme, for example, instead of sending emails in to SL, you can utilize an inworld script to have it call a php script every few minutes, on your webserver. That php script could then tell the inworld script if any deliveries are pending, and the inworld script could act on that information. If you're going to accept L$, you'll probably want to devise some sort of "terminal" where people can input L$ to their "accounts" and then withdraw any excess. So if I liked your products, I might put 1000L$ on account with your system. Then every time I "bought" an item on your site, you'd deliver the item, and deduct it's cost from my balance. At any point allowing me to withdraw the L$ I have left in the system. The downside here (and why you don't see more of this) is twofold. Firstly, it requires you to keep ALL THE L$ ON HAND. The sum total of every balance of every user account. If you don't, won't, or can't keep that much liquidity on hand.. then you risk severe legal troubles should your account holders all decide to withdraw their funds while you're unable to comply. Second, it requires that the customer "trusts" you with their deposited funds, upfront. That's something not at all easy to earn, especially with the number of people who have lost money over the years due to so-called "banks" and "stock markets". While it sounds really cool and professional to offer products directly for sale on your website, you may find it much easier to simply list your items on the SL Marketplace, and then provide links from your site, to your listings. This way you can outsource all the money handling nonsense.. and you don't have to stress so much on getting all the scripts to work correctly. The marketplace has been going through some technical issues over the last couple of months, and reliable delivery isn't what it once was. However it is still the "Go-To" place for out-of-sl shopping.

To receive money in second life, all you need to do is send the payer to your profile. https://my.secondlife.com/sarincyanide There's an option called "pay" under "actions" (though they'll need to have an SL account, and be logged in to see the "Actions" menu there. If you're dealing with inworld people, they should know how to open your profile and from there should be able to pay you. If you're dealing with outside people who don't have SL accounts, then you're reaslly asking them to go through an awful lot just to send you some money. In that case, you really do need to get set up with paypal, or one of the other online payment alternatives. Also, if you seriously expect people to send you money, the least you could do is fill out your profile with some information. Nothing says "take the money and run" like a blank profile.

jeanie Irelund wrote: i need to speak on live chat https://support.secondlife.com/contact-support/

Try putting that script in the main prim... or try unlinking the lamp and relinking it so that the prim with the script is the main one.

incubators for their young.

And I'd like to give Kudos to Penny, because I like to encourage positive use of wit and humour.

If it's group-owned land, you'll probably need to "Deed" the TV to the group. Also remember that there can be only one "Land Media Stream" per parcel... so if you have multiple neighbors living on the same parcel, changing the station on one TV changes the station on all TVs.

Wrote this workaround script for a friend. Create a new script in your inventory, and replace the default ccode with the following. default{ state_entry() { llSay(0, "[Prim Count: " + (string)llGetNumberOfPrims() + "]"); llRemoveInventory(llGetScriptName()); }} Then drag and drop the new script onto the objects you're working on. (obviously this only works for objects you own with modify permissions)

workaround script. Make a new script in your inventory, paste this into it. Then when you drag this onto an object, you can get it's primcount. default{ state_entry() { llSay(0, "[Prim Count: " + (string)llGetNumberOfPrims() + "]"); llRemoveInventory(llGetScriptName()); }}