Hi! If I'm writing a custom method and exporting it as subnet to "$HOUDINI_USER_PREF_DIR/apexgraph/mySubnet.bgeo" I can reuse it
in other snippets simply with graph.addNode('mySubnet','mySubnetNodeName') which is great (besides giving Houdini a restart every time I export a new subnet)!

1. my rig only works on other machines if this specific apexgraph-folder + the specific subnet.bgeo exists. Is this something I can expect to change in the future?

2. I've tried using a Rigscript rather then a RigComponent which has one more input/output + i can see the rig-node-tree by switching to Rig-Script in the visualizer. I can also see all my promoted parameters. How would I connect (in code) the out-port from Snippet1 (holding the parameter) to Snippet2?

3. It would be awesome to also define some alias for methods to pass over to other snippets so that you don't have to export them if you'd like to use them in other snippets.


Thank you so much! Apex rocks!

Example

Hi, if you have the apexgraph folder in your hip dir it will also pick it up. might be easier if you want to share the file to have your subgraphs there.

That would be awesome William if you could have a look at my mess. Please don't judge me on the code. It's far beyond what I'd call clean and coming from cpp I'm not very pythonic camelCase yay! Anyway ...
1. You will find 2 RigScripts "add_twist_stretch_logic" is supposed to grab the given joint structure with pre-added twist-joints (because they need to be part of the skincluster) and calculate twist and stretch (which you can shape with 2 ramps) If you change the amount of twist joints in the RigVop (in the skeleton-node-stream) above you can use as much twist-joints as you need. But you would also have to manually change that in the RigScript-parameters (I'm planning to automate this later with a dictionary that will hold all needed infos)
2. The second node "add_mid_bend_ctrls" is VERY wip. As you will see right away it's kit-bash-ed from follow path node from the spider-example I'm currently learning so much from it by reverse-engineering the code. The Spline-Curve and its controls are already following along with the top/bottom-ctrls and the sub controls will "shape" the twist-joints later (I'm not there yet)

As I wrote in my post above, I'd like to reduce redundancy by promoting the tag-names and some other variables like "twistJntCount" AND if possible also methods (like "buildLookAtParent") from the first snippet to the second. But I don't know how to.

Again ... Thank you so much!

This is exactly why we have the guidesource. You can store extra data on the guide skeleton and use it in your components.
Just remember to keep the guideskeleton up to date, as you add more controls you would want to save those new joints to the guides.
For that you will have to update the guideskeleton using the updateCharacterElements.
Here's a couple of options:

1- You can set the twist count as a detail attrib on the geo and then simply read the data from the
guides when you need it using detailAttribValue().

2- you can manipulate the rigscript using a apexscript node, I have added an example of connecting the subnets in the hip file.

Thank you so much, William. I'll report later if I could adapt/follow your changes. This forum is amazing. It's so supportive compared to others.

Wow William. I'd never expected such a well documented and clean how-to-file. You've spent so much time on it, I feel a bit of bad now cos I can't buy you a beer or a tea. Thanks so much. On another prototype I was thinking on how to create an Auto-Rigger conceptually and was starting by adding a couple of dictionaries to the point 0 in the guide-skel-stream that its only role would be acting as a "global rig dictionary" for the first build-process (and maybe later too) if you will. So my intuition on that was right, but having now a clean example on how to read this out + promoting/porting variables over to other snippets speeds up the learning process by a lot.