Quartz Mole

According to the wiki, the limit for IMs and inventory offers (combined) is 15 for regular members and 80 for premium members. http://wiki.secondlife.com/wiki/Limits However, since you're particularly concerned about notecards, you will be pleased to see that http://wiki.secondlife.com/wiki/Limits So it looks as if you can allay your concern about not receiving notecards simply by switching that debug setting to TRUE (if you use Firestorm, I'm pretty sure you can do it from the Preferences tabs, too).

Could anyone with one of these houses still affected by this bug please send me a message via a PM in this forum or an IM in world? I'll come and fix the immediate problem and and inspect the duplicate house to see if I can find out what caused the bug in the first place, since to do that I need to conduct an onsite inspection.

Try attaching your facial animation HUD in an area where you can run scripts, before you tp to Ahern. If the HUD is properly scripted, it should continue to work in no script areas, so long as it's attached and running when you arrive there.

Next thing you'll be telling me that people don't read product notecards and operating manuals!

Thanks, but what's the practical advantage to doing that? As I understood it, the original complaint was that people are not able to move around the houses using double-click teleports in the Victorians, and won't be able to in the Log Houses or subsequent themes, as they are in the Trads, Houseboats and Trailers. Unless I'm missing something in your explanation, that still won't be possible using your method, will it, since the touch events will still be raised? If I wanted to double-click TP around my house, I think I'd put down large flat transparent prims on the floors, so when I double-clicked them, it would trigger the teleport. Off the top of my head, I might be able to fake double-click tps using experience tools and llDetectedTouchPos, but I'd need quite some convincing it was necessary before I even thought about trying to persuade Patch to agree to my spending any time working on it, since the control scripting for these houses is quite complex enough already (and we'd get complaints from people who were being teleported unexpectedly because they'd accidentally clicked things), and since people who really want to be able to double-click tp can do so already at the cost of only a couple of LI.

If you put a script containing a touch* event in the root prim of an object, then the script detects touches in every link in the linkset, at least what the script is in the state containing the touch* event. Same with collisions and collision events. Our scripts do, of course, work by using llDetectedLinkNumber/llDetectedTouchFace, which they then use to access all the information they need to decide what, if anything, they need to do with the link that's just been touched, and then do it with llSetLinkPrimitiveParamsFast. But there's no way I know of to make them detect touches from only some links in the link set and not others. To do that, I would have to revert to putting individual scripts in all the doors and windows, to communicate with the root prim when they're touched, which is what we did in the Trads, House Boats and Trailers, before rejecting that technique as an unsustainable waste both of region resources and Dyna and my scripting time (or possibly I could put scripts that contain only an empty state_entry, but no touch event, in all the links I don't want to be touchable, but that would be even worse). If you (or anyone) can show me a method that will allow me to put a single script containing a touch_end event in the root prim of a complex object like a Belliseria house and thus make some, but not all, of the links touchable, I would love to know how to do it, but I don't think it can be done. I'm always happy to be proved wrong if it means I can learn a useful new way of doing things, but as far as I know, I have to have the script detect all touches, and then ignore ones I'm not interested in.

All our houses have built-in blinds as part of the standard scripting. The Log Homes will be no exception to this. So if you want to save the LI for something else, you can obscure the windows simply by touching the glass and making a blinds texture appear.

Because we now control all the doors and windows from a single script in the root prim to economise on script usage on the region, the whole house has to respond to touch events, so that the process touches script (which handles this) can determine what, if anything, it needs to do about the link that was touched. Sorry, but all parts of the houses are going to remain touchable from now on. That's not going to change.

There's a Knowledge Base article on how to file Abuse Reports you might find helpful: Also, Abnor Mole recently provided some very useful tips on what sort of things you need to include, and what you need to avoid, in your report: My free SL tip: in my experience, the words "No Drama" in someone's profile usually mean the complete opposite.

/Me joins Bloodlines and channels Bela Lugosi... I do not bite.... sandvichessss.

I think what you're seeing there are two of the Victorian houses with colour-coded copies of the individual internal wall meshes above them, but somewhat offset, for ease of reference when we're checking the face and link number of each room's walls -- they're very difficult to keep track of. But then I would say something like that, wouldn't I?

We have now put some updated houses in the rezzers which should fix the issue -- if you're having difficulties, please rez a new house (it's safest to stand outside the parcel when you do this because if the house collides with an avatar while it's rezzing and initialising, this can cause weird physics issues with the mesh) and give house 30 seconds to finish reading all the data it needs from the servers. After that, the owner should be able to use it without difficulties. If problems persist, please report the issue by raising a support ticket, giving the slurl for the house, obviously, and also the full name of the house (select the house in edit, and copy-paste the name), including the version number. The latest versions are Doyle: v1.24 Hardy: v1.25 Shelley: v1.26 Verne: v1.25 If your house does not have that version number, please re-rez it, and if the new house fresh from the rezzer still has the wrong number, please report it as a matter of urgency (as far as I could tell after the update finished, all was well, but SL never ceases to find ways to surprise me).

vector vAvocado = <0.39535, 0.60930, 0.01395>; default { state_entry() { integer n = LINK_THIS; if(llGetNumberOfPrims()){ n = LINK_SET; } llSetLinkPrimitiveParamsFast(n,[PRIM_COLOR,ALL_SIDES,vAvocado,1.0]); } }

Yikes! I remember avocado green walls the first time round, in the 70s.

Hotel Chocolat are a British company but I think they will probably ship to Canada and the US: They do chocolate bars and batons in several different strengths, including 100% chocolate (with a choice of countries of origin for the chocolate bean) https://www.hotelchocolat.com/uk/shop/collections/products/luxury-chocolate/?prefmin2=40&prefn1=chocolateTypes&prefmax2=100&prefn2=measureCocoaPercentage&prefv1=Dark (They have a shop about 10 minutes' walk from my apartment in First Life, which is handy!)

One of the many things we Moles love about this forum is comparing the extrapolations we read here with what we know to be the case. If LDPW did have its own independent nuclear capability -- which it's above our paygrade to know whether we have or not, and even if, hypothetically speaking we did have one and were authorised to know about it, our NDAs wouldn't let us discuss it, were it to exist -- then we might well want to hide it. Just saying. Ah yes, the mysterious SSP83X. Dyna and I keep telling people we simply use it for building, testing and debugging purposes, but that's just what we would say had Patch told to spread disinformation about what we're really doing, wouldn't we?

Vehicle scripts, be it balloons or anything else, are a bit like particles -- that is, there's no great mystery about the script itself but the real art (and it is art and not science) is tweaking the settings until you have the item working just as you want it to. So if you've got a full-perms hot air balloon script that you like, then the settings in that script should be a very good basis for any model into which you put it.

Thanks! Fixed now.

The workaround is: Step off the parcel Rez a new house Do not re-enter the parcel, touch the house, or try to interact with it in any way, for 60 seconds After that, everything should work as expected. We know what's causing the problem and have a solution ready, which we will roll out as soon as we're given the go-ahead.

They're used by the Moles placing trees and suchlike near houses since, while branches may overhang the parcel boundary, so long as the root prim is on LDPW land, they obviously can't be allowed to poke through into any of the houses that may be rezzed on the parcel, or block windows and so on. Those detectors are composites of all the house models in a particular theme, scripted to position and orientate themselves on the parcel where the houses will be, so it's easy to check that nothing is too close to any of the houses. What they're doing at the bottom of the sea is a mystery to me, but someone will doubtless remove them before the region is released.

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.

Yes, you've found the platforms on which we keep the server-rezzers that send out the houses for the region. Congratulations.

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.

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.

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.