Unless I'm misreading the documentation, when an end-user creates a for_<guid>.json for a non-action-menu-ready
avatar, they have basically every freedom with how they actually set up the radial menu, without changing the normal
native AAS menu item names, whereas an avatar maker must alter the names to make the mod work.
The idea is simple enough; provide a unity Component which just stores text (json, in this case) one could place
into an empty game object on the avatar, paste the json into that, use the mod to whitelist it (the mods Limb Grabber,
Eye Movement Fix, and QRCode Reader all take this approach to some degree), and then make the mod proper
just slurp the json out of the, lets call it ActionMenuContainer, component if it exists, then the normal 'check aas
entries for slashes,' 'load user provided json (maybe this should be first so an end-user of an avatar can override
the creator's provided setup)', and finally falling back to the default no-config algo.
Unless I'm misreading the documentation, when an end-user creates a
for_<guid>.jsonfor a non-action-menu-readyavatar, they have basically every freedom with how they actually set up the radial menu, without changing the normal
native AAS menu item names, whereas an avatar maker must alter the names to make the mod work.
The idea is simple enough; provide a unity Component which just stores text (json, in this case) one could place
into an empty game object on the avatar, paste the json into that, use the mod to whitelist it (the mods Limb Grabber,
Eye Movement Fix, and QRCode Reader all take this approach to some degree), and then make the mod proper
just slurp the json out of the, lets call it
ActionMenuContainer, component if it exists, then the normal 'check aasentries for slashes,' 'load user provided json (maybe this should be first so an end-user of an avatar can override
the creator's provided setup)', and finally falling back to the default no-config algo.