Qie Niangao

Advisor
  • Content count

    7,107
  • Joined

  • Last visited

Community Reputation

620 Excellent

5 Followers

About Qie Niangao

  • Rank
    Coin-operated
  1. Prokofy got that from me, I cited it earlier. I particularly picked-up on that post because I've had intermittent problems rezzing on most any mesh surface at one particular site where I have lots of mesh decor, old and new. I'm sure some item(s) don't use the workaround, but the misbehavior is wildly unpredictable. (E.g., at the moment, mesh seems to be rezzing easily on a mesh floor that's often been a problem, but it's now impossible to create a fresh box on that surface. There's always a problem in this area, but where and how it manifests itself is maddeningly random.) But if Prok is having the problem on all these different sims all the time, then that's a different experience than what Chic described, and the one that's been trying my patience these past few years -- which themselves may be different. I'm just not confident that we know as much about this bug as we think we do. It particularly bothers me that the location mentioned in the error message is (usually?) not off in space somewhere far from where one is trying to rez at a position where the avatar truly doesn't have rez permission, but rather seemingly right there where you were trying to rez in the first place. It all reminds me of two very old bugs. Early on it was practically impossible to rez on the inside of a hollowed box, and then briefly later, rezzing on an old-school megaprim would always position the rezzed object at the origin of that megaprim.
  2. Apropos "the last 100 items in inventory" thing, I found this post from Chic in a thread from last summer that seems to suggest that the rezzing issue can be caused by something completely other than the surface on which you're trying to rez. That is, some (analyzed physics, or perhaps not?) item somewhere in the general vicinity can contaminate the local geometry and confuse the sim about where a rezzable surface is to be found. If that's right, then any item from inventory, placed in that environment, may not be able to support rezzing, even if it correctly worked around the bug, because some other nearby item was made without the workaround.
  3. pay box amount

    I don't think you can change the amounts for paying an avatar, but it's easy to use llSetPayPrice() to specify default payment amounts for objects scripted to handle the money() event, such as vendors, tip jars, etc.
  4. Is the modelling workaround documented somewhere? I've never been able to sustain even "basic weekend-hobbyist level" of interest in modeling mesh for SL, so I didn't see what's wrong with Mesh Quad.dae, or even what's all that unusual about it (other than maybe that its sole surface is offset from the model origin, and that bit should only be a problem because the Mesh uploader contrives the geometric origin on its own).
  5. I know this bug has been discussed many times but I never paid much attention to it, idly accepting a general explanation that it's because the mesh maker didn't know what they were doing. Now that I've looked at the underlying jira and its attached mesh models, I'm puzzled why this wasn't fixed four years ago. I'm looking in Blender at the problem case, Mesh Quad.dae and I'm not understanding what about it should cause such horrible misbehavior when raycasting for the surface on which to rez. Moreover, as Maestro commented, the error message refers to a perfectly good rezzable location, which doesn't seem to be the location where the failed rezzing is being attempted. If it knows the rezzable location to generate the error message, why can't it use that location to rez the object in the first place? It would take some heavy explaining to convince me that this shouldn't simply be fixed so we never have to see this or any other error message.
  6. Inter-region script communication

    Now I'm not sure why it's necessary to communicate at all. The HUD itself can keep track of where it's been lately, detect when it has CHANGED_REGION, check if the avatar is still seated (if llGetObjectDetails(llGetOwner(),[OBJECT_ROOT]) is a vehicle or the avatar), and TP if necessary. Probably there's some part I'm missing.
  7. I've been assuming we're talking about the roadside land here, not the sky island. But I could be wrong.
  8. Inter-region script communication

    Hmm. I wonder what you're describing here because I don't know of any "SLRR" communications. Just based on the green color, maybe SLGI? I don't know anything about how those work, but I can tell you how VRC does communications for the rail traffic maps (for SLRR, Bay City transit, ONSR, etc.). Before Experiences, those used a hybrid of email and http; now it's http and Experience key-value store (programmed a bit like POSIX shm). The one-time-use traffic probes (which do traverse the track route at high altitude in order to do llCastRay in each region) use http with the servers that rez them, getting passed the stationary server's ephemeral URL when rezzed. Then the servers store the debounced traffic telemetry in the Experience key-value pairs for use by maps. Because you won't have an Experience enabled for everywhere vehicles may wander, that's not going to be relevant to your case. There will be some attrition of vehicles due to straying into no-script land; attachments may continue running scripts on no-script land, but not vehicles... but those vehicles are dead anyway, so nothing lost by not being able to find them for re-seating. What you might do is more like what that system used before Experiences: When an attachment needs to communicate with a vehicle, it could send an llEmail to a fixed (preferably redundant) in-world registry of ephemeral vehicle URLs, identifying its own ephemeral URL on which to receive the response. The vehicles would update their URLs to that registry with every region crossing -- a lot of volume, so probably those updates would be llHTTPRequest()s to the registry's URL, learned by a preliminary llEmail. The trick is to keep it scalable, which means never sending llEmail from a central node (20-second delay per message per script), and also directing HTTP so that requests come from distributed nodes (because llHTTPRequest is throttled per object, and per owner per sim). Also, once in a blue moon, a sim will simply stop delivering emails to an address, which means the server at that address must be worn, carried to another sim and back, and dropped (not detached) back where it was to get the sim to resume delivering the backlog of email messages. After that has happened a few times, an external server may seem cost effective.
  9. I think it depends what the item is. If solid walls of the building encroach on Linden land, that's likely to get returned as a result of abuse reports from inconvenienced vehicle drivers. A driveway or some parts of phantom foliage, on the other hand, won't interfere with anybody's travel, so may survive quite a while before being returned. Also it's a pain to have any of a house's interior extend outside one's own parcel; then you have to keep track of where things can be rezzed... and which bits must be linked to which other bit as root in order to keep from getting auto-returned... and then how such linking might affect Land Impact calculations. It's worth reiterating Chic's suggestion to scale down the house to fit. Most prefabs are tremendously oversized (and most furniture, too, in order to fit the huge scale of most houses), so shrinking it all down will almost always improve things even if you can fit the full-sized version.
  10. I never noticed those before, but I suspect that was the intent because they're named "intersection crossover" -- but if so they can't have been very effective, buried a half meter or so below the road surface. On 4-way intersections there seem to be four of them, one in each sim. They're physics hogs, at a weight of 444 each, and based on how they look in wireframe I'd guess them to be twisted Tubes. Back when prim dimensions were capped at 10 meters, there were tricks to get larger coverage from basic prims using various twists and shears; these may have used a version of that. (Ironically, we were told that the 10m limit was to control load on the physics engine.)
  11. This no-object-entry condition is a little more common than may be apparent. Most of the Linden routes do indeed allow object entry, but Zindra is conspicuously different. Some of the Kama City sims were changed to permit it (specifically to allow unmanned Yavapods to circle some of those regions) but for example the road bordering Vallone on the north is no-object-entry on the Selano Beach East side, as is the case for the majority of Zindra. I believe object entry to roads and water of the Horizons regions (attached to Zindra) are similarly restricted. This probably doesn't substantially matter to your project, but just FYI in case it comes up.
  12. SL Moving to the Cloud

    Perhaps for small values of "almost". Actually the sim processing load fluctuates wildly and LL's small-scale virtualization doesn't spread out that load efficiently across its thousands of regions. Hence, moving to the cloud could be enormously beneficial specifically for sim processing -- but there's sure to be some surgery necessary to remove assumptions in the code about executing on the same processor from minute to minute. While they're at it, if it were me, I'd revisit the "region idling" approach for opportunities to more aggressively reduce processing when there's nobody around... and possibly introduce new "on demand" land products.
  13. Sansar

    As far as I can tell, the choices are to create outside Sansar, or in the manner drug-induced hallucinations are "created."
  14. Trying to buy land for group, transaction not going through?

    The 10% bonus applies immediately when the tier is contributed to the group. In the group's Land/Assets tab "Your contribution" gets that 10% boost when added to "Total contribution." Billing, on the other hand, follows a monthly cycle, charged in arrears for peak usage during the past 30 days. Always, always, always update your tier to make sure it fits the amount you expect to pay in the month after the current billing cycle concludes. (That next cycle's bill will be issued 30-60 days hence, depending where you are in your current billling cycle.) If the web form won't allow you to set it as low as you intended, you'll continue paying the higher amount until the billing cycle after you correct whatever's wrong.
  15. Sansar

    Wait. I just stumbled on this thread, in the Sansar for Second Life Residents subforum. Who knew? Perhaps it makes sense to segregate all the Sansar-related topics away from any parts of the forums where somebody might look. But its particularly ironic that it should be categorized under the Creation subforum, almost as if it were possible to use Sansar to create something. Those Lindens, they have a wicked sense of humor.