Ceera Murakami

If all you want is different appearance setups, like one look that is a 20-something girl, and another that is a quad housecat, and another that is an anthro vixen, and one more that is a burly male truck-driver type, but all can have the same name over their head, then that is just different outfits worn by one avatar. Buy new avatar sets, like a furry avatar that makes you into a vixen, and wear it. Changing your body, including gender and all other physical description factors, is as easy in SL as changing your shirt. Switch between them at will by selecting them in inventory, and wearing the new stuff to replace what you had on before. My main account has over 100 different looks like that. They would all say my name over them, but they can look 100% different. If you want a completely different name, friends list, inventory and everything, and the ability to log on with more than one of those accounts at once, then you create a second account. This is also called "Making an alt". There is no linkage between individual accounts at all. They are unique individuals as far as the Lab is concerned, andf share nothing between them in common, even if you register them with the same real-world info and mailing address.

Quite probably the reason you percieve so many 'cheaters' in Linden Realms is that after the firsrt few hours, when you've completed every possible quest, there's nothing to do there except swoop around and collect crystals. The Residents that aren't into doing that leave after a day or less, and have no reason to return. The ones willing to spend lots of time scooping up crystals for minimal rewards are far more likely to try to do that as efficiently as they can, by any means that they can. What amazes me is that anyone at all spends more than a day playing Linden Realms.

Can you do one? Yes, absolutely, and several people already are. However... LL won't allow you to promote your third party commerce site in any of their official forums, nor will they sell you advertising for your business. Meanwhile, LL advertises SL Marketplace heavily to all SL Residents, from every possible angle. You're effectively trying to compete against a company with a much larger advertising budget, that can prevent you from having equal access to the potential customers. Since LL took over XStreet-SL, which later became SL Marletplace, most of the third party e-commerce sites have died, or have been relegated to a very small niche of the market. The average resident has no way to know a third-party e-commerce site even exists, unless they hang out a lot in the third-party forums related to SL. It's worse than trying to open a mom-and-pop general store right next to a Wal-Mart, in terms of the unfair advantage that SLM has over any other means of sales in SL.

In regards to both problems, do you have cookies or javascript disabled in your browser? A lot of LL's pages wont' work without both being enabled, and that mat be what is wrong with your landlord's site too.

Nope. Most hair uses a mix of alpha and non-alpha prims, so an invisiprim wouldn't help you to hide someone else's hairstyle. The buyer of the hat will need to mod a copy of their hair so the hair doesn't poke through.

Adding to the above, if you do have something that needs to be deeded to a land group to work, like a security orb, what you can do is buy the item back (by setting it for sale, and buying it) in order to edit it, and then deed it back to the group when you're done. The advantage of that versus returnig the item is that the item remains in-world, which you probably want to have happen for a security orb.

Unfortunately, almost ALL of the translators in SL, including the one built into the LL Viewer code, relied on the formerly-free Google Translate API to function. Google closed that free service, and made it a paid service that is rather expensive in the context of something like SL chat. If anyone knows of a functiuoning free translator that works, and is confirmed to work, please post that info here. You can connect the translate feature in any V2/V3-based viewer to a paid service, either from Google or from Bing Translate, if you set up an account for yourself with that paid service and are willing to pay the fees they charge. As I recall, the Bing service has a small level of free translation, but you'll burn through that pretty fast if you use translation a lot.

One script can invoke functions in another, certainly, All they need to do is communicate with each other. They might use llWhisper, llSay or llRegionSay on a specific chat channel, with listeners on the same channel. That can communnicate between different linkests entirely. Or they may use llMessageLinked, with a different type of listen for linked messages, for communications within a single linkset. But all the scripts need to be running at least a listener of some sort, for that communication to happen. For example, I made an elevator. The script in the floor call buttons makes the scripts in the elevator car, elevator car doors, and shaft doors do things at certain times. The script in the elevator car makes things happen with the doors of the car and the doors of the shaft. When they aren't doing things, the scripts just idle and listen for further commands. But they are all running.

Were you forced to re-log by a sim restart, just a short time after you placed the items in-world? If so, I have bad news. The central asset servers probably had not yet updated the changes in your item placement, and you have lost the items entirely. It is unlikely in such an event that you will get the lost items back.

