[opensource-dev] Adding Neck and Root Attachment Points
In the interest of seeing how feasible adding "mNeck" and "mRoot" attachment points to the official LL viewer would be, it turns out that it's as simple as adding the joint names to the avatar_lad.xml file. It's been known for a while that modifying the file can give you more attachment points (for you and others with the same mod only), but the what I didn't know is adding entries for mNeck and mRoot will give the viewer fully functioning Neck and Root attachments, which are the two bones which previously had no attachment slots. Nyx Linden has expressed off the record that he will see a Neck attachment added to the viewer if a patch is submitted, which I'd assume would include the XML change, and updates to the menus. I was told I should bring this up on the list in hopes to give it some attention. I think it's possibly a rather easy thing to add, although it's beyond my own ability. https://jira.secondlife.com/browse/VWR-26120 ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
Yes, although the catch here is that there simply isn't a Neck slot or a Root slot, so the fact that we can attach multiple objects to any given slot is irrelevant; those two slots have yet to be created. Neck and Root here are unique locations that aren't simply a duplicate slot of something we have now. > Haven't we had the ability to put multiple attachments on any given > attachment point for nearly a year now? I think there's a max per avatar > (32), but once you've got an attachment on a particular point, select the > next one you want to add and choose either Add or Add To from the context > menu. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
That's a very common belief, and possibly why the neck attachment has been missing for so long. But it's not the case: The neck is it's own bone as is the "root" bone; as anyone who has created an SL animation can tell you. :)Here's a youtube video to explain my case: It shows the new Neck and Root attachments being used, after I added this snipit of code: http://www.youtube.com/watch?v=Off7WNlfS3s This is not something that is possibly simply by using an attachment we already have, they are the missing bones. https://jira.secondlife.com/browse/VWR-26120 > True, though the neck is in a fixed location in relation to the chest and > spine. Adding neck-worn items has worked pretty consistently well using > those points.___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
You get this string when right clicking an object in your inventory, and choosing "Attach To" the new attachments added to the XML show up at the bottom of the list (They're actually sorted by ID number, I believe) as "MissingString(Name)" There are a few places the new attachments will need to appear in menus, and verified the strings are coming in:-In the the "Attach To" sub-menu when right clicking an inventory object-In the "Take Off" sub-menu when right clicking your own avatar mesh-In the "Attach" sub-menu when right clicking an in-world rezzed object-New checkboxes are needed when making a V2 outfit. > When you write in the jira that "these missing strings comes in> as" -- > where or how do you get that message? I could change the> code if only I knew > where to look. >> Functionality wise, an XML addition is all that's needed, although the >> >> viewer would need some strings added or they come up as MissingString on >> >> some of the menus, and I think those are hardcoded. Maybe. (There's also >> >> the LSL back end needing some new constant names if scripts are to be able >> >> to use them properly, but I'd assume that would be on Nyx Linden's >> end.)>> Should I go and add it? (If so, how) >>> Add this to the agenda for the next Viewer Evolution meeting. If all>>> it >>> takes is a change to the xml file and there are no repercussions>>> from >>> doing so it should be taken in. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
The official name for the joint is "mRoot" so I suppose "Root" is the most logical thing to name it.And yes, it should auto-fill in the menus, if "id" and "pie_slice" have the correct values. I'm not sure how they work. The ones I provided certainly aren't correct.Additionally, the position and rotation offsets... I left at zero. The real attachments use a bit of offset for position, so small objects don't appear inside the avatar when first worn. > I have altered the xml file you wrote about and added 2 entries to > strings.xml and am compiling a viewer to test this. > > Can you think of a more descriptive name than "Bounding Box"? A > regular user would not know what that means. > > I'll be back later today to test these changes (hopefully the menus > auto-update from the xml file). ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
Perhaps; although the thing with the mRoot joint is that it never moves in relation to the avatar, so it won't actually be positioned on the center of their body. (People will use it for worn vehicles, props, dance poles) But if that's not to confusing, I say go with it. > For non-technical people would "Body Center" make sense? Root makes > it sound like a plant. :) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Adding Neck and Root Attachment Points
Well, there it is. Maybe it should be called Prop. But whatever works. Name is an afterthought to function. :) > Perhaps; although the thing with the mRoot joint is that it never moves in > relation to the avatar, so it won't actually be positioned on the center of > their body. (People will use it for worn vehicles, props, dance poles)> But > if that's not to confusing, I say go with it.>>> For non-technical people > would "Body Center" make sense? Root makes>> it sound like a plant. :) > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] llGetGeometricCenter
llRezObject will rez an object with the center of the to-be-rezzed object's bounding box at the position specified. llRezAtRoot will rez the object with it's root prim's center at the position specified. You won't see a difference unless the object to be rezzed has a center of bounding box that is different from the center of it's root prim, i.e., rezzing a linked object.___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] space navigator 3d on linux with viewer 3?
For what it's worth, I can also say it works fine for me on all current V3 branches on Vista. Adeon ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Anim format files upload
I strongly support this patch; the internal animation format can do many unique
animation tricks that the bvh cannot; including:
-Different animation priorities per-joint
-Keyframed animation control of eyes!
-Variable length joint offsets per frame (allowing cartoon-like "stretchy"
bones)
-Keyframed rotation and repositioning of attachments (which meshes can weight
to; to use as new child bones :) )
-ClientSide scaling of attachments and default mesh
Just to name a few.
-Adeon Writer
On Jan 16, 2012, at 8:50 PM, Laurent Rathle wrote:
>
> Hello,
>
> Is it possible to add the following patch :
>
> In indra/newview/llviewermenufile.cpp. Locate the function
> upload_new_resource, and circa line 800 (search for
> DoNotSupportBulkAnimationUpload ) after the following code:
>
>else if (exten == "bvh")
>{
>error_message = llformat("We do not currently support bulk
> upload of animation files\n");
>upload_error(error_message, "DoNotSupportBulkAnimationUpload",
> filename, args);
>return;
>}
> add the following:
>
>else if (exten == "anim")
>{
>asset_type = LLAssetType::AT_ANIMATION;
>filename = src_filename;
>}
>
> as seen on this web page :
>
> http://blog.machinimatrix.org/avastar/avastar-anim-format/
>
> Should I open a Jira as feature request for this ?
>
> Thank you
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Viewer Policy Changes
I'm pretty sure RLV doesn't modify the shared experience. Any feature of it that others can see will observe it in the same way as the official viewer. Perhaps I am interpreting this incorrectly? This rule will avoid thing like the original double attachments that main viewer saw incorrectly, or that OTR chat encryption thing. It wouldn't disallow derendering, since others on TPV's and others on official see it the same way (ie, they both see nothing happen at all and it doesn't violate privacy) Basically, as an official viewer user, "Don't invade my privacy, don't make me see the world incorrectly." Correct me if wrong. On Feb 25, 2012, at 11:56 AM, Skye Menjou wrote: > What I am worrying about is that this will also go against RLV, which is in > wide use, even outside the Adult community.(We use it for some of our combat > systems). > LL, are you really trying to force people to use your client and piss off > most of SL userbase? I haven't seen such a terrible move since M Linden was > in charge. > > On Sat, Feb 25, 2012 at 1:08 PM, Tillie Ariantho wrote: > Hello Oskar, > > > 2.k You must not provide any feature that alters the shared experience of > > the virtual world in > > any way not provided by or accessible to users of the latest released > > Linden Lab viewer. > > Ah hm... > > - What about text based viewers? > - What about viewers on mobile devices? > - What about special viewers for disabled people, that may have quite some > different representation of everything? > > Or someone's just trying to connect a C64 virtual machine based viewer to SL, > with its own, quite unique representation. What about that? > > The "shared experience" of all those is quite different from the LL viewer. > > And more: > > - What about the shared experience of very old LL viewers? Not allowed to > copy/clone if its not in the "latest released Linden Lab viewer"? > - What about LL viewers in DEV or BETA status? Have TPV devs to wait till a > feature is officially out? > > Is there any grace period till the new policy is enforced? What about grace > periods on client changes later, LL client removes something, > do TPV devs have to remove it instantly, too (dont say now there is nothing > being removed, I remember Avatar Ratings, for example). > > Tillie > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > > -- > Have a nice day, > Skye Menjou > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] data_online's new requirements
I've heard DATA_ONLINE will now only work for "the owner or the creator" of the script. Shouldn't that be instead "owner or compiler" of the script? Any full permission script already written could be used and recoded as a status finder, and I have a feeling this will be what people move to for stalking if it goes by script creator.___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Firestorm has a decent writeup on their Wiki on how to use theirs: http://wiki.phoenixviewer.com/animation_overrider I don't know the inner workings of how it does what it does, but I do know it is still merely overriding the default animations, rather than simply replacing them entirely (as I suppose you guys at LL could do, server and all...) On Apr 10, 2012, at 9:01 AM, "Oz Linden (Scott Lawrence)" wrote: > I'd like to get a tutorial on how the AOs built into viewers work - what > inputs do they use, and how do they set the animations they set. > > Would someone who's got deep know-how on this either write up one for me > (or point me to one if it exists), or make some time to go over it with > me interactively? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Wouldn't a new inventory item type make most sense? That way it could be put in with any outfit folder or packaged with sold avatars. On Apr 12, 2012, at 10:42 PM, Tateru Nino wrote: > > > On 13/04/2012 11:30 AM, Argent Stonecutter wrote: >> The overhead of a conservative scripted AO is pretty low, and the ability to >> switch AOs by wearing an asset (attaching the AO HUD) means that I can have >> appropriate AOs for each of my avatars and outfits without having to tweak >> my client settings each time I jump from kangaroo to grasshopper to dolphin >> to ferret... > Absolutely - if we were talking client or server-side AOs, they'd have > to be linked to outfits or wearables somehow to maintain parity with > common use-cases. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Adding entirely new "slots" to AO's (running against a wall, standing on a ledge, running at various inclines, swimming in system water) is one of the things you can only do do programmatically. But a base "animation replacer" client AO to get rid of the official animations is still handy. A script can just handle all the extra, where it's actually necessary. On Apr 13, 2012, at 10:14 AM, Stickman wrote: >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. > > I've written scripted AOs, and while I'm not familiar with the > clientside AOs, I know that a scripted AO is significantly more > powerful than a clientside AO on one very important point: > > A scripted AO can be quickly and easy be changed. Features can be > added or removed. Say someone has the bright idea to add extra > "one-shot" animations, such as a stumble to break up a repetitive > running cycle, it can be added without much fuss. While a clientside > AO built into the viewer, unless built in a way to support it, > couldn't do such a thing. > > More support for a clientside AO wouldn't be a bad thing. But it > couldn't, and probably shouldn't completely replace scripted AO. > > Stickman > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Alright, here's some features that, if missing, *someone* would complain: -Any given AO needs to be able to have multiple stand, sit, and groundsit animations. Stands needs a choice of either playing them sequentially, randomly, or on a set timer. For sits, people want choices of which sit of many to use so they can switch between them while sitting. In both cases, the amount of animations you can put on one slot shouldn't be capped. It would actually be going the extra mile to let ANY slot have multiple on a choice/sequential/random/timer, if it can be done without over complicating the UI. (by the way, the "slots" I am referring to are all of the possible return values from llGetAnimation, plus some extras like typing animation) -Secondly, an easy way to turn the whole thing on or off (without taking it off) is needed, AND a way to just turn the sit override on it off but keep the rest on The most common AO is the ZHAO-II AO HUD, it's open-source and is usually the standard as far as features go. As far as new features go, I would look into all of the system animations an avatar can do, and consider allowing them to be replaced too. (Example, the shout, chat, away, and voice animations are not always included features of AO's, but they make great candidates.) -Adeon - On Apr 13, 2012, at 12:16 PM, "Oz Linden (Scott Lawrence)" wrote: > On 2012-04-12 17:50 , glen wrote: >> On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >>> Thankfully the previously bad aos are not so bad now. If a client side >>> AO cannot perform what Oracul and/or Vista AOs do then it is a total >>> waste of time to bother with the client side code. In order to do >>> client side AOs requires AO expertise. Period. Don't even bother if >>> you don't have it. Because it will be a waste and people will still >>> use AOs. >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. >> > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Alright, here's some features that, if missing, *someone* would complain: -Any given AO needs to be able to have multiple stand, sit, and groundsit animations. Stands needs a choice of either playing them sequentially, randomly, or on a set timer. For sits, people want choices of which sit of many to use so they can switch between them while sitting. In both cases, the amount of animations you can put on one slot shouldn't be capped. It would actually be going the extra mile to let ANY slot have multiple on a choice/sequential/random/timer, if it can be done without over complicating the UI. (by the way, the "slots" I am referring to are all of the possible return values from llGetAnimation, plus some extras like typing animation) -Secondly, an easy way to turn the whole thing on or off (without taking it off) is needed, AND a way to just turn the sit override on it off but keep the rest on The most common AO is the ZHAO-II AO HUD, it's open-source and is usually the standard as far as features go. As far as new features go, I would look into all of the system animations an avatar can do, and consider allowing them to be replaced too. (Example, the shout, chat, away, and voice animations are not always included features of AO's, but they make great candidates.) -Adeon On Apr 13, 2012, at 12:16 PM, "Oz Linden (Scott Lawrence)" wrote: > On 2012-04-12 17:50 , glen wrote: >> On Thu, 2012-04-12 at 14:09 -0700, Ann Otoole wrote: >>> Thankfully the previously bad aos are not so bad now. If a client side >>> AO cannot perform what Oracul and/or Vista AOs do then it is a total >>> waste of time to bother with the client side code. In order to do >>> client side AOs requires AO expertise. Period. Don't even bother if >>> you don't have it. Because it will be a waste and people will still >>> use AOs. >> Agree. I'm one of the ones who's written a scripted AO. I tried the >> client-side AO in Firestorm and went back to my own because of the >> feature set. A server-side AO would like be even worse. >> > > Ok... so those are nice opinions to have, but you're not succeeding in > educating me... what is it that makes these better or worse? > > What do they do or not do that differentiates one from another? > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Tutorial needed on TPV viewer-side AOs
Are the non-AO default animations actually transmitted by the viewer? Or does each client already know which animation state the avie is in, and animate them with the correct default animation appropriately? If the entire AO set was something broadcasted to everyone in advance, it would cut down on all the start/stop animation traffic and be truely clientside for everyone. The downside is the newer viewer would be necessary to see official AO's. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Talk/shout circles on minimap, lost in the cracks?
Er... Just color the dots based on talk/shout/toofar? ;) -Adeon On May 9, 2012, at 9:11 AM, Ricky wrote: > Correct, but most often a thick horizontal plane centered on your avatar's > altitude is considered the most critical area. This volume is supposed to be > indicated by the dots being round instead of triangular, thus giving the > vertical filtering while the circles give the horizontal. I admit that just > changing the shape of the dots is most likely not enough - if they changed > brightness, and maybe hue or alpha, as well it would be clearer who's in the > same thick plane. > > I say "supposed to be indicated by" because of the now well-known issues with > resolving coarse altitude differences above about 1km... > > Ricky > Cron Stardust > > On Wed, May 9, 2012 at 5:19 AM, Zai Lynch > wrote: > Well, I don't know either about these circles. I only read about them in this > thread, though it seems they're supposed to indicate if someone is in chat > range or not. Though a circle won't indicate that, since SL is 3 dimensional. > If someone appears to be in chat range on the mini map, they might not be, as > chat range is a sphere, not a circle. > > > > On Wed, May 9, 2012 at 2:09 PM, Lance Corrimal > wrote: > Am Dienstag, 8. Mai 2012, 12:27:40 schrieb Oz Linden: > > > No... the user experience folks decided that the minimap was confusing > > enough and that the circles made it worse. > > says a lot about those folks ;) > > > As punishment, we assigned it to them to find a better solution :-) > > I like the sound of that. > > That being said, has anyone ever seen a member of the user experience team > inworld? > > > bye, > LC > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > > > -- > @ZaiLynch > > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Formal Animation Set Replacer
A few months back there seemed to be interest on this mailing list in a formal way to have custom animation sets for avatars without LSL scripts (Animation Overriders) The last I heard there were inquiries on how TPV's were pulling it off (fully client-controlled isn't the most ideal implementation in my opinion, but it works) but after that the mesh deformer seemed to take center stage. Was there any result to the discussion? Is Linden Lab interested in a feature similar in function to TPV client AO's? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
