Dyna Mole

Just remember that you cannot choose a specific location. You specify the style of home that you want (Traditional, Victorian, Log, Stilt ....) and you are offered a location among those that are available at the time. You can abandon a Linden Home and choose a new one up to five times a day.

Either way works. If you rez your bike on the ground, it should auto-attach. (Assuming that you rez it in a place where you have permission to rez it, like one of the handy rez zones on Belliserria. ) Otherwise, you can ADD it directly from your inventory, as Quartz says.

Oh, yes we are. 😉

Thanks. That lower limit is a bit arbitrary, but we took several things into account. The maximum height at which objects can be seen on the world map, for example, is 400m. Also, there have been several discussions here in the forums about how far above someone's house you have to be before it's impossible to cam inside. It turns out that it's something like 300m. When you take into account that we have terraformed Bellisseria with some "mountainous" regions that are well above the average 22m elevation of most of the Mainland, it seemed that setting the lower edge of the fly zone at 400m was a reasonable choice. It's high enough to keep travelers from peeking into places where they shouldn't. The 2000m upper limit guarantees that flyers won't bump into any skyboxes or random garbage either.

That doesn't even sound easy. It's always possible to turn of all scripts in a parcel or region, but I can't think of a way to lock up just one script -- especially if I don't know exactly which script to lock. There are a huge number of security systems out there, and it's not hard to write new ones. Even if I had a tool that could target a specific type of orb, we'd be playing an endless game of Whack-A-Mole to find and lock them all. That's sort of the situation we are already facing as we try to keep up with the evil ones that residents report with ARs, so that hypothetical tool wouldn't help much. Worse than that, if I could think of a way to lock someone else's script, you can bet that griefers would also be able to do it. Talk about my worst nightmare ..... 🥺

The LH Security System is not designed to control access to your house. It is a parcel control, activated when anyone crosses the parcel boundary. Like any security orb you might buy from the Marketplace, it doesn't even know that your house exists, so it does not communicate with Control Panel functions. (In fact, you might want to whitelist a completely different set of friends for access at the altitude of a skybox than you allow on the ground, so you could rez a separate Security System up there.) You rez the LH Security System once and you never have to replace it as long as you own the parcel. It's available because we wanted to provide a security system that could be placed anywhere in the parcel, at any altitude, and would be fully compliant with the Linden Homes covenant. That is, it can be placed anywhere in the parcel, will allow at least a 10 second warning, will only eject unwelcome visitors (not send them home), will only detect people within the parcel boundaries and within the altitude range that you set, and will ignore people in the free airspace between 200 and 1000m. By contrast, the Control Panel is specific to the house model that you choose to rez. Each house has its own characteristics and may have different options than other houses within the same theme, so each time you rez a new house, you get a new Control Panel that is built into it. The access list that you create in the Control Panel deals with your house, not the parcel. It is saved remotely, so it persists if you rez a new house on the parcel, but its focus is entirely on house functions. Decor choices are also saved remotely, but are deleted if you rez a different style of house on the parcel.

I quite agree. Any experienced SL resident knows how to get past a locked door. Still, a locked door is a gentle deterrent, a signal to visitors that you really don't want anyone walking in unannounced. In my mind, though, that's not the most important reason for having access controls on the Bellisserian homes. When you give access to people on your list, you are not just letting them open the doors and windows; you are also letting them use many of the functions of the Control Panel. They can do things that nobody can do by just sitting on a chair from a distance to enter the house. For that reason, it makes great sense for the system to ask you to opt IN to using the access list rather than trusting that you will think to opt OUT of using it.

It actually does make sense, if you think about it for a bit, or at least it's just as logical as doing it your way. We weren't really trying to mess with you. The system is designed to let you create a list and decide when you want to use it. You can deactivate the list and have some ME time when absolutely nobody else can come in. We asked ourselves whether to make the system default to "Use List" automatically -- which is what you and Sam1 expected -- but decided to make your privacy the default instead. So when you start a list, you opt IN to using it instead of opting OUT of it. And of course, as Mika pointed out, we provided an owner's manual in the form of a notecard in your mailbox (and in more detail in both the Knowledge Base and the SL wiki), and we have the Control Panel send you a reminder about "Use List" in chat every time you modify the access list.

