Anne Cloud

@Oz Linden Can you help us clear up whether the Premium bonus & Group land bonuses are supposed to stack?

The viewer already allows purchase for one's self using the bonus allotment, but it seems it cannot be allocated to any group.

If the appropriate individuals want to move this thread, they're welcome to, however I'm specifically giving feedback to a Knowledge-base article, which appears to be deficient at this time.

Hi - I'm writing this in response to Which is great on the surface! But i'm noticing I can't apply my bonus to my group, which is basically the only way I use my tier. Was this intentional or is some change in the viewer forthcoming to allow group members to donate any amount up to their full allotment? Neither the blog post nor the knowledge base article covers this from what I can tell. Thanks for any help you can provide.

Additional nitpick: Listing only first name in the Stats area isn't terribly useful. Ideally, if a visitor needs to get in contact with the parcel owner, they will need a full name. Also, I have to wonder whether it would be more useful also if that link just went to the person's profile page for full contact details? I see the link is not visible for pages which are not mine. If i can already access my own pages through the navigation at the top, there is not much reason for that stat link to just go back to my list of places.

Additionally, it looks like the placeholder secondary image does not go away if no secondary image is specified. Is there a way of hiding it? And on the flipside, is there any way of offering more than three secondary images if I want to make use of the Places Page as an intermediary slideshow for services/products offered?

I'll also second the call for some means of listing upcoming events related to specific parcels.