We had that once. It was called the "Main Grid" (Adult) and "Teen grid" (G-rated). LL deemed the G-rated teen grid a failure, and closed it, forcing the 16 and 17 year olds into G-Region-Only main grid access. Then they caused massive disruption my forcing the Adult businesses to moce to an "Adult" rated mainland continent. Residents argued at the time that if LL wanted to run a virtual world with no Adult content, they should have started a "family Friendly" grid at that time, and left the main grid as it was - for 18+ adult use, and perhaps made it possible to migrate avatars from the Main Grid to the Family grid, for those who preferred a sanitized, PG-13 environment. They could easily have done that. Adult instructor accounts on the Teen grid were created on the Adult grid and migrated to the Teen grid by LL, with their inventories, as a one-way move between grids. Teens who tuened 18 got a one-way move to the Adult grid, with their inventories intact. . LL ignored that advice.

Also bear in mind that you need to buy or rent land to put the house on, once it is built (or as a place to build it, though you could do the building in a sandbox area.) The land you put the house on needs to be big enough to contain the physical shape of the building, and also needs to be big enough to support the number of prims the house requires, and some left over for furnature and other things.

Trying to become a Kitsune? (For those who don't know, a Kitsune is a Japanese spirit fox, with between one and nine tails. They gain one tail per hundred years of life, aproximately. In China they have a similar creature, called a Huli Jing.) Here's how I did my three-tailed Kitsune tail, and going for nine is just more of the same technique. Start with the single-tailed avatar that you want to base your Kitsune on. For example, the KZK red fox or arctic fox. The avatar needs to be modifyable, of course, but most furry avatars are. Go to a parcel or sandbox where you can build, and where the parcel isn't nearly full. Furry tails often have quite a few prims in them, and making multi-tails can run up the prim count pretty quickly. Drag a copy of your tail onto the ground in-world. Edit it, and you'll see that in addition to multiple prims (likely cone-shaped flexible prims) that make up the visible tail, there is a sphere prim at the base of the tail that is the root prim, and that all the other parts are linked to. This sphere contains the scripts that make the tail wag or respond to other HUD commands or chat commands. If the tail is trying to wag on its own, wait until it is in its resting position, between wag cycles, and stop the scripts in the tail. If it is stuck in mid-wag, select the tail and use the edit tools to set the rotation values all back to zero. Copy the tail in-world, by selecting it with the edit tools, holding down the shift key, and dragging it sideways. With the copied tail, select it, and delete the scripts in that tail. (You may want to rename that as 'unscripted tail' and take a copy into inventory.) Now make another copy of the unscripted version of the tail, by shift-dragging it to the other side of the scripted one. You now have three tails, and the center one still has its scripts, but those scripts are stopped. (you can make as many additional unscripted copies as you want tails, so you have enough of them.) Turn on 'highlight transparent', so you can easily see the position of the base spheres. One tail at a time, rotate the unscripted tails so they angle outward from the center tail. Move the tail so its sphere exactly overlaps the main tail's sphere. Now shift-click on the main tail, and link them. If you did it right, the root prim should still be the one with the scripts in it. Be careful though, because once you link them, you can't readily unlink any single tail in the set to adjust its position. Repeat the above steps to add additional tails to the main tail, sticking out at different angles. When you are done, you'll have one tail attachment that has a huge number of tail prim parts attached to it. Rename that tail as 'My Kitsune 9-tail', or some other recognizable name, set scripts to 'running' in it again, and take it back into inventory. When you 'wear' that tail from inventory, it should replace your avatar's single tail with a floofy collection of nine tails, that wag in sync and respond still to your avatar's HUD commands, for things like raising and lowering the tail. === As an alternative (which I haven't tested yet), any of the newer V2/3 based viewers support multiple attachments on a single attachment point. So for a lower number of tails - up to 5, I believe, you could just copy the tail in inventory, and 'add' the extra tails to your avatar. If you do it that way, each tail would wag on its own, rather than all at once. I don't think you could attach nine tails at once, though.