As you know, there are a few textures in the Content Packs already, so that's not a bad thing to wish for. There's a limit to how many more would be useful, though. Surfaces in the homes are all mesh faces, and the textures are UV matched to them. With the exception of some very flat surfaces like walls, our textures wouldn't look good at all on most add-ons. Textures that we use for woodwork, doors, railings, and many other parts of the house can't simply be dropped on other objects. Most surfaces in the homes also have normal and specular textures that add subtle depth and vibrancy; again, these are designed for the specific mesh faces that we put them on.

As Abnor says, we have ways to replace or update existing content in Bellisseria fairly easily. That's sometimes necessary when we discover that there's a flaw in something like a tree or a wall that we've deployed. It's also a key element of our flexible design for the new Linden Homes regions -- a way to keep them from getting dated too quickly. If you look in the notecard that's in the Content Pack in your house controller (mailbox) , you'll find a sentence that says something like "Please note also that Linden Lab may offer new house models or upgraded versions of existing ones from time to time. When that happens, current residents will be notified. You may choose to use the House Controller to select a new model or upgrade at any time." Unless there's some really critical reason to do it, we're not likely to update your own house ourselves because that could mess up custom colors or other custom features. As that sentence says, we'll let you know that an upgrade is available, leaving you with the choice to rez the new version from your house controller. Similarly, if we ever decide to add completely new house models to current themes, we'll just add them to your house controller and let you decide whether to rez them.

Take a look at my response in this thread from last autumn, where the Memorial Garden was discussed most recently: Some day, when there are no projects with higher priority facing LDPW, the Lab will possibly decide to do a deep makeover of the Memorial Garden. That sort of decision is way outside my authority and will be made by people well above my pay grade. I won't dare to guess when it may happen.

Those are veggie hot dogs, a worm-free product from Mole Kitchens™, created for discerning Bellisserians who appreciate the health benefits of meatless outdoor dining..... "Mom! These are the YUMMIEST!" 😍

Yeah. Ooops. /me slides away to relax for the weekend.

Our approach to managing doors, windows, and blinds has evolved since we released the Traditional Linden Homes. Initially, each window and blind had its own script, so that they could operate independently. It didn't take us long to realize, though, that all those individual scripts -- even though they are small -- add up to a lot of potential load on the region servers. We replaced that design with a more complex one that uses a single script to manage all doors, windows, and blinds in the house. Until very recently, though, we have still been managing the blinds in large groups, one per room. Moving to allow residents to once again control each window's blinds separately has been a challenge. Because mesh models of the homes themselves have evolved over time, it's easiest to apply script upgrades to the most recently-released homes -- the stilt homes -- first. We are doing that cautiously. Meanwhile, if you find that windows, doors, or blinds do not work properly, check first to be sure that people who are trying to use them have been given access and are wearing group tags if necessary. Then, consider rezzing a new copy of the home. If even that does not fix things, submit a support case.

..........

Unchecking the box that keeps anyone other than the parcel owner and group members from running scripts is certainly the best solution, as Abnor says. As a point of clarification, though, you should know that most modern scripts for HUDs (especially those for AOs) contain code that allows them to continue running if they were running before you brought them into a no-script area. That's true for many vehicles as well. So, your friends' body HUDs should work now if they were wearing them before they entered your parcel, even if you have script permissions turned off.

