Da5id Weatherwax

I use a number of digital calendars, both online and local. A habit I got into while living and working in the midwest, potentially dealing with folks in any US timezone, was that the first thing I did with a new calendar app was always configure it so it didn't automatically assume that the times for any entry I was creating or editing were in the local timezone, always required me to explicitly specify it. Now back in the UK and (for all but a couple of weeks of the year) 8 hours ahead of SLT the habit is still useful. I always enter the times for SL events in SLT, set to use LA time. That way, whatever timezone I happen to be in at the time, when I check the summary page or look at the phone app the event appears in the right place for my local time.

You ever played a really *evil* minecraft modpack where something is described as "expensive, but doable" ? Don't plan on it being a short project. It would be doable but complex as heck and difficult to keep the lag down. Another place where it's likely you'd have problems is animations that rotate the avatar in an entire circle. There will be places where what you want is the avatar to rotate past the "limit point" on an axis but the animation system insists on going "the long way around" instead. Sometimes you can overcome this by aggressively keyframing the transition but I've seen that fail too. Buy a wig, because you'll be tearing your hear out making Cirque du Soleil style animations

A fair point, and it is certainly *possible* for LL to build in the kind of heuristic logic required for context to be a factor. I think we can, however, legitimately debate over whether the amount of coding time and the maintenance of that code would or would not outweigh the intended saving of staff time required to respond to legitimate complaints over listings. I suspect that you and I would find ourselves in full agreement over how that debate would play out, not to mention the impact to the easy operation of the marketplace while such a heuristic algorithm is yet "untrained"

LL have had a system to flag inappropriate language in listings in place for a while, and in trying to improve its efficiency and reduce the number of manual interventions required, they have encountered a flaw that is inherent to any such system. That there comes a point where they are having to intervene to revert false positives as much, or even more than, they had to intervene to correct something escaping their filter. That much is almost a no-brainer, the folks having these ideas aren't daft, they can see that the law of diminishing returns will set in at some point. The problem is that this happens sooner than most folks think, and sooner than almost anyone proposing the idea will be prepared to admit. In my experience, and this is an argument I have had with several employers (with about a 50:50 success rate), any and all effort implementing such a system is ultimately a waste of time. There are too many "flaggable words" that can also mean something else and be correctly used in that other context. (A donkey, a fool or somebody's hindquarters? Male anatomy or a verb roughly synonymous with "to pierce"? Female anatomy or a group of bird species?) What are you going to do, flag "grease nipple" if it appears under a category indicating an avatar part but not when it's listed under machinery? Trade marks and brand names are most often everyday words or proper names, only taking on their protected and flaggable status in a specific context, and code can't read context. If my cousin ran a SL business under his RL surname he'd risk getting flagged, even if his products bore no resemblance to the RL brand that uses that name. People win disputes with corporations over this all the time - sometimes even if they are in the same business! (case in point: in St Paul, MN, "John's Pizza" has been a family run restaurant for decades - and their 'za is excellent, I've eaten a lot of them! - "Papa John's " moved into the Twin Cities and tried to force them to change their name with a trademark lawsuit. They lost.) Users mangle words to avoid simple filters. Coders see this as a challenge and build logic to detect this. In the process they also increase the number of "innocent" words or contexts a rule with trigger on. Scunthorpe. Sparse. Essex (ok, that ones probably ok to flag , use Middlesex instead.) What it comes down to is this. Without automatic filters, over a given time period LL staff will have to respond to n listings flagged by users for violating the rules. If automatic filters are introduced m of those will be flagged automatically and LL staff will therefore have to only respond to n-m listings in that time frame. But with automatic filters those filters will result in x actions that result in support tickets for a false positive and LL staff will need to respond to these, where before they did not. And, as filtering logic becomes broader and "more sophisticated", x rises at a higher rate than m does. What this means, in practice, is that with the most simplistic filters m is small compared to n and the filter provides no real benefit. As the filter increases in sophistication, eventually you reach a point where x > m and the filter becomes a detriment, not an advantage. In almost all cases, this point is reached while m is still small compared to n. So there is actually no "sweet spot" for the folks trying to refine the filters to aim for. Better, therefore, to not waste time trying to automate it at all but just suck it up and respond to complaints as they are received. In the long term this will actually SAVE staff time and company money.

The perennial "Scunthorpe problem" - residents of that city and people talking about events there are continually being edited by poorly configured "profanity filters"

