Firestorm Bridge Product Specific Code

[Extrude Ragu]

The Firestorm LSL Bridge has code specific to two inworld products as far as I can see - Specifically to ZHAO and OpenCollar.

Since the bridge is designed to 'bridge' between the viewer and LSL, one can assume that these products can do some tricks with the Firestorm viewer that a competing product that was unaware of the functionality could not.

I would like to know what ZHAO and OpenCollar specific functions the viewer has, so that in case I am making something that could take advantage of these functions I am not at a competitive disadvantage and also just to make the best use of the viewers functionality in general.

So I suppose my questions are

1. Are the ZHAO Commands and what the firestorm viewer does with them documented anywhere?
2. Are the OpenCollar Commands and what the firestorm viewer does with them documented anywhere?
3. If not, what can we do to retrieve this information?

[Jenna Huntsman]

The ZHAO and OC (actually, LockMeister) stuff in the bridge I believe gets used to integrate the built-in AO with common AO-contoller protocols. ZHAO has their control protocol, and LockMeister (now part of OpenCollar) has theirs. Both do the same thing (allow external sources, eg. furniture, to switch off or on your AO).

[Coffee Pancake]

It's not really specific products, just that those open source projects established the protocols now widely in use.

ZHAO commands allow an AO to be toggled on/off by a worn attachment, typically this command would be issued by a collar .. perhaps even an open one.

[Quistess Alpha]

You can read the script stored in the bridge. As far as I can tell the only (useful) script-to-viewer messages are "turn on/off your AO" and "register this URL so you can send me commands"

llOwnerSay("<clientAO state="+newstate+">");
// where newstate is one of "off", "on", "standoff", "standon"
llOwnerSay("<bridgeError error=wrongvm>");
// presumably shouts an error message to owner?
llOwnerSay("<bridgeError error=injection>");
// wow, they don't want you adding extra scripts to the bridge :/
llOwnerSay("<bridgeURL>" + gLatestURL + "</bridgeURL><bridgeAuth>3e10ed5d-6796-0b57-5a1c-d5d05450a094</bridgeAuth><bridgeVer>" + BRIDGE_VERSION + "</bridgeVer>");
// self explanitory.
llOwnerSay("<bridgeRequestError/>");
// for if the bridge doesn't get a URL.
llOwnerSay("<bridgeMovelock state=" + (string)gUseMoveLock + ">")
  // this is just a confirmation. the movelock is implemented LSL side. (Which seems dumb, can't the viewer just remap the keys so that movement doesn't get sent to server in the first place?)
 llOwnerSay("<bridgeGetScriptInfo>" + llList2CSV(returnedList) + "</bridgeGetScriptInfo>");
// tell the viewer the results of some complex llGetObjectDetails() calls.
llOwnerSay("<bridgeError error=scriptinfonotfound>");
// if the llObjectDetails calls failed.

from scanning the source. comments are mine.

[Frionil Fang]

30 minutes ago, Quistess Alpha said:

 

llOwnerSay("<bridgeMovelock state=" + (string)gUseMoveLock + ">")
  // this is just a confirmation. the movelock is implemented LSL side. (Which seems dumb, can't the viewer just remap the keys so that movement doesn't get sent to server in the first place?)

 

The primary point of movelock is to stop *others* from moving you, not to stop you from moving yourself, just for what it's worth, and that's probably easier accomplished script-side.

[Anna Salyx]

The bare bones basic is: OC/LM/ZHAO object will try to register with the bridge on attach/rez-attach.   Only one object can be registered so it's whichever activates first if you are wearing multiple items.  It does this by speaking on a specific channel to basically say "hi I'm here". 

The object that successfully registers to the bridge can then toggle the built in Firestorm AO on and off as needed for that object by communicating on the registered channel with the bridge.  I don't use OC or ZHAO, but I have made some personal pose HUDs that I integrated that bit of OC logic into so the HUD gets properly registered and then when I activate a pose, the Firestorm AO is deactivated and doesn't interfere with posing for photos,  and when I turn the pose back off, the AO is turned back on.  it helps me not forget to it manually.