Mo Noel

What you always can do is what was always done to overpower bad priority design: use priority 6 use a real short loop stop and restart and stop and restart your animation again and again in shortest time hope that your AO will manage to be faster then all others trying the same This thread is not about how to do that. This thread is about how to do it with a sense for needs, resources and reliability. This thread is not about competition, but about cooperation. PS: I do offer a Bento gag AO, and its designed to be extreme low on lag & resources, like memory, while being reliable. I do know, how things can be done.

I would like to create a listing of Bento Mesh heads and the priority of their facial expressions, mainly to compose a list of mesh heads that are compatible to products that need to animate the head / face as well. I came across this topic as it seems various head makers use various policies about priorities for facial expressions. Some even seem to use priority 6 for simple background animations, thus making it impossible to override anything by 3rd party. Background Info: I am Mo Noel from MoDesign. Some of my product (as many products from other creators) use facial expressions to give a proper visual picture of the product in use. For example if you put a gag in ones mouth, the mouth eventually should stay open. Before the mesh heads era, this could be achieved by standard SL expressions, like „express_open_mouth“. The options where limited, but they worked reliable. Most mesh head brands do not support these standard expressions. Actually there is no brand I know that does scan the avatar animations for standard SL facial expressions and transform them to the corresponding mesh head expression. This renders the head incompatible to many products that animate the standard face. For basic animations, there is a reference about what priorities should be used for what kind of animations. It goes about like this: Priority 0 Used for many of the internal animations which are intended to be overridden with an AO. Priority 1 Used for internal emotes. Priority 2 Priority 2 is a good choice for stands in AOs. Priority 3 poses while moving (e.g. a walk) or that should override regular standing poses (like kneeling, a hug or standing with a handbag), but usually walks, dances, sits and most other animations that want to override standing poses Priority 4 enforced 1 (lower body) restricted walks, to overpower restricted stands this could be a walk in leg cuffs or humple walk when loosing a shoe Priority 5 enforced 2 (upper body) this could be enforced poses that need to override enforced walks like handcuffs, that should override the upper body even while walking in leg irons, as a leg iron walk also would animate the arms. Also a neck corset should be priority 5. Priority 6 anything that is even more restricting then priority 5 and we forgot to think about this could be special furniture things, for example, where a body might be folded as tiny as possible to hide it, e.g. to simulate a magic trick (Yes, some AO makers violate these rules, with the effect that A others do as well or B items don't work as expected) Example: Handcuffs and leg irons: 1. Avatar is standing: Prio 0: SL standing animation Prio 1: - Prio 2: standing animation of the AO Prio 3: - Prio 4: standing with restricted legs Prio 5: standing with restricted arms 2. Avatar is walking - same animations but * animations added Prio 0: SL standing animation Prio 1: - Prio 2: standing animation of the AO Prio 3: * walking animation of the AO -> overriding any stands Prio 4: standing with restricted legs Prio 4: *walking with restricted legs overriding the previously active prio 4 stand Prio 5: standing with restricted arms -> still overriding the arms of the restricted walk 1. Avatar is standing again - same animations, but the * animations from above stop: Prio 0: SL standing animation Prio 1: - Prio 2: standing animation of the AO -> takes over from the prio 3 walk Prio 3: - Prio 4: standing with restricted legs -> takes over from the prio 4 walk, still overrides Priority 2 stand Prio 5: standing with restricted arms -> still overrides loose arms of Prio 4 stand For a head, we need something similar. As there is no SL preset overriding face expressions by Bento animations, we could use the full range of the 6 priority levels. As a first sketch, the following "Mo-Rule" could be an idea to discuss: Priority 0 used for minor 3rd party animations or things that really don't matter and should be overpowered by standard face animation Priority 1 used for standard animations/emotes to keep the head alive while no one else is doing something Priority 2 Animations that override standard emotings, this could be smiles talking head whistle smoking etc. Priority 3 same as Priority 2, but for 3rd party items Priority 4 enforced 1 special effect animations e.g. avatar gets electroshocked Priority 5 enforced 2 real physical enforcements open mouth by a gag closed eyes by glue, death or something (e.g. a zombie avatar or a ghost) open eyes, hold open by matches etc. Priority 6 anything that is even more restricting then priority 5 and we forgot to think about (yes, some really may say this comes a tad late, but better late, then never.) (and yes, similar set of rules would be great for hands and feet and tails and ears …)

I am on a Mac Pro Firestorm 4.4 (2 years old viewer) & 4.6 (latest viewer): When staring on a static scenery: 10 to 13 FPS When meeting some other people about 2 FPS or below With the latest viewers I just cant chat, as any key pressed freezes keys and mouse of the computer for 0.5 to 4 seconds. (see also: http://community.secondlife.com/t5/Second-Life-Viewer/Does-LL-have-any-intention-of-fixing-the-COCOA-bug-that-affects/m-p/2896878#M25431 )

Nalates Urriah wrote: There is a fix. I thought it had gone out. I remember that it is an Apple problem that affects not just the viewer but other Mac programs too. It happens when the Mac is running out of memory. So, it isn't something the Lab would fix. They are always working to fix memory leaks and those fixes will help. Apparently FS found a work-around fix and the Lab adopted it. You can follow what the Lab is doing by following Inara Pey's or my blogs. Running out of memory has nothing to do with it. I am on Mavericks, as secure Email is not yet availale on Yosemit (pgp) and people report other issues as well. I have the dearest typing lag you can imagine, even when alone in a skybox. Waiting on a frozen, quite expensive MacBook Pro for letters to appear on the screen, one per 4 seconds is no fun at all. I did upgrade my Mac to 16 GB memoy, as there was rumor of LL, that this would help. It did cost me a fortune. No Help at all, though. I have 3.3 GB Memory available right now, and I cant even type IM even when anlone in a skybox, with draw distance to 32 meters (no way to get it lower). FS did not find a workaround, as FS is still heavy affected as well (I am on FS, actually). The only FS workaround is, to use a 2 year old viewer. But then you should not meet people that wear attachments that are based on liquid mesh, as you will go crazy by artefacts flashing all over your screen. Here is the FS jira about it: http://jira.phoenixviewer.com/browse/FIRE-12172 The only fair thing to do would be either to process typing separate from graphics (and that rather quick), or to just be honest and say: Mac not supported. As this bug is 2 years now, and there seems to be no actual attempt to act about it. I call that not-support, in other words, you don't support Mac, so just be honest and name that. You already said, its not something the Lab would fix.

Hi. I am experiencing some severe issues with items that communicate by http. I have in world items that request a secure URL. At present, it seems that now and then one of these granted URLs become invalid. When you try to adress that item, you get the standard failure message about cap not found, even when it was working fine just some minutes ago. Is anybody experiencing something similar? (Of course I do request a new URL after sim reboot. It seems the URL gets invalid just out of nowwhere)

Kayla Whittaker wrote: Same here with me... It is driving me nuts. The dev-team just told me the bug shoudl be fixed. However, it is not.

Marcus Hancroft wrote: Good mornin, Miss Mo Are you getting some kind of error message when you try to activate them? I can't tell from your description exactly what is going on. Could you provide us with some more information, please? What is happening when you try to activate them? Which bug? I cannot activate. Its grayed out. I do not get any error message when I edit the listing. Its the bug where the items affected are only listed in the "All" tab, not in the other tabs.

LillyBeth Filth wrote: Okay so... The reason why I have 350+ products unpublished on the Marketplace is because of the information provided by Support staff below. At least I know and am not sat at the PC tearing my hair out trying to "Activate" listings that won't allow me to or edit listings that are shown as DD but refuse to update and go live! From Support Staff The items actually got listed during testing by the Dev Team. There is an issue with some listings where if they have an SLurl that is entered the system may see the SLurl as invalid and display a not very helpful error message. The products that were on your Unlisted section that had already been migrated to Direct Delivery were affected by that issue. The Dev Team wiped out the SLurls on those listings and were able to activate them after the SLurls were removed. Items that show as being migrated to Direct Delivery but showing under the All section and not the Unlisted section are affected by another issue that the Dev Team is currently working to resolve. My only suggestion for the item that you were able to re-upload is to check to see if there is an SLurl entered on the listing and if so, remove it. After removing the SLurl and updating the listing, locate the entry for the item on your Manage Listings page and click the greyed out check mark to see if the listing will become active. If it does not, then it will be necessary to wait for the Dev Team to complete their fix and get it released to the web site. They are working to get the issue resolved as quickly as possible. WOW you already got way better support then me. I was fined to ask them. I did file a jira at April, about 2 weeks after I reported that bug. The jira states the issue is resolved since

I just migrated an other bunch of products that still had been linked to the magic box. Guess what. 100% of these products suffer now that bug, that they cannot be activated. I did ask support for help, before - no avail. I did file a bug report. The bug report is resolved now - the bug is not. I have >10% of all of my products rendered unsell-able, as I cannot activate them. Some of them are not active for more then a month now. The only really action I experienced form Linden side was, that I was fined L$ 999, because the migration process rendered one listing as doublette, which is against TOS, and of course the customer needs to be punished, if the own software system is acting up - at least, when the customer dares to ask for help and support, or even dares to report an issue. Sorry, guys, but I really feel P***ED. I want the very well working magic box back. :(((((((((((((((((

Czari Zenovka wrote: Mo Noel wrote: Czari Zenovka wrote: Mo Noel wrote: Czari Zenovka wrote: Pamela Galli wrote: Yes Czari; you would just replace the box. I do like not having to go to a MB inworld to do that, tho I do not like having to find the newly uploaded item and manually associate it. Thanks, Pamela. Czari, replacing the box only works with magic box. it does not work with Direct Delivery folders. If you just upload a new folder, nothing really will happen - only that if you check your uploaded folders, Markeplace will show you a conflict, if you dig for it. I'm keeping my items packaged in boxes which is one of the DD options ie. upload boxes with the item or put the items in a folder. I never had any automated anything so that is a moot issue for me. Still, same process. Just uploading a new box (which is a new folder with but one item) will not replace the item that gets delivered. You need to follow the steps I have described. I realize that. I wasn't referring to the steps. Darrius Gothly and other regular posters on the Merchants Forums have posted very helpful guides beginning a year ago. I really wonder, why not enough people opposed to that clunky, time consuming process, that is so prone for errors and full of bugs and replaces an smooth working process, that could be processed 100% automatic by in world tools. I was hoping that LL would not break existing content, but they ignored my comments, obviously

file a jiira mark it as "Severe" or "Showstopper" and state, that its "breaking existing content" Suggest as a possible solution to allow the usage of Magic Boxes

Kaydence Rodeyn wrote: What I've started doing is deleting those inactive items one by one, reloading them to the MP, and recreating the listings. Time-consuming, pain in the rear but it's the only way I've found to get those popular items active again. Just don't tell that support - they won't support you, they will fine you.

Czari Zenovka wrote: Mo Noel wrote: Czari Zenovka wrote: Pamela Galli wrote: Yes Czari; you would just replace the box. I do like not having to go to a MB inworld to do that, tho I do not like having to find the newly uploaded item and manually associate it. Thanks, Pamela. Czari, replacing the box only works with magic box. it does not work with Direct Delivery folders. If you just upload a new folder, nothing really will happen - only that if you check your uploaded folders, Markeplace will show you a conflict, if you dig for it. I'm keeping my items packaged in boxes which is one of the DD options ie. upload boxes with the item or put the items in a folder. I never had any automated anything so that is a moot issue for me. Still, same process. Just uploading a new box (which is a new folder with but one item) will not replace the item that gets delivered. You need to follow the steps I have described.

Czari Zenovka wrote: Mo Noel wrote: Please vote for this, to make updating as easy as it has been the past 5 years: https://jira.secondlife.com/browse/BUG-2167 The jira won't allow me to access it...due to LL closing public access to jiras last year. I did try, though. ok . how is it supposed to work then? mobilize people to write their own, dublicate jira?

Czari Zenovka wrote: Pamela Galli wrote: Yes Czari; you would just replace the box. I do like not having to go to a MB inworld to do that, tho I do not like having to find the newly uploaded item and manually associate it. Thanks, Pamela. Czari, replacing the box only works with magic box. it does not work with Direct Delivery folders. If you just upload a new folder, nothing really will happen - only that if you check your uploaded folders, Markeplace will show you a conflict, if you dig for it. To update an item with Direct Delivery (e.g. if you want to add or replace a notecard), you have to upload a new folder with allcontents of the product. You have to log in to your merchant page at Marketplace, you have to search for your product listing , you have to change the folder associated, you have to search for the new folder and not to confuse it with other copies, you have to select it, you have to update the listing, you should do a test delivery and check the item delivered, if its really the correct one, you should visit your Marketplace web page, search for the old folder and try to delete it (it may work or not), you should try a second test delivery after that, just to be sure it still works. You should only process one item at a time, the process is prone of loosing track. Expect the web page taking several, up to dozends of seconds of time with every step you make. It may happen, that your product becomes unlistable during that process. If you are lucky, you will be able to set the product to active and list it again, later. At my Marketplace, about 12% of my items cannot be listed any more after migrating and Marketplace customer service fines you, if you come to the idea to fix that by just creating a new listing for the borked one, because that is not allowed. They actually fine you even, when the product gets listed twice because of quirks in the DD-Migration-process and you ask for help. Just to compare with the old process with magic box: A. without automation: edit the magic box, wait for the contents to load, remove the old product-box, (you even can remove complete bunches of boxes at once) add the new product box. (you even can ad complete bunches of boxes at once) done. B: with automation: edit the objet that updates the magic box (and other servers) automatic (no need to wait for loading contents, as the item always is empty, safe for one single script) drop the new box of your product with updated contents into to your object that updates the magic box (and other servers) automatic. (you even can drop complete bunches of boxes at once) done.