Comes down to one fundamental question for me. "Am I performing a set later today?" If no: Coffee or tea through the day, whisky in the evening. Whatever I feel like prepping or cooking for food. The limits on "prepared food" in my house stop at smoked and cured meats, butter and cheeses. Pretty much everything else I prep from raw ingredients. (Guilty once-in-a-while pleasure is a bag of doughnuts from the bakery down the street. The baker and I are buddies, we talk about our sourdough cultures a lot ) If yes: Eat nothing heavier than a sandwich for the three hours before the set. A full belly really does horrible things to your ability to sustain vocal tone. Coffee and tea as usual, but no tea during the set - that can "tighten up the pipes" too.The whisky bottle stays capped until after.

"... But you know what? I didn't die. I landed on an internet doomsayer and it died. But this time around it was different. This time I did want a pickle. It's in Bellisaria." (Apologies to Arlo)

Asynchronous tasks. You have to write them both assuming that you know nothing about the state of the other task that it hasn't explicitly told you. I'd lay odds that just about every beginning coder has written themselves at least one race condition before these rules got properly wired into their heads and got burned by it. We've a lot of gifted and creative folks in SL who are not professional coders, who did not come to LSL with the mental bruises to teach them why "this is always the way you do it, even if it looks like a simpler way will work." There's bound to be a lot of this out there on the grid, and it is the nature of race conditions that they are usually exposed as performance improves. That these LSL coders are in this position of having their scripts break under a performance improvement is not LL's fault, but nor would it be fair to say that it is entirely the coders fault either. This is their encounter with that painful lesson that almost all more experienced coders have had in their own history - it is part of the "experience" that causes a 'less experienced coder to become a more experienced one. It's like triggering an animation when somebody sits on the object "knowing" that animation perms are automatically granted by a seated avatar instead of requesting them and waiting for a run-time-permissions event. Exactly the same race condition. Ultimately, since the performance improvements which expose these race conditions are now critical, I don't see that LL will have any choice but to publicize this as widely as possible for a short time and then bite the bullet and roll the update, letting the chips fall where they may for scripts that subsequently reveal themselves to have been mis-coded. Sadly, this means that where an object's scripter is no longer around or no longer supporting the object, if it contains this kind of error in its scripts that object will likely be junk. We've been there before. It wasn't pretty then and it won't be pretty now, but for all the inactive scripters whose legacy objects fall into obsolescence there will be others who are active and will create objects to fill the void, coding them to avoid this pitfall.

Your friends are wrong. Without going into enough details to be a howto for ripping, 'botters just install and configure the libraries required to hook the graphics stack (these are legitimate developer tools and freely available) and then forget about it. They can use any viewer they like, even the official LL builds. Then when they see something they want to yoink they hit a hotkey, get a few seconds freeze-up on their framerate and their local HDD contains a copy of every mesh and texture that was part of the scene they were viewing at the time. Literally nothing you can do with SL perms or silly script tricks gets in their way or slows them down. If it's displayed on their screen it's already in their system's memory, and that's where they pull it from. Stuff like easily-detectable "malicious viewers" are the tools of the distant past unless they are wanting to rip animations.

Like many, I joined during the "pick a surname and try to find a first name to go with it that hasn't been claimed yet" era. The list of surnames was - uninspiring, shall we say? - even after several refreshes, but then "Weatherwax" turned up. I am a grouchy ol' pagan IRL and Granny Weatherwax of Diskworld is just about my favorite "literary witch" ever* so that was decided. But then I wanted to use the name I go by IRL as a first name (It's not my actual first name IRL, my family has a tradition that the eldest boy in each generation goes by his middle name rather than his first, I have no idea why.) and of course "Dave" and "David" were both taken. Since my tastes in reading came to my rescue for the surname, it should be no surprise that the same applied to the first name too, and in the same way. I'm an old-school geek and a lover of cyberpunk and scifi. By substituting a 5 - to be read as a roman numeral, a V - as in "Snow Crash" I managed to name myself for two aspects of my life and keep my RL name. It was "me" on several levels so I've never used a display name and probably never will. *When the author comes up with lines like "It takes three witches to make a coven. Two is just an argument" you know he's met some of the finer practitioners of "robust theological debate".

Because there are people here who like my music and show up to hear me play it

That's not entirely true, some creators could (do) very well lose money, in the same manner some rental business owners can, even if not always on the same scale (though even that's possible-it depends entirely on the merchant's overhead). No sales at all can hit any business owner hard, especially if it's a repeated event over the course of months. All creators, all business owners, need resources... Both good points and ones I can really connect with as a performer. I pay for my stream whether I'm using it or not. Whether anyone shows up to my sets in SL or not I'm still spending those hours each week putting wear and tear on my gear, along with the same for the 5 or so hours each week preparing and rehearsing the set list I'm going to use the following week. We've all got RL costs for what we do in SL. If we run a business or offer a service of any kind inworld we're (usually) trying to make enough $L to cover those costs.