Something like this has been needed for quite a while, particularly since the old Facebook integration is no longer relevant. We've always needed place listings that were less restrictive than the word count and in-world appearance for place listings. Something like this should help flesh out the exploration experience quite a bit. Some initial thoughts: - I see that Place Pages show up only for parcels which are marked to show in search, however marking a region as 'Block Land Show in Search' locks off ALL avatars from changing this setting, rather than only those who are NOT Region Managers and/or Estate Managers/Owners. More granular settings in this regard are required. As the owner of a residential sim, I'd like to be able to publicize the region but prevent tenants from inadvertently setting place settings (or inheriting them from previous tenants' settings). - Is there a reason why place descriptions is limited to 250 characters? Being able to include more flavour and info prior to visiting may be helpful, particularly if there are rules or guidelines for visiting. - An optional field to include Marketplace links would be helpful for those who are browsing, want to know a bit about the store and want to shop but not able to log in right away. - How will Places Pages be integrated (if at all) with Landmarks?

I don't have any problems logging in, either on the main grid or beta (agni) grid with the most recent viewer. Clear, further info would probably help diagnose what the problem you are running up against here. Sometimes logging in to the Beta grid can take a while - logging in to a specific region rather than allowing the grid to use your last known location usually helps a lot, if that's the problem you're experiencing.

I would not consider the position of the mHead bone out of the ordinary in this case, but based on the behaviour I'm seeing, the nametag is hovering somewhere in the snout area. Here's a cleaned up snapshot of mHead as it relates to this avatar:  The av *does* make some use of face bones, but I have omitted them in this shot because based on your reply, they are not relevant.

https://i.gyazo.com/8667e14826ae8934fb29569b98d2136a.gif Anyone else experiencing this behaviour with name-tags & Bento? While this is somewhat cute, positioning of the nametag is not ideal. it doesn't really seem like the tag is rigged to the head, av center or even skull, so is there a way I can avoid this odd placement? it is rather distracting. I would have thought the nametag should maintain position directly below the voice dot, but that doesn't seem to be the case here.

Okay - i think I found the cause and it's Avastar specific: Torso is currently parented to PelvisInv (historically, it has always been parented to COG), so as a result, the entire torso is moving along with any pelvis angle changes.

I have a quick question, but I'm not sure whether the behaviour is intentional and whether it is a product of changes to the skeleton exclusively of whether it is a Blender Avastar problem: It appears that the entire avatar now rotates when PelvisInv or mPelvis are rotated, rather than affecting only the vertices rigged to mPelvis. It used to be that you could rotate PelvisInv or mPelvis to provide slight adjustments in the hip angle for animations, without negatively affecting other bone rotations/positions. Is this change intentional, and if so, 1) what alternatives should people be rigging to and 2) how might this affect older content which did rely upon mPelvis animating only verts around it, rather than acting as a parent for other bones?

I see the most recent hover-height related changes have been pulled in to the Bento viewer (previously having been confined to the Test viewer). I'm going to say it now - the treatment of animations and camera position is undesirable. - Attaching the camera to the z-offset of the avatar introduces significant vertical camera movement for avatars which move up and down (say for example breathing or walking animations for quads) For example: https://i.gyazo.com/61c9a9628a5e0d16fc136382b7a9ed99.gif < i get nauseous looking at this from afar for a few seconds, let alone right up in front of a screen for extended periods. - The change in animation handling is now just pushing the avatar up and down and not handling movement and positions in the hind limbs. Whereas hind feet would rest properly on the ground where they were animated, now they just get pushed in to the ground and do not bend according to the loc/rot set out in the animation.

The voice dot sits above my head. Odd thing is it too moves - but in the opposite direction from the avatar. https://i.gyazo.com/1b8a903bd2db46018f049a3f3323020c.gif

I should note the COG isn't any higher or lower than normal - it's just that some bones are much higher than they would normally be with an average SL human. With that said, it works properly with the most current Bento viewer. I don't know whether this problem is a side-effect of the adjustments Vir made regarding the hover height issue Teager reported or if it is completely separate, but given that both issues involve vertical positioning and it only showed up most recently in the Test viewer, I have a strong feeling that they are related. I've written up a JIRA for this here: https://jira.secondlife.com/browse/BUG-20169

Here is how that standing animation looks in Blender. No changes have been made to it since the animation was uploaded. It is priority 4. https://i.gyazo.com/c596455e31170aac699363cc352663b2.gif

Additionally, the pre-jump stick issue continues to be a problem for animation overrides - particularly in cases where AOs are essential towards the believability of non-standard mesh rigs. (some additional distortion between upper body and pelvis appears to be present in that video, but I have yet to diagnose what is causing the issue.)

Even just standing still normally, not cammed in on anything, I notice marked change: (Edited to fix link: https://i.gyazo.com/263e52ec8b1ead6591067862f4fcde66.gif )

I am experiencing some inconsistency with relation to z-offset in animations between the current most recent Bento build (317134) and Vir's currentTest build (317405). This first graphic shows the expected animation, which can be seen in the Bento build: https://i.gyazo.com/41c6a9c373f3b6f25f3f13d8dc346acf.gif This following graphic shows how the same animation looks seen via the Test build: https://i.gyazo.com/57f39d5965a90f0f0bd07b24f1e2ff7a.gif I am also noticing that, whereas previously the camera would hover at a consistent height above the ground behind the avatar, the camera now bounces up and down *with* the avatar based on the z-offset of the animation. Are these behaviours expected? They are subtle but different and in the latter case, may affect general user usability (possibly causing nausea issues).

Don't get me wrong - If you can make the switch you definitely should. But i'm not even really talking about just eyeblinks here. Say for example if someone makes a steampunky avatar that has multiple interchangable parts, one of which has a door, knob or switch that makes use of alpha switching to flip back and forth? The content creator would be limited not through any fault of their own but by the inherent issues associated with updating rigged, joint offset meshes.

First off, let me say that I've noticed the eyeblink issue relating to texture offsets appears to be fixed from what I can tell (Thanks!). I have not yet tried alpha flipping. With that said, My concern is not specifically focused upon eyeblinks, and here's why: Not everyone will be creating things which have the flexibility of using up human face bones for non-human attachments (my own wyvern case is an example). Additionally, If we point to eyelid bones and say 'you can use those', don't we ignore the issue that creators may wish to use alpha flipping for *any* reason not otherwise handled by Bento bones? Granted, with what I have on my plate right now, I don't currently have something that would test this, however I think it is in our best interests that potential buggy areas be future-proofed as much as possible.

The tail of that bone might well move based on the shape of the avatar, however it is crucial that the head joint of that bone be fixed as per Siddean's suggestion, since anatomically, it is so close to center and it would be unlikely itself to shift much due to shape change. It might not matter much to those of us who do use offsets, but in the situation where doing so negatively affects the face when sliders are used, I can understand why it would be of great importance to ensure an anatomically correct baseline.

I use a full body alpha for pretty much every avatar I make and never run in to this problem, nor have any of my customers. I've also never seen the behaviour you describe with any other avatars, so I have to wonder whether there is some other factor involving your product or your viewing experience? I think at the heart of it, you probably need to figure out why it does this for your products in the first place. Aside from some baking issues I noticed popping up recently with the Bento viewer from last week, nothing comes to mind that would cause your problem. You shouldn't have to work around that issue.

Shouldn't putting an alpha layer on the head remove the appearance of the eyelashes entirely? Since you make full mesh heads, is there a particular reason why you might not be using one?