That's exactly the right thing to do, Sylvia. Re-entering the RGB values for the walls in your home really doesn't take much time. If you have written down ones that you like in a handy place like a notecard or the Notes area in your own profile, you should have no worry about losing them. When we were designing the custom tinting system, we considered several approaches. The biggest challenge we faced was memory use. The Linden Homes are controlled by four major scripts, each of which is large and eats up a lot of memory, even before you start stuffing it full of user input (access lists, texture preferences, the states of moving parts like doors and windows...). We can send some of that user input to be stored in Linden Lab's KVP servers, so that it's available if you decide to re-rez your home, but then finding and retrieving it on demand becomes a challenge. We have regions full of residents in different styles of home and with their own individual preferences. It's one thing to save your choices among a handful of preset values. Storing a huge stack of custom values is a much larger challenge. It's easier on the system if we expect you to store those custom color values yourself.

Exactly, except that the database is not "external." It's buried in the server networks that manage all SL assets and functions. (It's now actually all in the cloud -- which I guess is technically "external" after all. Go figure.) Anyway, we have to store an immense amount of information about each parcel in Bellisseria. Every time you rez a new home, we record which model you chose and then add all the information about what color/texture choices you made for walls, woodwork, and the rest. We also save any information you add to the home's access list. All that information is updated every time you change anything, and is reloaded and applied to a new house if you decide to rez a new copy of the same house. Changing the house style resets the color choices but not your access list. That way, the choices you make (except for custom colors that you make for walls) are saved as long as you have a house on that parcel. If you abandon the parcel, it's all wiped and reset to default values so the next owner can't see your access list and can start fresh with her own choice of colors. Much of that information is also saved locally in scripts in your house, along with other bits of information that are only important temporarily. As a result, you get homes that not only respond instantly to changes you make but also have backup records stored remotely. We can use those records in KVP for diagnostic purposes if we need to help fix something and, as I said, they automatically reload into a new house if you ever want to start over.

Yes, I understand that. If I remember correctly, someone once asked Abraham Lincoln how long his legs were and he answered, "Long enough to reach the ground." That's the way it is with the stilt houses too. When we write the scripts for any of the houses, one of the questions we ask is, "How high above the ground should the main floor be?" In the case of a stilt house over water, we ask almost the same: "How high above the water level should the main floor be?" Once we have that question answered, the stilts take care of themselves. If the moles who created the mesh models of the houses did the job well, the stilts are long enough to stick down well below the seafloor. The part that you see just has to be "long enough to reach the ground," no matter how deep the water is.

Actually, that's not true. All Stilt Homes have stilts the same length. An OL house has front steps because you're meant to approach it from land and then walk up to get to the front door. An OW house has no front steps. If it's attached to a pier, you walk in directly from the pier, making your last few steps on a special walkway that leads right to your front door. If the house is not attached to a pier, there's no point in entering by the front door (which is why we provided an optional baby gate in the Content Pack, so you wouldn't step out the door and get wet). Instead, you moor your boat by the rear deck and enter the house by one of the sliding doors. So, the short answer is: OW houses don't have front steps. Your mailbox knows which type to deliver.

Showoff. 🙄

They are Moles Of Few Words. Heads down, burrowing onward. A loyal mole never rarely hardly tarries.

We have learned a lot about efficiency and quality assurance since the Traditionals were released. The current approach -- creating a large mass of regions to seed a new theme and then filling in the transition zones around it -- is a better use of creative time and makes many more new homes available at once than releasing a few regions at a time. No matter which way we do it, the final step before opening the doors is to do detailed QA. A careful sweep, as soon as new regions are in place and before residents start flying across and adding their own content, is the best way to guarantee that all our work is up to project specs. It saves a lot of disappointment and user complaints later.

It's a feature, a dramatic special effect that we reserve for rare occasions when all the stars align and circumstances cry out for creative whimsy. If you teeter on the edge of a volcano or go exploring in a hidden cave, you should be more wary than usual about odd moleworks. Embrace the moment. When you're just walking down the street, minding your own business ... nah. We don't do that sort of thing. 😇

If that boggles your mind, consider the meta-QA world in which testers are wandering around inside SL looking at the scripts that Quartz Mole and I write .... virtual testers inside the virtual world examining code inside virtual objects. It's turtles all the way down, they say.