@ChinRey has a point - the margin on earning in SL is so tiny, you really do notice small movements.It's why we were looking so carefully at the changes in cashout fees earlier this year. A month that doesn't earn enough $L to cash out for fresh strings for the guitars and pay for 1/12 of my annual fee for my streaming service, keep enough inworld to pay for my workshop space and a "few" uploads is one that I notice - and it doesn't take much of a lindex movement to generate one.

You can rip textures and meshes with any viewer, even the official one, and it involves areas of the OS with a higher privilege than the ring at which the viewer runs, so can be (and usually is) completely undetectable to the viewer. I'm not going into details because that would be against the rules on publishing howtos for violations but there are legitimate developer tools that hook the GL stack or the graphics driver. Getting your hands on one of these is trivial, as would repurposing it as a way to rip SL assets be. The original "copybot" - an inworld avatar-like object that used scripting to capture the texture uuids of what you were wearing and make itself look like you - used viewer resources and its method no longer works. However, if what somebody wants to do is rip assets to local storage there is nothing LL can do to detect or stop them. Period. For it to be displayed on your screen it is already in memory on a system that you control. You already HAVE it, ripping it is just a matter of accessing it. All they can do is act on reports of stolen content if/when it is reuploaded to the grid, and this is what they do.

My anthro feline av wears pants, or a kilt. Aside from everything else there are things fur doesn't cover and unless it's BOTH somewhere that nudity is allowed or accepted AND circumstances where it's appropriate to be unclothed nobody wants to see cat-nuts dangling in full view any more than they want to see human dangly bits outside of that sort of venue or a more private setting.

you're right, of course, because there are 8 tiles that are unique and not in sets of 4.

For the tile faces, not too hard with texture atlasing. There are 36 unique tile faces in a mahjong set and a 6x6 grid of tile faces can be made at an acceptable resolution for something the size of a mahjong tile within the limits of SL texture sizes. Probably even allowing for normal mapping to give the faces the proper incised look. It's a pretty close to trivial task to write a function that converts whatever data structure you use to define an individual tile into a texture offset to put the right face on that tile. If you're going to be picky and not permit the builder to skate on your one-texture requirement for the tiles sides and back and introduce a second small texture for that purpose that makes the numbers less neat as you'd need a partial 7th row for that, but you just make sure that your function to define offsets never overflows into that range.

The reason I use LSLForge in Eclipse is profoundly unsurprising. I already had my c++ compiler(s), my perl environment and my python environment set up there. Adding LSLForge to Eclipse instead of setting up a separate environment from scratch was pretty close to a no-brainer decision.

I get at least the bulk of my scripting done offline using lslforge in eclipse. Like Rolig though, once it needs to start actually moving things around or different pieces need to start talking to each other that's when I lurk in my inworld workshop finding all the ways I broke it when I thought I was being clever...

Since it's a separate mesh as part of a linkset, you can keep it linked. Select it in "Edit linked" mode and set its physics to "none" - that's "phantom squared", makes the physics engine ignore it. Just make sure it's not the root because the root can't be set physics:none - then you can link the transparent prims to provide minimal physics.

I've been watching this thread with interest, because I too have a project slowly fermenting that is running into similar issues through having a large amount of data to manipulate. I'm SO glad somebody else has already done the painstaking research on it and I can add the same techniques for LSL-specific workarounds to my own toolbox Thank you, @animats and the other contributors here

@Coffee Jaworower - Followup. I did some research on your model of mixer to be sure I had given the right advice and the Behringer 1024 has a particular feature not common on small mixers that will work to your advantage. You have a compressor built in to each input channel. Adjust this for your vocals and your guitar independently while monitoring only that channel and adjusting its gain as you go - I don't know the block diagram of that mixer so I don't know if its PFL path takes the signal before or after the compressor, but it would make much more sense for it to be after the compressor, so I'm assuming you can be in PFL with the mixers meters showing that channel pre-fade and both see and hear the effects of the compression. Now, it's a relatively simple compressor - you have only one control for its strength, you can't adjust the hardness or softness of the "knee" in its profile and you don't have separate control over a limiter stage to explicitly damp peaks and prevent clipping so you're going to have to fall back on the sound engineers best tool, the Mk. I ear, to find the limits of how much compression you can apply to each channel without it sounding like crap. Once you've found that limit you're going to want to apply about 75% of that as a starting point and adjust the gain accordingly. You should find that you can be levelled to avoid clipping but still have a bit more "loudness" headroom on each channel - by the time you balance the mix you should find that overall your mix is louder for the same peak level on the meters at each step of the process I described above. If at any stage of listening to the main mix you start thinking you might have too much compression on either channel, do not just back it off a little and try and compensate for it at that later stage. Start over with levelling each step. Changing the compression will mean your input gain is "off" by a little (or a lot, depending on how much compression you had dialed in and how much you changed it) and each departure from ideal is magnified by the next stage, so even a small goof in input gain is almost guaranteed to give you a messed up mix by the time it feeds into the stream. I apologize if I'm insulting your experience and going too far towards "sound engineering 101" but I don't know how much production experience you have and being "too basic" for your experience at least includes all the information you actually do need, whereas erring the other way wouldn't.

