Custom Feature: Cable/Wire Routing

@eric_pesty thanks - I did encounter that recently and fixed it in my test examples - let me look again.

@eric_pesty @Matt_NC I have just pushed an update to fix the stripped end appearing on the same end of the wire - the logic that was there for years had no right to have ever worked, but now it should be fine.

@eric_pesty The "connector requires library update" is a catch-all. In this instance, your WAGO connectors are essentially splices (or daisy-chained connectors with more than one wire attached) which is not currently supported. I did mention it in the video but did not point out that this also includes splices. I am currently working on this, but it is a challenge.

I also fixed the zero length strip value which ended up being a typo in a variable name.

@eric_pesty I also made some adjustments to the Harness layout feature so now you can at least flatten USBIN. The issue there was related to the Wire ref USBBHD having a tiny stub length and a stub offset of zero, therefore leaving a small gap. It works now, but it is better to at least adjust the stub offset to a negative value to ensure the wire touches the back of the connector.

Hi Brian, the "network" feature still exists, but it detects it automatically (if there is more than one route through the "clip", then it's a network). Let me know if it's not working as expected.

For every feature, and sometimes several times per feature, I was calling setAttibute/getAttribute (I store all the data as attributes on the Part Studio origin) to populate an array of a specific data type. What I asked Claude Code (Opus 4.8) to do was to find every instance of setData/getData (my read/write functions) and replace it with a single box[] that could be referenced from anywhere. I had tried to do this manually on several occasions but trying to get the code to even "compile" never mind run was too big a hurdle to overcome. While the performance gains are extremely marginal, it makes it easier for me to debug and extend the features knowing I can get at any data I need at any time.

I also asked Claude to do a general code review and look for potential performance optimisations and it found some loops, especially in manipulator logic, that were processing more data than needed and so suggested some changes which make interactive performance better. I did this all on a copy of the doc so was very gung ho about letting it do what it wanted. I did this over several hours/days, fixed some bugs and tried a few dead ends and crazy ideas (I don't think it can implement some of the feature requests on this thread yet). The results were great, but it did burn through over 1M tokens. I don't know how many API calls it took, because I was running several sessions/projects at once.