Anna Salyx

What I do when I need multiple timers is a global variable to set the 'end time' for the timer tick against unix time. then compare the current unix time against the variable on each timer event. This works for me as it helps me keep straight (if I use good var names) to know what's fireing on what intervals. Now granted most of my timer needs are at intervals of more than 1 second, usually a minimum of 10 seconds, so I'm not sure how accurate it would be on fast pulse, but I don't really see why it wouldn't . You could also reset the variable after the 'do stuff' is finished simply by calling a get unix time + x at the end of the function. this would allow time for things to finish before setting up the next pulse interval for it. Anyways, hope this helps spark some ideas for you for example for a 1 mintue and 3 minute timer integer gTic1; integer gTic2; default { state_entry() { llSetTimerEvent(1.0); gTic1 = llGetUnixTime() + 60; gTic2 = llGetUnixTime() +300; } timer() { integer lTic = llGetUnixTime(); if (gTic1 > 0 && lTic >= gTic1) { //if done with timer is true set gTic1 to 0, // else gTic = lTic + 60 do 60 second stuff } if (gTic2 > 0 && lTic >= gTic2) { //same logic of setting to zero if done, // or resetting to another 5 minutes out. do five minute stuff } } }

"As a security measure, parcel owner, estate owner, and estate managers can not have their objects returned by this method, except when the object returns itself. " I"m thinking that since you own the object being returned you cannot use this method to return it. So going back to your original question, I'm not sure if there is a good solution.

I think of Elsie till this very day I remember how she´d turned to me and say: "What good is sitting all alone in your room? Come hear the music play Life is a cabaret, old chum! Come to the cabaret!"

You defined "my_list" as a global in the header section but you also redefine "my_list" with the list keyword in the touch_start event. That second time that "my_list" is defined in the event creates a local version of the list that is limited solely to the event and does not get passed to the function when it's called. So when you try to set the "end" variable in the function with the call to get list length it's using the empty global "my_list" and is set to zero. The for loop does its first check and since i equals end (both zero) the for loop exits immediately and the function exits normally. It displayed nothing since there was nothing to display. twice. If you emove the keyword "list" here (as shown here), the script and function will work as epxected. this one is a bit hard to see because it works without the function. the creation of the local instance of 'my_list' is hidden and because everything is local to the touch_start event, it all works like you wanted it to. touch_start(integer total_number) { my_list = [ "1023:1000", "Reminder 1", llGetOwner(), "0712:1800", "Reminder 2", llGetOwner(), "0123:1153", "Reminder 3", llGetOwner(), "0123:0000", "Reminder 4", llGetOwner() ]; edit: to clear up some of the wording and to add a few clarifying comments that I realized after the fact were needed.

A few that come to mind for me: DV8 PixelDolls Angelwing Material Squirrel Mischief (**MIS**) / JANE! (Jane! still has a MP but i've not seen anything new in a few years now) (Janie Marlowe started with MIS and sold that brand and started up Jane! after. both brands are now gone as far as I can tell). House Of Europe (HOE) Wetherby's VoguE Mentine Sassy edit: Oh and Burroughs. Jewelry and eyes. Best eyes I've ever found even now and the ones I still use, I got from them in 2011.

At the risk of falling into a circular logic flaw, I'd say one reason that flats and high feet sell so well is that is essentially the only options available. All feet have some combination of flat, low, mid, high, and point options, but we generally only see the flat or high and so if we want to wear shoes at all, we buy flat or high. I, for one, am always on the look out for mid and kitten heels and boots. I might be wrong, but I think if more designers started offering up the those options they'd see regular sales enough to encourage more. My suggestion to the OP is to startup a conversation topic about this in the fashion forum rather than down here. It might gain better traction and expose the content creators to the idea that maybe there is a valid market for the shorter heels.

Also you can have the hud detect when the avatar leaves the region, via the CHANGED event, and auto detach/delete when they do that if that is a desired action. Having it auto detach/delete when the avatar leaves a general area is also possible but require a bit more coding

That they did, which is why the IRS clarified. Fortnight and similar are real money in, no real money out, as opposed Linden dollars being real money in, yes real money out. It is a convertible virtual currency under that specific definition: ie: convertible back to some real world currency a defined but variable exchange rate. And that is the specific clarification that the IRS made in their publication. I think that maybe the fact that is has a variable exchange rate in and out depending on "market" conditions just enhances that idea. But I do agree that calling the in world tokens 'dollars' while accurate does add confusion to the mix. there needs be more clarification in the tax code and publications. I don't have a CPA. I only file the 1040 long because I'm forced to by circumstance (head of household with dependent), otherwise I'd be filing 1040EZ and not worrying about any of this

I get what you are saying, however on form 1040 (which I file) (Schedule 1) for 2019 there was this: "At any time during 2019, did you receive, sell, send, exchange or otherwise acquire any financial interest in any virtual currency?" It threw me for a loop to be sure because it was a brand new thing that directly tied back to my activity in SL. Yes, I understand that by the IRS's only publications they are listed as property for calculations related to capital gains, but still, it is now at this time being required to at least report yes/no if you ever got any during the tax year, with the clarification that only those virtual currencies that can convert back out to real world currency need be included in the declaration. But the inclusion and wording of that declaration line leads me to believe that it's not going to be long before more detailed reporting may be on the horizon. again, must my take. My receiving Linden Dollars and the subsequent spending of those same Linden Dollars for goods and services even if I never cash out can be a form of ... imputed income is the phrase that comes to mind, but I"m not sure if it's wholly accurate. But the crux is I'm getting goods (even if but virtual) that I would normally have paid real world dollars for. Since I have a regular Second Life income I never have to convert "real world" money into the system, but sans such income I'd (arguably) be spending that same equal real world cash value and so it can be construed that I have received that real world value of goods and that the virtual income is form of actual income that can be directly calculated. I'm not an expert by any means. this is just the understanding I have from casual reading and talking with people who *are* better educated on the subject. so it might my worry has less basis, but I'd rather try to get an understanding now rather than having a sudden unexpected kick later. ps: ( and yes, I know my thresholds are waaaaaay below what would be a notice, but even so, if I have to start accounting for the virtual currency is going to be a pain. With luck it'll just remain a declaration and if my transactions through Tilia/Second Life never exceed the threshold that forces Linden Lab/Tilia to require a W-9 from me, it'll be just that, a check box I have to remember to tick every year. )

Since 2013, the U.S. Financial Crimes Enforcement Network, recognized Linden Money as a convertible centralized virtual currency for purposes of tracking for money laundering and other things (if I'm reading things correctly in a quick search). But it probably wasn't until Tilia came along as a registered money transfer service (subset of MSB, again if I'm reading it right), that this became something that is drawing the attention of banks and other institutions. It might be related, also, to the fact that starting with the taxes I filed this year was the question about if I held any virtual currencies. The wording of the IRS description originally included pretty much all virtual currency tokens, but they clarified it to read: "We have changed the language in order to lessen any confusion. Transacting in virtual currencies as part of a game that do not leave the game environment (virtual currencies that are not convertible) would not require a taxpayer to indicate this on their tax return." While this is directly aimed at bitcon I'm sure but it does leave Linden Dollars still in that category of being required to be listed on the IRS tax forms since it is a convertible virtual currency. It might be this that is helping to drive the practice of considering L$ purchases as a cash advance. Another would be that, while it would at a loss, I could buy 20 USD worth of Linden Dollars against my CC, turn around and immediately sell them back getting a USD balance that I then transfer to my bank account. Yes, I don't get the whole 20 back after fees and such, but it's functionally a cash advance that would bypass the cash advance flag on the credit card. So, IMO I think there are a lot of little things going into the reasons why PayPal and some credit cards are changing how they classify the purchases of virtual convertible currencies. again, IMO I think it's mainly due to recent IRS changes. There is a very good article on the subject of virtual convertible currencies on Investopedia from March of 2018 that might be good reading for those interested. Anyways, that's my quick take to add to the mix of conversation.

Nanokini by Insanya.

I came to say much of what Drakonadrgora but they said it much better I just wanted to add that If you are looking for a comprehensive wardrobe management system, you might look at the CTS Wardrobe. I know a few people who use it and like it, it's just not for me, personally. it's got a visual web interface too which is a plus, but also it's a downside if the maker ever stops supporting it. that's a caveat to be considered. But if you are looking for a simple, i just need to swap things out occasionally, add/remove huds, change shapes, etc. find a scripter and see if they can make you something that's light but easy to use if there's not a system to your liking already on the MP or in stores inworld.

A 3rd reason is what is referred to as "ghosting". Sometimes during a teleport between regions an attached item becomes detached upon landing/appearing in the new area, but your viewer doesn't detect that. So your viewer will still render it, but nobody else can see it. One clue that an object has been ghosted is you can't take it off. In the past the solution was to relog and get your viewer to refresh your worn object, but with some recent viewer updates there is now an option on the Avatar health menu to "refresh attachments" which will force the viewer to recheck what's worn and replace/re-attach those that are not actually there. Most often ghost happens with bodies and huds but I've seen it with other attached objects as well. Most of the time when somebody tells me that can't see a something I know I'm wearing, my first act is to refresh. Ditto if a hud is suddenly not working and I know I'm in a script enabled area. Wulfie already showed an example, but let me add a bit to that, if you are using Firestorm or another RLV enabled viewer. There is a bit of a quirk in the RLV code that allows people to dress and/or attach items to your avatar from a special directory. In the original implementation, you had to "tell" your viewer where the object was to be attached by renaming it with the attach point added (ex: fancy gloves (left hand) ) or in the case of no mod items in a folder whose name was or included the attach point. In more recent version of this feature this is not strictly required anymore but the code for it remains. Where this becomes significant is if you try to organize outfits into logical folder it can result in 'unexpected' behavior if you're not fully familiar with this behavior/standard Case in point. I was setting up some outfit folders and so I made the parent folder something like "day casual outfit 1" and to be neat and orderly, I created the following subfolders : top, pants, shoes and proceeded to put in the appropriate clothing I wanted associated with that outfit. So, when I wore "day casual outfit 1" everything was attached as expected but because the one folder was named "top" Firestorm dutifully attached the shirt to the hud TOP (keyword) instead of my body (at whatever slot). I saw myself just fine but nobody could see the shirt. It took me a while to crack that one. Moral of the story, don't put wearables in folders named top, bottom, or center. and because Firestorm (and I guess other viewers) remember the last slot an item was attached to, simply wearing/adding it didn't fix it even after I renamed the folder to shirt. I had to manually right click and attached so some point on my body. After that everything was back to normal.

They have presented this class at least one time before this one, maybe they will do it again.

oh, good! I was looking for the derail point so I could inject my little bit of self humor further down /lol I used to do that when i first started in SL. A few years later it was, "meh, just dump the stuff to inventory and i"ll sort it out later." now 10 years later, I have to file a travel plan a week in advance of venturing into my inventory, plus I have to carry extra supplies and hire a S&R team to come looking for me if I've not checked in on schedule or are more than 24 hours late from my expected exit time. Trust me after 10 years of treasure hunts, it's not a pretty place in there....... I think they tried. It didn't work out so well. /shrugs. seriously though, fwiw, I like what we have, quirks and foibles and all...

from the notes on llDialog: "If the listener resides in the same script that created the dialog, then the dialog button is heard sim-wide." So the concern of llDialog, while important and needs to be considered, only really comes into play if the receiving script for any llDialog calls is different from the actual calling script.

It would be interesting to find out. I think a big push is also just as likely to reduce the chat ranges not extend them. I have always disliked that that normal chat is 20 meters, whisper 10. My preference is always to have those values halved *except* in club settings. But I realize I'm probably in the minority there. But however it's sliced, if the chat range changes are at the region level, I honestly don't see them being adjusted much in a broad sense when you have mixed use regions: stores, clubs, housing. If adjustments are used in such regions, it might to restrict the ranges so that chat is more easily confined to the parcel level. In those scenarios, extenders might become *more* prevalent in clubs not less. My wish list would be that chat range changes be done at the parcel level and be only effective at the parcel level and up to 10 or 20 meters beyond the parcel border at which "normal" rules apply, but that might be too much overhead to process to be practical. Just a few extra thoughts on the topic and probably my last since I don't want to stray to far from the forums purpose which is scripting

I think one of the confusion points that is being danced around is that its less about what 'channel' (whisper, normal, shout) that my script is getting the message from (and I'm sure it is important to some) is I need to know if a given chat range is been reduced. I have some project objects that whisper to child objects and avatars in close proximity, with the expectation that they will be within the 10 meter 'standard' range. if that range is reduced to 5 meters then potentially things break if people or objects are placed at 6 to 9 meters from the central sending object. Being able to check a region setting that tells what the whisper range is will allow me to have the script better understand if the broadcast is being received by all of the intended audience On the other point on being able to know the chat dynamic type (whisper, shout, etc): is an example of the chat extender that I use. It hears the avatar, and checks the area and determines the distance each member of the intended audience from the speaker. If they are in normal chat range (20 meters) that person is excluded from the relay and the message is only relayed to those that are > 20 meters. When I accidentally whispers (which I do about 1/5 of the time) everyone 1 to 10 meters 'hears' me, those >20 meters 'hear' me via relay, but those >10 <=20 currently get nothing. The relay assumes they heard it and doesn't serve it up to them. So, the ability to detect a whisper or shout that can be dynamically accounted for and would be of great help. No more missed messages for those close in, and also no more duplicated messages for those further out: Oh the person shouted, I'll not relay to anyone inside the default (or current) shout distance. Lastly and one important point: as I understand it, the chat range changes are going to be region based only and not parcel based. With this assumption the changes in chat ranges my not be that wide spread or might only be minimal. Chat extenders, again for example, might still have their place where some regions want to make only tiny changes to the default ranges (reduce or extend whisper and normal in some combination and tweaking shout or not as fits their needs), but parceled off places like clubs, classrooms, or lecture/presentation hall might need a different rule set and chat extenders might still be able to accommodate those situations. I know I'm not going to want to be in renting a shop parcel and have the club parcel on the other side of the region "chatting" normally into my shop, so there are going to still be limitation to just how much chat ranges are extended based on regional make-up. At least in my mind that will be the case. But If the chat range changes are going in a parcel level then that's a horse of a different color and ignore mos of what I said here. lol Awyways, that's my thoughts on the matter while I still digest this news.

I've used state changes for that. Set the item to be given in a state called "unused" and does it things and then does a reset script at the end and the default state handles any "I can't be used anymore" messages and actions on the attach handlers and state entry. set the script to nocoy and voila.

You can still use that even with your 15 min window at the end, it just complicates things a trifle. Have the object send a message on a control channel, along the ID of the avatar when detached. (no more sending back to starting point, but oh well). Have a room object/sensor listening for that detach event from the mask and send whoever removed the attachment home. If you are at the end of the party, the host can deactivate the send home control device and everyone can take off their mask for the reveal at the end. Perhaps you can even incorporate that in to the masks and event: have the room object when deactivated send it's own control message on a common channel to all the masks to detach when the "room sensor" is turned off. You get the benefits of sending people home right away still, and you have a benefit of everyone does the reveal at the same time. That last bit night be an iffy option if some people might want to leave at the end so as to remain anonymous, but it's an option you can look at. Just thoughts and brainstorming ideas. Good luck.

I'm curious -- as a temp attached object, is the attach event raised when the object is removed/detached? If it is, you might also try to act on that short window when the avatar manually removes the mask to return them back to the "start point". Then use the the room sensor act as a backup to send them home if that fails. If that would work it would have the duel benefit of not only removing them immediately, but also elegantly sending them to the "threshold" area instead of simply 'home'.

Lol no no no. I mean, yes, I'd like that but we are used to login problems doncha know... I mean, we need to give newbies and returning people some priority on logging in so we don't scare them off right out of the gate. /evil genius laugh (or is it just creeping madness )

Keep in mind that the body will need a linked mesh layer over the left arm/left foot that are mapped to use the BAKED_LEFTARM and BAKED_LEFTLEG for this to work. the only body that I have first hand experience with implementing native BoM (not triggered by a relay) is Maitreya -- and it doesn't (yet at least) support those channels, just the BAKED_UPPER and BAKED_LOWER, ignoring the rest. Other bodies may be doing something with those channels, but if most bodies are similarly just mapping the UPPER and LOWER channels, then that'll make that function of the universal wearable fairly useless.

Not to derail too much here, but I've always wondered by blacklisting RLVa commands is a nope. there are a couple I'd love to blacklist out, mainly the "permissive" command along with the "secure" forms of some comm restrictions. is there a simple explanation that can be shared maybe? Thanks.

Another way it to just grab the local texture's UUID and plug that into an applier and do your major tweaks and edits as a standard applier level creation. That gives you the ability to see the changes in real time coming out of your preferred texture editor. Then, after you are mostly satisfied with it, upload it to use as BoM. From there it'll either be what you want or you'll need only very minor tweaks. Coupling this with the preview grid Sean pointed you, will make the costs minimal and the process flow a bit smoother and less frustrating. It's works for me at least.