Canonical names for new attach points need to be defined

Issue #25 resolved
Alan Glover created an issue

Latest viewers have new attach points at neck and avatar centre. What names will be used for each of these in RLV?

Details: http://modemworld.wordpress.com/2011/11/01/watch-out-your-avatar-is-about-to-get-it-in-the-neck-but-in-a-good-way/

Comments (6)

  1. Marine Kelley repo owner
    • changed status to open

    I was thinking "Neck" and "Root", which are the internal names (my RLV does not define an interface to map internal names and RLV commands, there was never a need).

    Always choose the simplest way !

  2. Former user Account Deleted

    Works for me.

    Comment for scripters reading this - the new attach points are 39 and 40, above the HUD attach points, so any code that cares about whether it's on the HUD or the avatar's body is going to need to start testing for attach point > 38 too

  3. Former user Account Deleted

    Oops - that comment and this are from Chorazin - somehow my signed in status on this site got forgotten

  4. Alan Glover reporter

    The newly released 2.7.4 viewer does support these new attach points however the name for the root in rlv currently apepars to be avatar center.

    There is also some odd behaviour around here too - create an object, name it Object (Avatar Center), wear it and it'll go onto HUD center (probably because that matches first in an ascending search through the attach points).

    After some IM online discussion with Marine, the message for scripters is don't use root/avatar center yet until she's considered which name is best for it and looked at the other points here

  5. Marine Kelley repo owner

    Ok ! After a few tests with "Avatar Center", I can say that... "Root" is much easier to implement. I have tested it with two avatars, including one still on RLV 2.7.4.2 (which names this point as "Avatar Center"), and it works well. Besides, "Root" is a shorter string, which is always better for scripts.

    So, "Neck" and "Root" it is !

    I must move this issue to RLVSPEC by the way, since it is not only an implementation issue, it will be added to the API v2.8 as well.

  6. Log in to comment