Jump to content

Qie Niangao

  • Content Count

  • Joined

  • Last visited

Community Reputation

2,821 Excellent


About Qie Niangao

  • Rank

Recent Profile Visitors

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

  1. Either way, you'd certainly want to make sure auto-return was disabled (set to 0) before starting any of this. Then you need to switch the group for both the land and the objects (in either order) before turning auto-return back on again.
  2. I don't think Tyche has ever identified them by name. All I know about them is their total holdings and their average parcel size, as Tyche reported in the Mainland Census (back in January), and I graphed above. Somewhere there may be a statement of confidentiality about those identities, I just don't know. Somebody a little more familiar with Mainland rentals could probably make reasonable guesses about those huge, near-full-sim parcel owners.
  3. You have to do it manually but you can do it in batches, not one at a time. Set the Build / Options to "Select By Surrounding" and "Select Only My Objects" then drag your mouse to select everything and set the group for the whole selection at once. Check you got everything in About Land / Objects / Set to group. When you're done remember to toggle "Select Only My Objects" back to disabled to save confusion.
  4. Not much of a surprise: INTJ, scoring about as "I" as possible. I thought most of it was hogwash, but the exec training course where I was first exposed to Myers-Briggs had one exercise that divided the room into the Introverts and Extroverts and gave both groups the task of devising the best way to divide up a birthday cake among eleven people. Those of us in the "I" group spent the whole time working on the geometry, which we presented in detail. The "E" group said they'd ask folks how much cake they wanted. The whole "I" group blushed. Never even crossed our minds, any of us.
  5. I don't know about the "gently moving them" part. To reliably move an avatar outside a parcel, there's nothing better than the llEjectFromLand() function which we've all experienced: it's pretty abrupt, and it tells the target that they've been "ejected" which just doesn't sound very gentle. The thing is, though, it works on seated avatars which you just can't get using physics-based push. If the avatars were not seated, a script can be pretty gentle with physical push, but only if there's a clear path for them to be pushed along, and that's just going to fail way more often than succeed. (It's great for discouraging folks from climbing onto a stage, etc.) It's certainly possible to give visitors lots of warning and make any action contingent on your presence (online, or in the same region, or on the parcel itself, etc), and I guess it could keep track of how long they've been there when you're not around. The 3-4 hour threshold, though, is very long, so... squatters, maybe? I'm wondering if it's really continuous 3-4 hour sessions that are a concern, or if it's spending 3-4 hours over the course of a day, or... just not sure what threat it's supposed to address. (In case it's of interest, for years I've used a little script I wrote that never interacts with the "intruder" itself but does inform me if anybody is present on my parcel whenever I'm in the same region. Then I can greet them, tell them to keep their dirty shoes off the couch, etc., but otherwise they can just wander around anywhere they want, any time I'm not around. Even though there are many passersby on the railroads, they're only very rarely trouble -- but then my threshold of "trouble" is pretty lax. For example, if they're already on my parcel when I arrive in the sim, I usually just go somewhere else for a while.) Anyway, I definitely like having different rules for when I'm online (or immediately present) than when I'm not. Unfortunately not every land property one might want to control can be set by script; notably a script cannot toggle the parcel privacy setting ("Avatars on other parcels can see and chat with avatars on this parcel") which would be really handy for this.
  6. Of course there are reports that simply need more information to be of any value. The release channel nomenclature for versions really doesn't affect those reports anyway, one way or another. The folks most inconvenienced by the change are, I think, those folks most eager to provide all information they can when reporting a problem. Many SL folks really try to help investigate what seems to be happening when things go wrong. It's just not as simple as reporting everything immediately and letting Support filter it out: we all encounter way more WEiRDNeSS in SL than deserves reporting as bugs. Much of it will turn out to be PEBCAK (and we know that going-in) but much is also observing patterns that surpass some subjective threshold for writing up a defect report. It's really not in Support's long-term interest to discourage such user engagement exploring problems in the platform.
  7. Taking this same example, there is zero chance I'll remember the release number that was running on my region a month ago, but if I know it's on the Blue Steel channel at least I can go back and figure it out (as an individual or a Linden), assuming accurate deployment reporting. But now we're not supposed to know a region's channel, so to figure out what release it was running a month ago I first must solve the channel cohort problem and then do all the same work sleuthing through old deployment reports. Or if we're talking about looking at old trouble reports filed a month ago, the full release number was always included in the About Second Life window and was as likely to be included in the report before as it is after the change; the reports that only said "Blue Steel" before will now say nothing at all to identify the release -- and we're back to the same two-stage detective work to ferret out the information. At first I was giving the Lab the benefit of the doubt on this, but after a couple of weeks of this, I don't buy it at all anymore. At best it was stupid; it feels more like an attempt to deter resident discourse about reliability and performance problems. It's like preventing lost keys by turning off streetlights.
  8. Without some legwork I'm not sure exactly how to do it (although those sandboxes give hints), but I'm pretty sure we could post to these threads the magic key to decrypting which release numbers correspond to which RC channel so we'd all know WTF we're trying to talk about. Of course this would utterly defeat the much-lauded goal of obfuscating that information and hence preventing residents from slipping into such slang terms for the releases. Even though Lab folks use only that slang, except when they're en-/decrypting the obfuscated nomenclature for residents. Besides being fantastically aggravating to deal with, this new make-believe release naming convention must rank near the top of the Stupid Linden Tricks list.
  9. It doesn't. Not necessarily. On the other hand, we know SL is just amazingly "sticky" for users after they're hooked, and we also know it's only a tiny percentage of new users who get hooked. With such hard-won users, it's more profitable to catch 'em while they have longer to stick around before they (we) die off. Still, as baby boomers age, the older demo expands. To make that good business, SL must be acquired by each newly old cohort, like AARP cards, not just a feature of one aging cohort, like... I dunno. Fox News?
  10. I need to find time to try replicating something like this in-world. One thing I'll test is whether it matters if the container is stocked while rezzed on the ground as opposed to attached... or have you already tried this?
  11. It's not that there's no minimum bid. Rather, if the seller is confident the land is worth more, they can set a minimum bid and pay the price to list it. If they don't want to pay that price, then they either don't set a minimum and take their chances, or don't use the auction system. To clarify the proposal, it's the same as the seller putting in their own bid as a minimum: if nobody bids over them, they'd get the land back and pay the Lab the commission on the "sale" back to themselves. Indeed, if the system had no provision at all for a minimum bid, the seller could do this manual version of preventing a sale below the amount they want. I'm not sure if that's a subtle problem with the proposal, or a virtue: there's little incentive for the seller to set a minimum bid up front, rather than to swoop in later and "buy" it if the price isn't reaching the desired level. Of course they can do that now, too, but with the current system, setting an up-front minimum doesn't cost the sales commission -- and that's why the resident auction page is so cluttered with hopelessly overpriced garbage that anything of value is buried. Hence the resident-to-resident auctions simply aren't worth viewing except by flippers willing to wade through the dreck for the few genuine offers -- fewer all the time, as the system gets more and more swamped by garbage listings. Another option would be to instead charge all sellers a listing fee corresponding to some share of the sales commission on the minimum bid, discounted from the final sales commission on sale. I'm just not sure there's any real reason to make this share less than 100%.
  12. Well, there's web search that gets part-way there. Can't actually purchase anything except in-world (and I'd hate the job of preventing "simultaneous" web and in-world purchases), but that in-world trip would be part of the process anyway because no sane person would buy SL land sight unseen. Oh I don't think so. Land barons simply provide a liquidity service for SL land, holding inventory for folks who weren't in the market for a parcel when it was priced at whatever the land baron paid for it. So inevitably land barons will bid on auctions and win the ones that they think they can resell for more than they bid -- exactly the same as they operate on directly For Sale parcels in-world. I don't have any expectation of changing the SL land market as a market. I'm just interested in the SL land auctions functioning as normal auctions, where the vast majority of items at auction are sold to the highest bidder, period, independent of any minimum bid. I guess the fixed timeline is kinda related to #1, but even no minimum bid auctions aren't necessarily "fire sales" -- indeed, the fixed bidding deadline of the impending gavel often generates (much) higher prices than could be raised by leaving it up to the buyer to decide when to pull the "buy" trigger. (That's how Sotheby's can afford to buy all that champagne. It's also why Sotheby's buys all that champagne, but that's gonna be hard to emulate on the auction page.) If a seller really doesn't trust the market to bring the price s/he thinks a parcel deserves, they really shouldn't clutter up the auctions page with it but rather put it up for sale the old fashioned way.
  13. Not sure where the Sansar thread is; maybe there's been a sudden turn-around in the past couple months. I suppose I should pop in again although it's difficult to work up much enthusiasm for downloading it. Everybody else always enthuses about how great the graphics are (if only there were any people around) but even the supposedly wondrous graphics don't do anything special for me. I mention "the past couple months" because the statistics I'd been watching are stuck somewhere in August -- evidently the API broke and I guess nobody could be bothered to investigate. It's kinda too bad because those were supposed to have been the all-inclusive numbers, not just the Steam entry statistics (which don't really look any better than before). That cross-subsidy was to be expected at first but there needs to be an actual customer base by now or it's high time to pull the plug. I get the feeling that the whole VR industry is based on the sunk cost fallacy leavened by an eternal spring of hope for consumer adoption of the next big hardware announcement, always just around the corner.
  14. Seems unlikely. The region you mention is currently pretty heavily script-loaded (6700 scripts with nearly 800 events per second) so of course there's no Spare Time at all and only about 2/3 of scripts run each frame -- and that's with only a few avatars in the sim. It's not the worst ever, but finding ways to shed some of those scripts would probably help. (In recent months we've seen some general flakiness about how efficiently sims run scripts from one restart to another, seemingly at random, but this one seems to be dealing about as well as can be expected with this volume of scripts, and there's not much except scripts competing for frame time.) Still, it doesn't seem bad enough to cause scripts to be dropping queued events. The update was supposed to include some efficiency improvements in listen (as well and sensor) events so it's possible some timings have changed. (I notice this specific problem is reported in a jira in case anybody wants to watch that.) I haven't seen any other recent reports of listen nor link_message bugs, but anything is possible. There is this recent jira related to RLV, but it may have been the same race condition, arising in communications with script-rezzed attachments. That also seems to be the case with this jira. And then there is this recent report of script failures in a particular product (not RLV related and apparently not the rezzed listen race condition but seemingly fixed by the same cure).
  15. The SL Death Watch is a game longer than I have patience for, but the Sansar Death Watch -- I'm still playing that one. Sansar from birth suffered from "failure to thrive," has been comatose for a long time now, and... well, let's not get too graphic with that analogy. Somebody will pull that plug eventually, if not this CEO then the next one. I do worry about the steady aging of the SL population, both in terms of account age (there sure are a lot of us old timey two-namers still haunting the grid) and RL maturity. SL needs more new blood. When it finally dies it won't be slaughtered by obsolescence so much as starved by the software's n00b-hostility.
  • Create New...