Jump to content

Qie Niangao

Advisor
  • Content Count

    9,450
  • Joined

  • Last visited

Community Reputation

3,626 Excellent

7 Followers

About Qie Niangao

  • Rank
    Coin-operated

Recent Profile Visitors

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

  1. If we're really only talking about rotation, then llTargetOmega isn't a bad approach to smooth the transition between updating the actual rotation every few seconds (with llSetLinkPrimitiveParamsFast() or the like). I've made a clock's sweep second hand that way that moves very nicely after the first viewer update (so if you look away, it can take those few seconds before the hand jumps to the time and starts moving smoothly... where "few" can be a tradeoff between the size of that first jump and the cost of timer()-driven updates). I was reminded of that clock because the desired 30 degrees every 5.0 seconds is much like 360 degrees every minute.
  2. Yes, please send me the name of that product in PM. I thought I knew the market leader in this space, but in their Marketplace (or in-world store) license agreement I'm not seeing any restrictions at all on end product permissions; as far as I can tell from this, as long as I followed the constraints on the scripts themselves I should be able to use them to distribute full-perm creations if I wanted. If such restrictions were imposed (mechanically or in a separate license) after purchase that would violate Marketplace terms, so I'm guessing this must refer to some other "standard" script set. The real concern here, though, would be if they're trying to use object perms to protect the IP of creator textures, normalmaps, etc -- and that's really not effective, so hopefully that's not what they're doing. Right. Of course they can still modify the originals -- even if they're set no-mod for next owner, because they're editing your object, not a copy that has transferred to them which will, then, be no-mod. I think that's all as you intend -- you're okay with those special folks with edit permission editing the originals you created, just not taking copies they can edit. But while you're being cautious about giving edit permission, also be cautious about Sharing with Group: it has somewhat similar effect. If I understand what you're suggesting, I don't think so, because checking that box only affects what the NEXT owner can do. So a person with edit perms could still take copies of objects set no-transfer for next owner, but wouldn't be able to transfer those copies because they'd be that next owner.
  3. New user sees a product photo; wants their avatar to look like the photo. What are their chances of success? How many layers of hurdles have we erected between that desire and its fulfillment?
  4. Not sure it's much consolation, but there's a jira from 2011, "rotation of llSetKeyframedMotion particulary wrong when the frames are long time". Unexplained minimum rate of rotation, apparently. Makes me wonder how this function works.
  5. I'll butt in here a bit. If you're familiar with making Omega appliers (I wasn't, but turns out it's really easy) you can convert any Omega-capable Mesh body to BOM just by painting it with the system BOM textures. After my Slink body upgraded to BOM (ages ago) I got so impatient with the mesh bodies my alts were using that I did this myself. None of this is as slick or render-efficient as the Slink body (recently updated again to make BOM even easier and nicer) but it's a way of getting some BOM experience without having to trash a mesh body that still hasn't updated. At this point, though, most bodies at least have such a BOM texture-painting solution already pre-packaged, if they don't offer it as a direct upgrade. (A big downside of merely painting the BOM textures is that the mesh still carries all the many "onion skin" model layers, so it misses out on much of the rendering efficiency of BOM.) For the problem with fingernails and toenails, visit Izzie's shop. I'm sure there are others (and, again, a certain mesh body creator supplies these with their BOM body model), but it's a pretty convenient fix. That said, though, many older skins (and clothes, and tattoos, and etc) were textured using the then-maximum baking resolution (512x512 if I recall correctly) so those look pretty rough compared to textures baked to the full 1024x1024 that's supported with BOM. (In case it's a concern, these higher resolution textures do not accumulate to some bloated rendering nightmare: all the layers get baked together server-side so there's just one big texture per major avatar region, combining all the details from the layered components.)
  6. Ah I knew it would surface: "Super premium plus rollout postponed"... I gather the meeting where it was announced was a month ago now, on May 5th.
  7. You really cannot begin to imagine how little I care about that.
  8. Somewhere I read that just as technical support was almost complete, the feature offering itself was semi-officially delayed because the timing was perceived as inappropriate in light of COVID-19 economic distress. On the other hand, I guess more might be known by third-party viewer developers (or I guess anybody who wants to read the Lab's own source changeset for the feature). I mean, there must be a finite set of attributes that could possibly level-up for double-plus Premium. So somebody knows something -- more than I do, anyway.
  9. Okay, I've read several times what you've posted to this thread and it's like a Necker cube for me, the sense shifting back and forth every time I look at it, so... I mean, I give up trying to understand. I will add this: Numerous times I've offered to purchase a "fat pack" at a substantial premium, if the creator will supply it with Modify permission. It's worth it to me to be able to remove or add my own scripts, fix clumsy Materials settings (way too common, even from popular creators), and use the actual build tool instead of some scripted kludge to tint or resize. Sometimes the creators take me up on the offer, but when they refuse, the reasons are a mixture of superstition and customer contempt. I guess it's their one opportunity to exercise control in their lives, so maybe I shouldn't judge them so harshly, akin to diners who abuse their servers.
  10. I would never knowingly buy anything from a creator with such an abusive opinion of their customers. You get the customers you deserve.
  11. Just for completeness, the example I was muttering about earlier boils down to this: default { state_entry() { // set up by rotating the prim to 90 degrees in Z vector fwd = <1,0,0>*llGetRot(); if (fwd.x == 0.0) llOwnerSay((string)fwd.x+" == 0.0"); else llOwnerSay((string)fwd.x+" != 0.0"); } } It's not surprising at all, unless one forgets how floating point works.
  12. Huh? No, Syo Emerald led us in the direction of an answer. (Granted, I don't know who's alt of whom, so I guess anything's possible.) Anyway, I'm drifting back to the same old place I was all along: Old time Mainland won't get a covenant, but it would be better if it had some of the constraints that apply on Belli: No hair-trigger orbs, no banlines, sky builds only at some plausible altitude. That's about it. The main reason for restricting Mainland parcel-owners' ability to screw with passersby is that Mainland, specifically, is uniquely suited to exploring, just by virtue of its geographic extent. So that's a market need that simply cannot be satisfied on Estates, even the ones with clusters of a few dozen contiguous regions. After understanding the economic forces, I get it that the more restrictive "gated community" "gentrification" (which I never wanted for myself anyway) only makes financial sense in an Estate business model, with dirt cheap labor and high end-user prices. Yeah, there are a few experiments on Mainland (Brown, Boardman, maybe some others), but they never had a chance of scaling. Belli is completely different, of course, with only fairly minimal covenant restrictions but constrained by a choice of pre-built housing, as well as the old "Linden Homes" region settings: no terraforming, no resale, no parcel joining/splitting, etc. Those particular constraints would be weird on Mainland* and I don't think anybody is arguing for them. But in reality we're not going to get anything, so exploring the market economics is the most interest I can squeeze from the topic. _______________ *I've owned some no-terraform Mainland, and of course most of Mainland is limited to that +/-4m range, restrictive compared to most Estates. And some no split/join Bay City, etc. It's not such a burden, really. Nor would be so horrid if sky builds were kept above common draw distance, just so shadows can be sensible.
  13. Again, the question was WHY Mainland as opposed to Estates? Which question, incidentally, you completely ignored by simply assuming the answer was "BECAUSE MAINLAND IS MAINLAND and must ALWAYS AND FOREVER HAVE BEEN DESTINED TO BE MAINLAND." That's just a ducky way of answering by simply assuming-away the question, but not a contribution towards understanding the economics. On the other hand, I think we later got the answer: It's simply cheaper to have fewer rules to enforce, and cheapest of all to have no rules at all; when you have the most expensive workforce, you're the one with no rules. The costs will determine that only Estates, with cheap labor, low margins, and higher end-user prices -- only Estates can provide the "gated community" "Nazi Home Owner's Association" experience you don't want (and, if you read a little further, you'll find I, too, don't want it for myself).
  14. Coincidentally, I faced this question recently. I'd have to go back and look at the code for details, but I was doing something involving finding the point(s, if any) where a line intersects a circle, and I was trying to test for a special case to avoid division by zero. When I created that special case, though, the denominator that "should" be zero was off by a minuscule floating point error. I remember being kind of amazed that this doesn't come up more often.
  15. I doubt they'll do anything either, but I think that comment was in the context of (not) freeing-up servers by re-hosting some mostly-abandoned Mainland (and Ye Olde Linden Homes) sims to homesteads... which would take some investment of time and effort. Having had some responsibility for platform migrations myself, and guessing what technical challenges ☁️Project☁️Uplift☁️ might entail, I wouldn't be surprised if the Lab eventually needs to reconsider that position (rather than trying to make Mainland more popular by introducing selective restrictions; compared to an Estate region, a full-up Mainland sim can generate substantially more revenue for the Lab -- but only very rarely does, so they'd be better off freeing up some mostly idle Mainland-hosting hardware to use them on shiny new Estates).
×
×
  • Create New...