The control HUDs for Ruth have two major functions: alpha cuts and texture appliers. A single simple protocol controls these actions.

• Channel: multiple channels have been used, the actual channel is calculated based on a constant appID as:

  // Calculate a channel number based on appID and owner UUID
  integer keyapp2chan(integer id) {
      return 0x80000000 | ((integer)("0x" + (string)llGetOwner()) ^ id);
  }

• Messages: The message format is (currently) clear-text in a single string formatted as:

  <command>,<arg-1>,<arg-2>
  TEXTURE,upper|lower,<texture-di>
  ALPHA,<prim-name>,<face>,<alpha>

The protocol is versioned separately from the mesh because scripts may be used with multiple versions of the mesh. Protocol versions are simple numbers, incrementing with each change. Anything before these extensions is considered version 1, ie RC2, and RC3.

The channel number itself is not a part of the versioned protocol as it is not part of the message format being passed between objects. We consider the various appID changes to be part of the overall release prior to now, ie RC2 and RC3 had different appIDs.

Examples

• find and get status
• Query current values from the body
  • body gets the uuid of the HUD in the ENQ message, let the ANS use llRegionSayTo() to reply directly
  • HUD chooses channel number in ENQ
  • reply with specifics or with all?
  • format reply in JSON or CSV?

ENQ|<reply-channel>
STATUS|<alpha-status>|<texture-status>

• Messages: The message format is specific and only has one form:

  [<color-vector>][<natural>][<specular>]
  
  [<0.4, 0.7, 1.0>][1][50]

  (note, the '[]' chars above are literals, not syntax)

  • natural: 0=colored, 1=natural
  • specular: specularity setting
• Extension format:

  COLOR,<target>,<face>,<color>,<natural>,<specular>

With 8 faces per link and 2 states per face to track we should be able to track each link in 8 bits. However, we need to also be able to have a delta to apply differences to enable things like stored alpha states for partial updates. One way or another we need to be able to mask out bits to change or to not change.

For example, we have a single link of 8 faces with a current state of 0x0F (00001111) with a 1 bit representing visible and a 0 bit representing invisible (much like the alpha value in LSL). So faces 1-4 are hidden and faces 5-8 are visible.

Our particular bit-o-mesh uses bits 1 and 2 for fingernails, 3 for hands, 4-8 for wrist through shoulder segments. With the above setting only the wrist, hands and nails are visible to accommodate a sleeve that doesn't quite fit the elbow when certain animations are played. The state of the fingernails is independent from the arm visibility because sometimes a separate mesh is used for the nails. When adding that mesh we want to turn off the built-in nails in our mythical one-piece arm without affecting the rest of the settings required by the sleeve. So we want a result of 0xC0 and only know that bits 1 and 2 should be zero. To do this we need to mask either the bits that do not change or the bits that do change. Either approach is valid, it seems logical to me to mark the bits to change as that lets you extract the current state for the same (in this case fingernails) easily enough.

So here's the math:

Using bitwise operators:

final = (current & !mask) | command

It is even possible to extract sub-states from a saved state