See solution below:

Each node is a Sibling and Each Connector is a Sibling.  So when I run "hideConnOut" it tells all its "outgoing connections" to hide AND tells all its succesors to do the same.

About Siblings (by Karl) 

If you hold down shift while copying with the green halo handle you make a copy.

Almost... What you now have are two sibling players, each of which is a "Player" or "Object" in its own right. (Also copies made by the Player Copy tile are siblings.) Each players wears its own separate Morph as its costume. The siblings are related in that they share certain things in common, in particular: scripts and variable definitions.  So if you add a variable to one sibling, all siblings will have their own instance of that variable with the same name. The same name, but the values can be different. For example if I add a variable called "speed" to one sibling, all siblings will have a variable with that name. But I can have one sibling with speed=5 and another with speed=10. Same variable name different values.

Also if I add a script to one sibling, all siblings will have the same script (and same scripting tiles, if I change it in any sibling at anytime). But although siblings share a script, each sibling has its own private "status" for that script, i.e.remembers separately whether the script as used by this instance is "normal", "paused,", or "ticking", or set to trigger on mouse-up, etc.; and what the tick-rate is.

When using siblings, what's really happening underneath is that there is a custom Player "Class" is created to bear the shared code, and the siblings are individual "Instances" of that class. "Class" and "Instance" are among the most fundamental concepts of object-oriented programming 

So why would you use siblings? Well besides teaching one of the most fundamental concepts of object oriented programming, you could use siblings in a game to make characters that have similar behaviors (aka scripts) but different looks (you can change the looks by either re-drawing the sketch or by setting the Sketch's graphic (if the object is a Sketch or image you copied in) or changing its size and colors.  You could also have ships in a game that keep track of how many times they were hit (using a variable to count the # of hits). That way you can program a basic ship once and make multiple siblings. Then if you decide to change the behavior (ex: modify a script, or add a new variable), you can change it once and all the siblings are changed. 

Siblings could also be used to try to simulate or model real world behavior.  For example deer population or some other animal.  You could create an Object that simulates the behavior of a deer: searches for food, ages, breeds (at a certain age), etc. and make sibling copies of that one object. Then each Sibling (aka individual instance of the Class Deer which you have defined) could age, search for food (and find it or not which could affect its life expectancy), etc at its own rate.  You could also create predators and food that grows. Then run multiple simulations varying the amount of food, starting number of dear, # of predators, etc. 

If the "all instances" box is not checked in AllPlayers, you'll see the scripts for only one player of each sibling group. This will give you "control" over the scripts of only one of the players. If you want to be able to "control" scripts for both of the siblings, make sure the "all 

instances" checkbox is checked.

Unless the "all instances" checkbox is checked, creation of new siblings will typically not result in any noticeable change in the all- scripts tool, since all the scripts of the new sibling will already be represented by another instance in the tool. Perhaps that's what you're seeing. 

Also, if the "tickers only" box is checked, only scripts whose status is "ticking" or "paused' are shown in the all-scripts tool. This can be another reason why the all-scripts tool may seem not to be "picking up" on a change.