Jump to content

Quartz Mole

Mole
  • Content Count

    194
  • Joined

Community Reputation

1,760 Excellent

10 Followers

About Quartz Mole

  • Rank
    Advanced Member

Recent Profile Visitors

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

  1. It's not a skybox, and it's an object set to LDPW on LDPW land, not an object belonging to a resident on a resident-owned parcel. The positioning for the platforms and rezzers was, as I recall, decided months before we wrote the Covenant. And yes, it's on every region. I could ask about moving them but I know our priority is to develop more themes and release more regions, so that task would be added to the ever-growing list of planned improvements to Bellissaria when we've released as many regions as are needed, and it would have quite a low priority even when that time arrives, since the list already contains several things we really wanted to do when we we've been working on the existing regions but didn't have time for.
  2. Yes, you've found the platforms on which we keep the server-rezzers that send out the houses for the region. Congratulations.
  3. It all depends on what you're using the land for. If you're the only person using it, then I'd recommend one set of perms, but if you need either a group or the public at large to be able to do things, then you'd need a different set, depending on who you want to be able to do what. Just as my personal view, I would say, build for owner or landgroup only. That way you don't need to worry about auto-return, but your friends whom you've invited to your land group can use the place as their own. Object entry off, certainly. You don't want people to be able to slide objects into your land. I would leave scripts on. That's because any competent scripter can circumvent the restriction if you set the parcel to "no scripts", which is how vehicles and AOs keep running even when you're in a no-script parcel, so you don't really inconvenience griefers by leaving them on (but this shouldn't matter, assuming you've set your other perms correctly) but you will inconvenience a surprising number of people by turning them off. For example (since it's happened to my resident account several times), if you crash while you're on a parcel where you can't run scripts, and you forget and log back in to your previous location (the no-script parcel) it's going to mess up all your HUDs and scripted attachments, to the extent you'll probably find it simplest and quickest to leave the parcel and go somewhere you can run scripts, and relog there for a second time. But this, I re-iterate, is my personal view. It's certainly not an official recommendation of any sort.
  4. You might want to reconsider having so long an auto-return time -- only yesterday several Moles with Estate Manager powers had to waste time clearing up after a day-old throwaway account who had (we assume) been going round Bellesaria looking for parcels with open-rez turned on and rezzing some pretty nasty griefing objects when he found them. OK, if someone abuses your hospitality and drops a particle griefer or a graphics crasher on your parcel when you're not around, it's only going to be there for 30 minutes, which is better than leaving auto-return off completely, but that's a lot longer than it need be, especially for people living nearby, Our LDPW vehicle rez areas have a short auto-return time -- one minute, from memory -- precisely because of that danger. And a minute is plenty long enough to rez a vehicle, which the simulator won't auto-return while someone is sitting on it.
  5. It's important to understand that we've got nothing against objects being rezzed by scripts, and neither have we anything against temp-rez objects. What we object to, and will return, are temp-rezzers, which are objects that constitute an unacceptable drain on region resources by abusing the temp-on-rez object property and constantly rezzing and re-rezzing the same temp-on-rez object for no legitimate reason. So when you see an object that Firestorm says is a temp-on-rez object, that's nothing to worry about, in itself. We're not interested in the object. What we're interested in is the behaviour of the script that rezzes it, and how that affects the simulator performance, and that certainly requires individual observation and analysis of the rezzer, and possibly of the region performance figures too, while the rezzer is in action.
  6. The simple way is to inspect the objects when they are rezzed and see if they show as being temp-on-rez. There's no problem with props rezzing when they're needed and being removed when they're not. That's no different from your rezzing it from inventory. It's when the same item is being rezzed and derezzed and rerezzed by script every 20 seconds or so, 24/7, that it becomes an issue.
  7. Thanks. We need the slurls, but since there are forum rules against "naming and shaming" people it might be more prudent to give us the slurls by way of private messages or IMs rather than posting them here. That's what concerned me. A lot depends on the size, number and complexity of the items being temp-rezzed but generally, at least as I recall from when temp rezzers first became popular, they do have a really significant impact on region resources. Re-rezzing a complex object and de-rezzing and re-rezzing it every few seconds or so can cause the simulator performance to take quite a hit, and if there are several of them running on a busy region it's pretty bad news, or can be.
  8. Thanks. I took a look at it earlier and, as you note in another post, the meal had disappeared from the table. There's nothing I could see about the object that suggests to me it's a temp-rezzer, other than one ambiguously-titled script, so I'm not at all sure it's anything other than a standard dining-table set that rezzes props when needed and deletes them on command when they're no longer wanted, and unless I can see it running (or unless I buy a copy myself and read the instructions) I have no way of telling whether there's anything untoward about it. If you have any more concerns about it, please don't hesitate to report it, and it'll be investigated in more depth, but in the meantime I think it might be prudent to remove the slurl from your posts identifying the parcel.
  9. Thanks. I will certainly check that. Last time I played with it (or my alt did, rather) it was to make something that temp attached demo hairs to people, so the fact the demo hair had a very high LI for the moments between rezzing and temp attaching to the customer was a real issue. I did check this with the appropriate people at LL and was told there no plans to change it (though I suppose if there's a conventional prim box set to convex hull as the root and the rest of the item is set to physics shape none, then, at least in theory, that should give it an LI of one).
  10. Simply because the sort of complex mesh objects that people are likely to want to temp rez tend to be pretty expensive in terms of their LI precisely because of their physics and rendering costs.
  11. It's maybe worth pointing out that mesh objects always count against LI, whether they're set to temp-on-rez or not. Temp-rezzing mesh objects is as bad, if not worse, for the simulator than is temp-rezzing prims and sculpties, of course, but people don't seem to realise that they're not even gaining any particular advantage from their selfish and antisocial abuse of this function (originally intended so things like bullets and arrows on combat regions can be used without worrying about LI).
  12. Have you considered Discord? Most RL projects in which I'm involved use that now, precisely because of the issues with Skype you describe, and I find it a lot more reliable.
  13. Ahem. Perhaps not the most tactful request More seriously, if you re-read the covenant, you will see that " Changes cannot be made to roads, paths, plants, trees, rocks and other landscaping. Trees or other objects that overhang into parcels are meant to do so. They cannot be moved or removed." Unless something's actually broken, we're not allowed to change it. If we did, we'd spend all our time landscaping people's parcels and never get any more regions built.
  14. When we first released the Traditional homes and Houseboats, we had touch scripts in all the links that would receive touches to trigger things -- doors, blinds and windows. That's why you could touch the floors to double-click tp around -- there was no script in them. However, as the houses grew more and more complex, it became clear this meant each house would require an unsustainable number of scripts in the child links, so we completely rescripted the system to control all the windows, doors, blinds, and all the tinting and texturing, from a few scripts in the root prim (we had to use several scripts in the root because of script memory limitations). However, this does, of course, mean that one of the scripts in the root prim has to detect touches from every link in the linkset in order to determine which face of which link was touched (and by whom) in order to decide what, if any, response is needed. That's what's happened, and I am sure it was the right design choice, since it greatly decreases unnecessary demands on the simulator. On a related point, the housecontroller (mailbox/preserver/sign) isn't the root prim. It's not part of the house at all. Its main function is to communicate with the house, the owner of the parcel, and several remote servers and relays. The actual root prim is positioned several metres up in the air above the housecontroller -- it could be anywhere so long as it's not on the parcel, but positioning it like that makes positioning the house easier when it arrives from the remote rezzer.
  15. Looks like it's a problem with the region -- I tried just now but I can't tp into Wavebreak either, and I get the same message when I try to fly in. Since I happened to see the message, I'll report the issue but the best way, in general, to deal with such matters is for you to contact support direct -- https://lindenlab.freshdesk.com/support/solutions/articles/31000131009-contact-support
×
×
  • Create New...