DYN-8766 - Add local node help lookup as fallback for DNA

[johnpierson]

Purpose

This PR enhances the Node AutoComplete functionality by providing fallback suggestions from local help files when ML-based recommendations are unavailable. It also refactors code to support the new feature and ensures necessary internal access for the extension.

Declarations

Check these if you believe they are true

• [ ] Is documented according to the standards
• [ ] The level of testing this PR includes is appropriate
• [ ] User facing strings, if any, are extracted into *.resx files
• [ ] Snapshot of UI changes, if any.
• [ ] Changes to the API follow Semantic Versioning and are documented in the API Changes document.
• [ ] This PR modifies some build requirements and the readme is updated
• [ ] This PR contains no files larger than 50 MB
• [ ] This PR introduces new feature code involve network connecting and is tested with no-network mode.

Release Notes

N/A

Reviewers

@DynamoDS/synapse

FYIs

@DynamoDS/eidos

[johnpierson]

Still need to make it work with packages, because the DynamoForma package is a big driver for something like this to be possible.

[BogdanZavu]

For the candidate help file we are looking for AppData\Roaming\Dynamo\Dynamo Core\3.6\packages\Clockwork for Dynamo 3.x\doc\a9ad1519-73f2-4015-97e3-03c6b9a484eb.dyn That is indeed the creation name but perhaps we should look for category as help - which in this case is more human readable e.g Clockwork.Display.Create.

[BogdanZavu]

@johnpierson can you recommend some packages that worth installing while testing this ? We are doing all this in an worker thread but still I'm wondering if this could be problematic performance wise if it happens to target a big package with lots of custom nodes and help files and/or a lot of packages are installed. We are narrowing down on every step so we should probably be fine.

This is a very nice enhancement overall! LGTM!

[johnpierson]

@johnpierson can you recommend some packages that worth installing while testing this ? We are doing all this in an worker thread but still I'm wondering if this could be problematic performance wise if it happens to target a big package with lots of custom nodes and help files and/or a lot of packages are installed. We are narrowing down on every step so we should probably be fine.

I would say that the following are good (but not sure which ones actually have .md docs in the docs folder, Rhythm doesn't but can pretty quickly I think).

• Clockwork
• Rhythm
• Orchid
• GeniusLoci

[johnpierson]

For the candidate help file we are looking for AppData\Roaming\Dynamo\Dynamo Core\3.6\packages\Clockwork for Dynamo 3.x\doc\a9ad1519-73f2-4015-97e3-03c6b9a484eb.dyn That is indeed the creation name but perhaps we should look for category as help - which in this case is more human readable e.g Clockwork.Display.Create.

I fixed this to search based on category and node name. However, clockwork does not ship .dyn samples within the docs folder. Only .md. 🫠 His .md files instruct the user to download from Github. So the search won't find nodes for clockwork using this method. But it is fixed! 😃