We updated Kitely today with several bug fixes to OpenSim that will make it easier to build attachments. We also made several improvements to Kitely Market, and added a couple of features that had been requested by our users.
Bug Fixes in OpenSim
If an attachment was rezzed and then taken back into the inventory then it forgot its attach point and position, which forced you to set them from scratch. This affected mostly creators of attachments, because other people rarely rez their attachments on the ground. This bug has been fixed.
In addition to the in-world fix, the attach point and position are now also saved in exported OAR files. However, currently only Kitely recognizes these fields because this bug fix isn’t a part of OpenSim yet (see Mantis 4905). Therefore, export and import of such OAR files in Kitely will retain this information, but loading the OAR in a different grid will lose the data.
When editing an attachment while it’s attached to the avatar, if you moved the root prim by itself then all the other prims disappeared. (Actually they still existed, but were moved far away so they could no longer be seen.) This bug has been fixed.
When editing an attachment, other people couldn’t see the changes you made until the attachment was detached and reattached. Now other people will see the changes the moment you stop editing (technically, once the attachment is no longer selected).
We fixed a bug that prevented you from being able to resize objects to be larger than 10m.
We fixed a bug that prevented resizer scripts from being able to resize objects below 0.01m. (It was possible to resize below 0.01m by dragging the object directly, but not when using a script.)
We’ll contribute these bug fixes to OpenSim, where relevant (Mantis 4905 already contains the bug fix for one of the attachment bugs; it just hasn’t been accepted into OpenSim yet).
How to Use Multiple Attributes in Kitely Market
In Kitely Market, merchants use Attributes to help people find their products. For example, a merchant might assign the attribute “Color: Blue” to a dress, so that when people search for blue items they will see that dress.
We allow merchants to assign multiple values to the same attribute. However, this capability should only be used when those values are equally dominant. For example, suppose the blue dress also contains yellow polka dots: it should still have only the Blue attribute, but not the Yellow attribute. That’s because when people search for yellow items they want to see items that are mostly yellow; not items that are mostly some other color (blue).
All of this was background; now we’ll describe the change that we’ve made. In order to make it easier for people to find the items they want, when searching for an attribute type we now show items that have only one attribute value of that type before items that have multiple attribute values. For example, if you search for Blue items then we’ll show the search results in the following order:
- Items that have only one color: blue.
- Items that have two colors, one of which is blue.
- Items that have three or more colors, one of which is blue.
This helps you when you’re looking for blue items because it makes the “bluest” items appear first.
Note that this change only affects the use of multiple values for a single attribute type, such as Color. This doesn’t affect the use of multiple attribute types for the product, such as Color, Theme, Movement, etc. It’s perfectly valid to assign as many different attributes types to the product as are relevant for it.
In addition, this change doesn’t affect search results where the attribute with multiple values isn’t one of the search criteria. In other words, if you’re not filtering items using their color then the number of colors that the item has doesn’t affect where it appears in the search results.
So, given all of this, should multiple attribute values ever be used? Yes, there are still some valid use cases. One valid use of two Color values would be for items that have colors that are both equally dominant, e.g. a blue and yellow striped shirt. This way the item will be included in search results for both Blue items and Yellow items. However, it will appear after items that have only one of these colors.
Another good use of multiple attribute values is for Bundles. If you create a bundle that contains several colors then it makes sense to assign many different Color attributes to it. But what about the problem that the bundle will appear lower in the search results? Our recommended solution is that in addition to the bundle, you also create one variation for each individual item. Each of these variations will have only one Color attribute, corresponding to the item’s color, and a picture that shows the item in that color. These single-color variations serve to promote the product: people are more likely to click on them than on the bundle variation because they show up higher in the search results (because they have only one color), and they have a picture that shows the product in exactly the color that the buyer is searching for. Once the buyer has clicked on the product they will be able to see that you also offer a bundle variation, and may choose to buy the bundle instead of just one color.
Other Kitely Market Improvements
We added a few attributes that our users have requested. These attributes can be used to better describe products in the market:
- Colors: Gold, Silver, Bronze
- Movement: Rigged
We’ve made it easier to find products using text search: when you search for a word that appears in a category or attribute we’ll automatically show products that belong to that category or attribute. (Previously it was necessary to click on the actual category or attribute link on the left side of the screen.) For example, if you search for the word “blue” then you’ll see all blue-colored products, even if the word “blue” doesn’t appear in their description (as long as the merchant has set the “Color: Blue” attribute on the product).
We’ve made a few improvements to the way we show errors when adding items to a product (if any errors are found, that is…). First, we now show different icons for Errors and Warnings. Second, when searching for asset UUIDs in scripts and notecards we now ignore comments: any UUID that appears after the characters “//” is ignored. Third, when showing warnings in scripts we specify the line number where the warning was found. And finally, we no longer show warnings for the standard textures that are built into viewers, such as the Invisiprim texture (e97cf410-8e61-7005-ec06-629eba4cd1fb).
We fixed a bug with the way we handle the Modify permission. Previously, if an object contained any No-Copy, No-Transfer or No-Modify items then we made the object itself also No-Copy, No-Transfer or No-Modify. But this behavior was only correct for the Copy and Transfer permissions, and not Modify, because it should be possible for Modify objects to contain No-Modify items. So now we allow that.
We don’t allow Demo items to be exported, even if the demo belongs to a product that can normally be exported. (Demo items are created when you click “Try demo” in the shopping cart. Demos are only available if the merchant has created a demo version of the product.)
Other Improvements
We added a checkbox in the Settings page that allows you to disable all the animations in the Kitely site, in case you prefer a more static user experience.
We added a checkbox in the Settings page that controls whether to send emails when you receive an Offline IM, and we made this setting On by default. Previously this setting was Off by default, and could only be changed in the viewer, so most people never enabled it and therefore they didn’t know when they received Offline IMs.