It's either a texture on the floor, or if you seem to see a 'sunbeam', the shaft of light is a translucent and phantom prim. There is a "real-time shadows" feature to SL, where a wall with a window in it really will cast a shadow, and a beam of sunlight through the window, but most graphics cards can't do it.

On the Mainland, 51 M above the terrain, any person that you haven't banned explicitly by name can fly into your parcel, ignore your ban lines and/or group access restrictions, look down (or up, if you're in a skybox), and the 'parcel privacy controls' won't do squat to hide you. While it is certainly nice that you can now hide the avatars on your parcel from anyone who is not on (or above) your parcel, that isn't even close to the control or privacy that you have living on a non-public, privately owned sim. On a private sim, if I say only a certain group's members can go there, that is what is enforced. A stranger can't enter the sim at any altitude, or by any means, unless they are a Linden staff member excercising super-user capabilities.

I've commented on that JIRA and set it to 'watch'. Thanks for noting the problem and raising the JIRA for it.

Deltango Vale wrote: Thanks for the link. My RLBF used to design databases. Since I am not an engineer (and feel kinda bad about it), I asked him to sit down and patiently explain to me why it is so hard to have first and last names. He said, "It's a piece of cake." So, let me try to explain what he said (and forgive me if I screw up). All avatars have a 'key' (I guess our UID), a unique number that is our 'identifier'. No properly designed database in the world uses names for keys. ... Am I anywhere close to understanding the problem correctly? The problem is that the core LL databases are not 'properly designed'. The databases weren't designed by database coders trained to 'do it right', but were designed by game designers who happened to know enough about coding a database to 'make it work'. So they DID use a concatenation of the first and last name text fields as the primary "Key" for indexing many of the most essential databases. It worked, and they saw no problems with that method, at the time. UUID's for assets and people were an afterthought. The primary index key in a lot of the existing code is still that stupid concatenation of the two name text fields! As far as I can tell, first name and last name are still individual fields in the actual databases. The current 'single name' is a pseudo-field, calculated from a concatenation of the first and last name, with both values forced lower case and a period put between them. The legacy "full name" pseudo field is the first name, a space, and the last name, with capitilization untouched. Many databases do use 'pseudo-fields' of that type, but using them as a reference key is bad practice. What they are supposed to be used for is as a single value that can be called for display purposes. Like being able to call a 'mailing address' in one call, from a value that concatenates many values in the actual database, such as city, state and zip code. Could they fix it? Yes, but it isn't as easy as it seems on the surface. Any current code that they write would, if the coder is competent, use the UUID as the referenced index key. So when a new form or process links person A with asset B, it would certainly use the UUID's to do that. But there is a ton of legacy code from before UUID's were added to the system, that has never been touched since it went live. There are lines of code burried deep in the server code and viewer code and the various database structures that don't know what a UUID is, and that only reference that concatenation of first and last name as the index value. For example, maybe the cross-check to see if a certain avatar has permission to update the ban lists for a parcel is still using the legacy method. Or maybe the code for handling change of asset ownership still uses the legacy code.To fix the problem, they would have to examine every last line of code, to make sure they didn't miss some function that used the old indexing method. Otherwise, if they started allowing name changes en-masse, (thus changing a referenced indexing key), they could have chaotic results, where one system knows the change took place, but another can't recognize that the new name is associated with the former UUID. If they did take the time to ensure that no code, anywhere, still references the name fields as an indexing value, then and only then could they allow changes to existing names, on more than a one-off basis.

The OP is correct in their observation, unfortunately. It used to be that if you selected all the faces of a prim, and more than one texture was on those faces, it would show you the texture on the lowest-numbered face of the root prim, and put the word "Multiple" over that text in the texture preview spot, to notify you that more than one texture was selected. That does not seem to work any more in V3.2.6, and it is a serious problem for content creators. It means that in the current viewer there is no way to quickly determine if all faces in a selected prim or linkset display the same texture, without visually looking at or clicking on every face. This means that it is effectively impossible to inspect a linkset for faces that didn't take a texture properly. I would suggest opening a JIRA report on this, as a bug - a loss of functionality from earlier versions.

