Jump to content

Qie Niangao

Advisor
  • Posts

    13,523
  • Joined

  • Last visited

Posts posted by Qie Niangao

  1.  


    Phil Deakins wrote:

    Did you ask for your abandoned land back? [...]

     

    Nah.  I found other things to do with the tier.  I was very glad to see the adfarm extortionist gone from the sim, even though I didn't own the immediately adjacent land anymore.  But I was pretty mystified that she gave up literally overnight, once I abandoned the surrounding land.  I mean, it had stayed as a standoff for well over a year; I'd never contacted her to try to get the land (it only encourages them), and before had only absorbed parcels as the adfarmers had been driven out by LL.  So it's not as if she could have had any reasonable expectation that I'd pay her ransom if she held out long enough.  I have to suspect that she had reason to think that LL would be less tolerant of her crap when the surrounding land was owned by the Governor than a private resident.

    Hugsy, that is an interesting case, and yeah: the timing makes it difficult to see as coincidental.

    About pricing: I really don't think this policy is going to increase the rate of abandonment.  Rather the opposite, in fact;  I'd certainly never have abandoned any of my land if I knew it would go on the market immediately.  Indeed, I kind of rushed to do the abandoning before the policy took hold, knowing it would sit "fallow" for a while that way.

    As always, it's the bottom of the market that will suffer, if this process succeeds in pushing abandoned parcels to sale faster than the auction system did.   Honestly, there is some Mainland that should have no value whatsoever.  In fact, even if tier were free, too, some of it is too awful to own.  But what I mean is that this really isn't going to have any effect on Nautilus City, Bay City, nor most of Zindra... nor Blake Sea coastline, etc.  But yeah, for landlocked, run-of-the-mill Mainland, I can see it raising the "no value whatsoever" threshold.

  2. I kinda doubt that the unusual events around that abandoned 16m² was really a function of this policy.  Very rarely, I see some unexplained transfer of abandoned microparcels to somebody not otherwise present in the sim.  It's very rare, and I've consciously decided not to probe into it too deeply, partially because of something stupid I did to myself in my "main" region:

    A while back, I'd gotten very tired of looking at the sole remaining 16 in a burnt-out adfarm that I surrounded and managed to consume, bit by bit, over years.  This 16 was set for sale at some absurd thousands-of-L$ price, but belonged to a group that had no tier contributed to it.  I submitted a ticket, hoping it would get force-abandoned and I could finish off that adfarm for once and for all.

    That isn't quite what happened.  Harry moved that parcel to a piece of Linden property that he carved out of the SLRR right-of-way, interposed between my property and the SLRR, deeded to one of the owners of the defunct group.  I was disappointed (to say the least), but thanked Harry for the assistance.  I realized that I'd brought it on myself.  Then, that freshly-minted microparcel actually sold, and now has an ad on it.  In fact, the ad is technically in violation of the adfarm policy because it includes a rotating texture.  I've decided not to press my luck by ARing it.  I figure another "improvement" like that and I'll be abandoning the whole d*mned sim.

    Speaking of abandonment:  There was another 16 that I surrounded on 3 sides, again for years, for sale for multiple-thousands-of-L$s (of course) by one of the last adfarmer hold-outs.  (Yes, they still exist.  You may recognize this one by her faux French name, which I can't say here.)  About six months ago, discouraged by the above incident, I finally gave up on that one and abandoned a couple thousand sq.m. around it.  Overnight, that 16 had been abandoned, too.

    Elsewhere on the sim I've still got another 16 surrounded, for sale for L$4000 by yet another sleazeball.  If I could be sure it would kill-off that S.O.B., I'd abandon however much land it took.

  3. I suspect the confusion here is between Landing Points, which are set on a per parcel basis on Mainland, and Telehub routing, which is used only on private Estate sims.

    A private estate manager can actually prevent direct teleporting into any individual parcel in the sim, forcing all TPs to a single hub location.  That's not the situation in Bay City (nor, as far as I know, anywhere else on the mainland).  In contrast, we can TP directly to individual parcels in Bay City today -- our own, other residents', and Governor Linden's.

    As Marie correctly notes, my concern is with the per-parcel landing points set up for Governor Linden parcels that make up infrastructure such as roads and canals.  These wind around and through each Bay City sim; everyone's individual parcel borders them. 

    The problem is that the entire road and canal network and any parks or other infrastructure in the sim share a single landing point.  If one wants to TP to the sidewalk in front of a business, for example, it's impossible.  One is very likely to instead end up at the opposite corner of the sim and have to navigate through the sim, following the red beacon, to the intended destination.  (Try it yourself: open the map, zoom in, and try to TP to the sidewalk next to your parcel.  See where you end up.)

    Ironically, I'm forming the habit of avoiding map teleports to obvious Linden infrastructure, and instead targetting private parcels near my destination, to avoid being trapped by the Governor's wacky landing points.  So, if anything, the landing points are causing more such intrusions, at least by me.

     

  4. Not just to be contrarian:  I'd rather move animations into the agent and out of the viewer almost entirely, except for playback.  The current round-about mechanism for informing other viewers about an avatar's changed animation makes synchronization a remote ideal, and poses hurdles for extending to a more "physical" avatar. 

    (This is actually orthogonal to where the UI of an AO operates.  It's not as if moving the AO to the viewer takes the sim out of the picture; it just pushes the simple AO processing out of the script VM, and saves a network traversal only for the current convoluted data path for animations and animation-states.)

    I guess I'm suggesting that in addition to making the viewer more extensible, the server-side agent representation could stand some beefing-up, too.

  5. I mentioned it at the Bay City Alliance meeting yesterday, and will send out a notice to that group shortly, so I'll ask here, too:

    Does anyone object to having those landing points removed from unparcelled Linden land in Bay City, on non-InfoHub sims?

    I'm increasingly convinced that those landing points seriously interfere with navigating and exploring the affected sims, because they render Landmarks nearly useless and turn teleporting by Map or SLURL into a maze of twisty little passages.

    One hypothetical objection that was mentioned at the meeting was the possibility that some folks bought land near one of the landing points* in hopes of catching traffic from frustrated travelers.   That seems a pretty dicey proposition in the first place (no reason to expect those landing points to remain fixed for long), and I can't imagine it really helps traffic anyway:  One very quickly learns never to TP to a Linden-owned destination in Bay City -- the penalty is far too high -- so, if anything, I'd guess that those landing points are places that (experienced) traffic avoids.

    Note that I don't propose to remove landing points from specific parcels when they've been set up for individual destinations.  And I also don't propose to change anything about TP routing at InfoHubs, which (one hopes) is specifically designed for handling the arrivals traffic on those regions.  The Landing Points I want to go away are the ones shared by all the road and canal and everything else Linden-owned in the region, especially for regions that are not 100% Linden-owned.

    _________

    *I guess that would be a bit analogous to an old idea of setting up shop near the (128, 128) sim center, to catch those who TP into a sim without specified coordinates, although I'm not sure that ever happens anymore.

  6.  


    Darrius Gothly wrote:

    [...]Wouldn't it make more sense to move script execution to servers that do only scripts .. and maintain a partition or task for each Avatar? As I understand it right now, when you teleport or move across Sim boundaries, your entire script collection gets copied and run on the new Sim's server.

    But if script execution was separated onto its own server farm, and you got a partition on the script servers when you logged in, no matter where you roamed in Second Life, your script burder would never need to be moved or copied from server to server.[...]

    I've seen that proposed before, and it would be interesting to see how it would turn out, but I don't think it's a panacea.  It seems it would get some savings at TP time (not having to actually copy scripts and state into the TP'd-to sim) at the expense of a very large amount of communications after TP is complete.  A tremendous amount of information flows "through the membrane" between the shared state of the region simulation and the script VM; all that would have to become network messaging, with implications for perceived lag. 

    My hunch is that it would replace one big fat rubber band with a whole bunch of little ones, from which there could be no escape.

  7. Pretty much everything has been said.  I'd just add one thing that's not about lag, per se.

    It would be a win if Teleports were blocked with a message, something like "You need to remove some scripted attachments before teleporting."

    There's a pretty steady stream of complaints about how much teleports fail, making the residents' experiences quite miserable.  It's one of the top things people want LL to "fix."  In maybe one percent of the cases, there's something actually wrong with the account that prevents teleports, and maybe five percent more have a problem with their network connection, but in the vast, vast majority of cases, it's because they're simply wearing too many scripts.  And no amount of technical "fixing" can make it possible to move between sims with an infinite number of scripts attached.

    If script memory limits were in force, that would probably prevent people from attaching enough scripts to cause teleport problems, but without those limits, it's a very common complaint.  If people were informed that they had to remove stuff in order to make teleports work, they'd have a lot less frustration than suffering through failed teleport attempts, over and over.

  8. I probably won't be able to make the anniversary events due to RL stuff, but it shows every sign of being a great success.  Superb planning and organization. :smileyhappy:

    On an unrelated topic: I've been wondering why so many of the Bay City sims have landing points set for the common municipal land in the sim.  Landing points work fine for specific parcels, but I'm forever landing a half-sim or more from where I'm trying to go, in regions where the Linden land is unparcelled but nonetheless has a landing point set somewhere.

    I'd especially like to arrange for the LDPW builds listed on the wiki to be accessible directly, without having to navigate from a distant landing point to the landmark or SLURL of the build location.  Just having the landing points removed altogether would be fine, at least for my purposes, and should be easier than setting up separate parcels with landing points for those attractions.  Is there anything I could do to help with this?  (Or does the current arrangement have some advantage I'm overlooking?)

  9. Oh, sorry, missed this follow-up.  No, it returns a list of results in side-number order, so you have to parse through them incrementing the side yourself.  Prim sides are always numbered from 0 to llGetNumberOfSides() - 1.  If prim type or geometry changes, the side number for any particular bit of prim (such as, say, the inside of a hollow) may change, too, in the way described on the wiki.

  10. It was the fact that only the first got mangled that made me suspect that dataserver events were getting swapped between competing handlers in a kind of race condition that only arose at the start of everything.  But if there are no other scripts or they all check that the query IDs match, then that's not what's going on anyway.  (For that to be the case here, there'd need to be some other complication that "ate" the dataserver event from that first line, too, so it's not a very parsimonious explanation; just something I've been bitten by in the past.)

    To the other question, if it's any help, in llGet*PrimitiveParams() functions it's possible to specify ALL_SIDES as value for PRIM_COLOR and PRIM_TEXTURE, which returns a list with each side's values.

    ETA: You know, I'd still suggest printing out everything the dataserver event is getting.  Could it be failing to ignore that first "delete this line" line?  That doesn't quite make sense either, but I'm still suspicious that something funky is happening in that handler, wrapped around the code that's posted.

  11. Right, but if the parcel allows Everybody to run scripts (as I understand to be the case), then it shouldn't  be checking if the owner can.  Hence my theory that it must be some specific function inside the script that's not behaving the same when the owner's not around, because of those parcel perms.  And that only leads to a solution if those specific functions can be removed.

    My concern is that the object may be no-transfer to the current owner, in which case it couldn't be deeded to group.  (But because there are two groups owning different parts of the path, that may not be workable anyway.)

  12. I must be missing it, but I'm not seeing where rezzing is the part that's failing here.  Rather, it seems the cart freezes (a physical vehicle, I assume, or anyway some scripted thing that is sat upon).  This really sounds as if the parcel is denying script execution to anybody outside the group.  When you're present in the sim, it can tell that you, as owner of the cart, have permission to run scripts on the parcel; once you leave, it can't determine that anymore.  The flaw in that is, of course, that the parcels have scripts (and object entry) enabled for Everyone.

    Assuming the parcels really do have those settings, the only thing I can think of is that a script is calling a function that requires parcel permissions, which it can't get when you aren't around (and because you own the cart, it's essentially acting as your proxy).  So, in addition to rezzing, there are some other functions that won't work the same in such cases... llGetParcelPrimOwners() is one, although I'm stumped for an excuse why a vehicle would call that function.  Oh, hmmm... maybe llOverMyLand(), but I can't come up with a story for that one either.

  13. You can check for packet loss in Help / About Second Life.  In Viewer 2, it will be the last line in the "Info" tab.  Within a few minutes of login, packets lost should be well below 1%.

    Actually, it may be useful to just copy all the text from that tab and paste it here, in case anybody spots anything unusual about the machine configuration.  (You can leave out the part with the sim name and location if that's not comfortable.)

    You can also see packet loss, bandwidth, ping latency, and other fun stuff from the Statistics Bar (Control+Shift+1).

  14. Hmm.  So there's a debug setting, TextureDiscardLevel, that wants to be 0.  If it's anything higher than that, textures will look blurry.  But I think they'll always look blurry, and it appears from those snapshots that eventually you can get them to load.  So that's probably not it, but if it is, then you may have other contaminated settings, and you'd want to manually clear those out and start from scratch.

    You might also try toggling HTTP Textures (from the Develop menu) to see if it helps.

    Also from the Develop menu, watching the Texture Console (Control-Shift-3) might give some clues about where things are getting stuck.  The wiki has an article that's helpful in interpreting that stuff.

    Frankly, though, it does point to a network problem.  Are you getting a lot of lost packets, by any chance?

  15. As a service provider, LL is somewhere between AT&T and the guy who cleans your pool.

    It's a business, that's certainly true, and like AT&T, they have to keep their channel partners happy -- hence the Atlas program meetings.  Ultimately, however, it's the end-user landowners and tenants who pay LL's bills; those are their actual customers.  The job, then, is to retain those customers and somehow acquire more of them.  That's the main purpose of having forums, user groups, blog posts, etc.  (Those aren't the only things they do to get and keep customers, of course.)

    And it's not just to placate us.  For one thing, it's very inexpensive market research (if a bit noisy). 

    They're also in the enviable position of having some very sophisticated customers who are even willing to both share expertise and do real grunt work for them, unpaid. Forums and user groups are useful for recruiting and coordinating such efforts.

    Historically, as soon as front-line Lindens set up structures to harness that crowdsourcing, a change in policy or staffing tears it all down again.  It's very odd.

  16. Ah, yeah, thanks.  Now that you mention the stack, that actually makes sense for the first time, so maybe I can remember it from now on.  (I suppose I should feel bad about all the post-inc/decrementing I've gone out of my way to do, mistakenly thinking I was optimizing, but it pales in comparison to the amount of code I really should re-write once we get llRegionSayTo().)

  17.  


    Innula Zenovka wrote:

    Are you sure it should be i = max -1 ?  The only way I can get it to work decrementing it is if I set i=max:

    Oh jeez!  You're right of course.  (Dueling fenceposts!) 

    Sorry for the confusion.

     

  18. I think there's a fencepost error in that sample code: it should try to execute the do loop one too many times because it's using postfix++, so it will increment after the comparison.

    Postfix increment/decrement is much more efficient than prefix in LSL -- I have no idea why.  Anyway, i'd try replacing that loop with something like:

     

    i = max - 1;while (i--){    // do stuff}

     

    It will run through the prims in the opposite order, but that shouldn't matter.  Of course, for a very simple application where you already know which prim you're changing and even what color it's supposed to be, you wouldn't need a loop at all and you can get by with a single call to llSetLinkPrimitiveParamsFast() specifying both PRIM_GLOW and, for the alpha, PRIM_COLOR.

  19.  


    Rolig Loon wrote:

    Thank you, Jenni, for putting some detail on what I referred to as nonsense before I quit for the night yesterday. As you say, a LSL script is never transmitted to the client in any form, so there's nothing to capture.  The only hole in LL's armor was plugged a long time ago, and I doubt that there's another. This feels like another Chicken Little worry, propogated by someone with a magic cure-all for sale.  I'm not buying it.

    I'm not quite so confident.  Although I suspect this particular case is bogus, there is still the possibility of permissions being compromised server-side, enabling mod on a script, and then all bets are off.  This voodoo magic "hexing" sounds pretty improbable at this late date, but I wouldn't completely rule out the existence of some unauthenticated sneak path through the spaghetti of the permissions system.

     

    One would hope, however, that the Lab would take such things seriously enough that anybody caught messing with script permissions (which should be trivial to trace, once discovered) would have much worse problems than a mere permaban to worry about.

    I don't care so much about full-perm scripts in sexbeds and the ever-popular "I'm a loser" HUDs that have been the perennial targets.  It would seriously suck, however, if some cryptographically secure communications were compromised.  Just the prospect of denial-of-service attacks is bad enough, not to mention possible RL identity theft.

     

  20. Well, there's one for advertising, but I suspect you mean advertising SL itself, not advertising to the SL market.

    As I mentioned above, there seems now to be no plans at all to introduce a "land" user group for regular estate or mainland owners.  Just the closed Atlas program meetings, and various Mainland community groups (Bay City and Zindra; desperately lacking: LDPW).

    Not sure what to say about "technological infrastructure and innovation"; there's the Viewer Evolution group (which is mostly just another Snowstorm meeting with a slightly broader scope than "how do I get this sucker to build?").  Good luck, however, trying to get any hint of what's actually planned: things like avatar physics, Project Skylight, etc. just drop from the sky fully formed.  There's Andrew and Simon's simulator/server group, which is sometimes relevant to changes in the underlying technology.

    AFAIK, the Lab has never taken input on policy, planning, nor organization.  At least not voluntarily.  And rarely given even a glimpse inside the kimono of what directions they might be contemplating.

    To be honest, that's exactly why I'm so concerned about the lack of a Land user group.  I can't help but suspect that they're giving serious consideration to something that will destroy all remaining value in Linden Research Inc.  They're only one charlie foxtrot from lights-out, and they have a board of directors stacked with idiots.  What, me worry?

  21.  


    Venus Petrov wrote in part:

    The other Adult subforum is private by request to Blondin Linden but meant for adult land owners and content creators.  I believe it sits over in the Commerce area.

     

    I wish I knew a little more about this special sub-forum. Ciaran described it a bit during the meeting, but without knowing what gets discussed it's difficult to know whether it's really of interest to me or not.  (If it's under Commerce, probably not.)  For that matter, I may not even qualify, now that I've traded half my Zindra land for G-rated Bay City and removed from sale (for now) all Adult content.

    It's a bit unsettling how these things sprout up without anybody on the outside knowing that they even exist.  I feel that especially about the Atlas meetings.  Obviously, being a Mainland creature myself, no amount of expansion would qualify me for the Atlas program, but there is no comparable group for mere landowners, not even at Concierge level.  From Amanda's comments at the meeting, it's evident we shouldn't expect that to change, either.

    This is disturbing.  Looking at all sources, Land must still contribute about 85% of Linden revenues, and probably nearly 100% of net profit.  (I'd guess that Marketplace would be lucky to break even; one would need commission on a heck of a lot of slutwear to cover the fully loaded labor rate of just one Linden FTE.)  My wild guess would be that maybe 25% of revenue comes from Atlas participants: they're big, but they get discounts... so maybe 20% of profit, if that.  This leaves a tremendous patch of Linden balance sheet without user group representation.  That's extraordinarily strange.


  22. I forget the URL to the part of the ToS with this, its on a notecard I've got somewhere...

    I think you mean this which is included by reference in the Mainland Policies which is in turn referenced in the TOS .

    I had actually forgotten that animation was forbidden, but: "They must contain no rotating or flashing content and no particles" -- where "rotating" may not be limited to llTargetOmega() but should reasonably apply to smooth texture animations, and "flashing" to cel animated textures.

    The FAQ also includes:


    Does this policy include signs advertising parcels for sale?

    Yes it does.


    So... somebody has some tidying up to do.

    On the other hand, the FAQ explicitly excludes from the policy signs above stores, so that may not be good news for Dillon's case, unfortunately.

×
×
  • Create New...