You're welcome. Remember that on a stream you are at the mercy of the providers encoder and the viewers decoder, but at least that's a mostly level field. As a performer who is also their own "sound guy" all you can do is make sure you're feeding the best - not necessarily the loudest - quality audio to the stream so that it truly reflects the dynamics and sound of the performance and that when you're performing you are getting a true and accurate monitor so that you can use your performance skills effectively - you can't do that if you are hearing anything different to what is being sent to the stream in realtime Accomplish both of those and you'll sound great. Your listeners will hear exactly what you are playing and singing, exactly how you are playing and singing it. A lot of venues are aware of the compressed-and-boosted nature of a radio stream too, so do not be surprised if at the end of your set the venue's host announces "Switching to radio now, watch your volume!" or something similar.

I use a similar setup, with my guitars and mic going into an Allen&Heath ZED10fx. One thing I have noticed in SL is that pretty much ALL live performers have a lower overall level than "radio streams" - DJs are closer but still tend to be overall lower than packaged "radio." This is mostly due to their input having its dynamic range compressed and then its gain boosted, so the whole track ends up with an overall higher level. This is common broadcasting practice but is sadly overused - you've experienced this on your TV when the ads shout at you compared to the level of the show they are interrupting! In part it's a legacy of analog radio where overall higher amplitudes were needed to break the signal out of the interference. "This is how you do it for broadcast" even though the actual need for it has largely gone away. For my part, I do all the usual stuff setting up as I would for a live session IRL. Al the usual stuff you would do for setting up a mixer, levelling each step in the signal path in order. PFL each channel, setting the gain to use as much of the dynamic range of the mixer as possible, according to its built-in meter. Next, monitor the main mix - with and without fx - and balance the mix with the individual channels faders. Check your windows settings on your sound device, make sure it's not peaking in the "meter" displayed in audio settings but is using about 80% of that meters range - since it doesn't have a db level scale. Below that you should turn up the sensitivity of your input in the device settings, but don't set it to above 75%-80% on that slider (higher than that you'll start getting clipping and noise artefacts from windows itself) - if you still need more level to use all the devices dynamic range, you should turn up the main mix on the mixer. If you have to set your windows device lower than 50% to avoid peaking, turn down the main mix on your mixer as you are probably overdriving the input device. You want the meter showing a decent range with input device sensitivity set in in the 50%-80% range. Only now fire up B.U.T.T. - it has meters and a master fader too. At this point that is the only control you should touch. Adjust it so that your performance is using all of it's range without clipping. If you need to do more than a few db cut or boost in B.U.T.T., a previous step is probably a little off. Use your judgement and your audio engineering experience to determine if it's acceptable or if you need to go back and rework a previous step. Make sure your levels are acceptable and you're not clipping by playing a quieter and a louder track through the stream while capturing the stream on another machine and listening back to the capture. Now, if you MUST have a high-level compressed sound going to your stream, you will need your mixer to feed a compressor which then goes to a DAC for input to your computer. With carefully chosen compressor parameters and by adjusting the gain on your DAC you will be able to keep almost your entire performance in the upper half of the meter without losing so much dynamic range that you sound "thin" or "flat" but be warned that it will be easy to detract from the "live feel" of your stream that way - you want it to sound like a live gig rather than a radio stream, because that's what it is!

I took a walk around the sim earlier today - A nice build, with its "spaces" overlapping and giving a kind of "Blade Runner" feel to the place. I briefly met Tinydollz on my arrival and while we only had time for a short chat it was a good one. There are several DJ stations around the place but of course as a live performer I'd be more likely to be leaning on a wall with my guitar around my neck and a cig either dangling outta my muzzle or clipped between the strings on the headstock of the guitar I'm still thinking about whether or not I'd play there, but DJs and performers looking to add a venue to their rotation could certainly do worse. For that reason, although I'm in no way associated with the venue's owners, it seemed only fair to pass on my impressions for the benefit of other performers. The "proof of the pudding" as they say, will be in whether it gets the people in to listen - and, we hope, potentially tip. As it's a new location we have no idea on that aspect yet, of course, but it sure can't hurt to give the place a try if you've got a way your performance might fit in with the ambience of the place