Was it "Prince D" before you changed it? Sometimes it takes a while for a changed display name to show up properly in all cases. If you didn't have "Prince D" as your former display name, that sounds like a glitch in the system. You may need to wait 7 days, and try again to set your display name.

Not 'Free', no If you purchase a Premium membership ($72 USD per year), one of the optional perks is a small 512 M2 parcel with a house that doesn't count against the parcel's 117 prim limits. But it's free only in the sense that you pay nothing extra for it, but you lose it of you stop paying your Premium dues. These free "Linden Homes" are suited primarily to newbies, as a taste of what land ownership is like. Any Premium member can have one, but a more experienced user would tend to want more prims, and fewer limitations.

Look at the 0,0,0 coordinates in the sim (SW corner, as low as is possible). Sometimes items that wander off the edge of the sim end up stuck at those coordinates, instead of being sent to the owner's lost and found.

Titles? Meh, no thank you. Far too much room for abuse. Last names: Seems simple to me. Make the last name field a free-entry text field, and be done with it. Filter what is allowed the same way the first name field is filtered, so a patently offensive name can't be selected. The concatenation of first name and last name need to be unique, and not already registered in SL. What else do we need, really? Maybe unlock the ban on use of 'legacy' surnames? I would be happy to register "Ceera" as a first name, with the surname of my SL Partner, who has been my partner since 2006, but whose surname was unavailable to me when I joined in late 2005. The name combination is unique. The only argument I can see against allowing the name to be registered is to artificially make 'legacy surnames' a special thing for early users only. This isn't rocket science, Rod. Just give us the ability to have last names.

The construction of the avatar mesh in the groin area is terrible. With many otherwise lovely shapes, if you look closely at the crotch and the insides of the thighs you'll see some horrible deformations there. Some animations make this even worse, or can cause an avatar shape that shows no apparent deformation when standing have issues there. It's just a glitch that we all eventually learn to ingore.

Land can only have one "Owner". That is either the person who purchsed the land, or it is a group that the land is deeded to. If the land is deeded to a group, then the group has a role called "Owner", which one or more people can belong to. The only way you could be co-owner of land is for it to be group-owned land, and you are a co-owner of the group. Someone who is already in the "Owner" role for a group can invite another person to the Owner role, but can not eject them from that role later - they must voluntarily leave that role. There are many other roles possible in group land, which can have various permission levels. Normally, you do not want most of the group members to be in the "Owner" role. It's really for the one person or small group of people capable of excercising full rights to the group's pand, including the right to sell group owned land, or buy land for the group. If you are the group Owner (or a co-owner), then you can eject other people from any role in the group EXCEPT other Owners. Normally, a group has only one "Owner" you would use the "Officer" group role for additional people with permission to add new group members or eject people from the group. If someone is not in the "Owner" role in a group, they can only invite others to the roles that they belong to themselves in the group. Officers can be given the permission to allow land access or add names to ban lists or eject banned people from the parcel of land owned by that group. Other group roles can also be given those permissions.

Textures that you have copies of in your inventory, just as a texture or a snapshot, count as one inventory item each. In other words, if you have it in a form that you could apply to a prim, then yes, it counts as one item in inventory. The textures applied to objects in your inventory make no difference in terms of inventory count (assuming someone else made it, and you don't have those textures as free-standing items), nor does the complexity of the item. An untextured plywood cube counts as one item if taken into inventory. That same cube prim with six different textures applied to it, one on each face, is still only one item in your inventory. So is a 3000 prim building with hundreds of unique textures applied to it, and taken into inventory as a single coallesced object. If you place items into a prim, and then put that prim in inventory, the storage prim only counts as one item, no matter how many things are stored inside it. This is a handy way to reduce inventory count. Take inventory items that you seldom use, or never use but are unwilling to throw out, and put them in a prim, and save the prim, deleting the originals in inventory. Be careful though about no-copy items. Placing a single no-copy item in a storage prim like that makes the storage prim itself no-copy, while that item remains inside it. That means you can't make a backup copy in your inventory.

Sounds to me like a combat HUD that has been around for a long time. It offsets the apparent position of the user as much as a full sim to one side of where they really are.