Jump to content

Da5id Weatherwax

Resident
  • Content Count

    256
  • Joined

  • Last visited

Community Reputation

225 Excellent

About Da5id Weatherwax

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is going off-topic for the original discussion, so we should probably not go on, but it doesnt matter whether you rotate by 90 degrees or 450, you end up with the same quaternion - rotations are not "general" quaternions, they are unit quaternions. Every element of them is the product of a trigonometric function (or the "product" of several ) which can only produce values in the range -1 <= n <= 1, inherently normalized. I'd love to carry on talking math with you and would love to learn from the insights you gained dissecting the import code smd writing your own implementation, but I guess this isn't the place for it
  2. oh I didn't mean to imply that kind of "limit point" - but more the mathematical one that results from the self-normalizing nature of calculating a rotational position. There are only 360 degrees or 2Pi radians of valid normalized range in a rotation about an axis and the math in handling them usually results in a value from -180 to +180, or -Pi to +Pi. Certainly the trig functions in calculating a quaternion are inherently self-normalizing in this way. The issue comes when the animation software has to handle tweening along a path that crosses from, say, -170 to +30. As you correctly point out they all handle this slightly differently and so it does depend on the software used to generate the animation but it also depends on the viewers handling of the anim format in these situations too. It was a lot worse when all we had was bvh import because that introduced a third black box, the uploader converting the bvh to anim, but even now it's possible to come up with a set of keyframes that look like they work correctly in your animation software but when the result is uploaded the direction of the avatars rotation abruptly reverses between two keyframes. And it's inevitable that generating animations of the kind being discussed here are more likely to tickle that edge case.
  3. 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.
  4. 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
  5. 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"
  6. 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.
  7. The perennial "Scunthorpe problem" - residents of that city and people talking about events there are continually being edited by poorly configured "profanity filters"
  8. 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.
  9. "... 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)
  10. 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.
  11. 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.
  12. 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".
  13. Because there are people here who like my music and show up to hear me play it
  14. 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.
  15. @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.
×
×
  • Create New...