search

DynamoDS / Dynamo

Open Source Graphical Programming for Design
https://dynamobim.org
Other
1.74k stars 634 forks source link

MD help files error #13926

Open erfajo opened 1 year ago

erfajo commented 1 year ago

Dynamo version

2.17

Revit version

2024

Operating system

Windows 11

What did you do?

Tried to use the "extended" help... lookup md files in the /doc folder for installed packages. I was testing my own package Orchid if help files work as they do in previous versions of Revit/Dynamo.

What did you expect to see?

To see the extended help document stored in the /doc folder

What did you see instead?

nothing at all...

It seems that the "extended" markdown help files are not being read in Revit 2024/Dynamo 2.17!?

has this somehow a connection to issues I reported earlier?

Just for the record, the markdown files work in dynamo 2.12 and 2.16

github-actions[bot] commented 1 year ago

Thank you for submitting the issue to us. We are sorry to see you get stuck with your workflow. While waiting for our team member to respond, please feel free to browse our forum at https://forum.dynamobim.com/ for more Dynamo related information.

Amoursol commented 1 year ago

@erfajo to confirm, when you add these via the Package Authoring workflow they are not being correctly created? Or they are being correctly created, but they do not show up in Dynamo?

FYI @QilongTang @avidit

erfajo commented 1 year ago

Well, I hope I follow the Package Authoring workflow correctly, however, I can't find any official description, so what was made for Revit 2022/Dynamo 2.12 could have been changed… and somehow I do hope it is changed since having a folder with thousands of small files is a really bad idea. image

Nevertheless…

In Revit 2022/Dynamo 2.12 did my markdown files and illustrations (png files) work perfectly. image

In Revit 2023/Dynamo 2.16 did my markdown files work perfectly. However, illustrations failed. image

In Revit 2024/Dynamo 2.17 nothing work! image

You see, as you have ruined the work I had done for icons (when you changed them from quadratic to circular) so I now don't make any icons for nodes anymore. This is also what I see happening with markdown files. Version for version has this feature being made unusable.

I am afraid that whatever you do in the team, is only meant for the small packages and not in any way near the package size I operate in… I have an extremely large package, much larger than anyone else even what you do in the dynamo team.

I would wish that you somehow would involve the outside in whatever you plan on the roadmap for changes before setting it into production with the consequences that something does only work on a small scale and not on a large scale. I am aware that you think you do that, but we are some who don't feel that this is the case, and we are those who end up losing over and over.

chuongmep commented 1 year ago

With me, I just recommend an online version guideline like this : https://chuongmep.github.io/OpenMEP/api/OpenMEP.Element.Duct.html,. Why we need put a lot markdown file to installer, it just help installer become heavy and hard to manager.

erfajo commented 1 year ago

I have also a "default" help description that takes users outside on a web address, however, this still means that every node need to have a markdown file where this address is specified.

image

...I use this "default" help markdown file for all my nodes except the 20 nodes a made the "proof of concept" for. Since I know that new things most likely are not tested in depth I only use limited efforts in testing... and this feature is also failing due to not being functional for large packages.

Therefore I will strongly recommend that this ”doc” function is being reconsidered in a way so we can add markdown files as resources like the icon files and that we can have a default markdown file for every assembly file or namespace, or just for the package. This is also something I have put on the wishlist when it comes to default icons… I don't understand why we can't have a default icon for the package, and most preferable for a namespace or an assembly file (VS Solution). I think that it would be beneficial also for the small packages that ”default” whatever, in many ways could be coded into our solutions.

erfajo commented 1 year ago

I found yet another issue with the naming convention for the markdown help files... the issue is the whitespace needed in filenames where you have multi signatures for the method! ex. --> Orchid.Geometry.BoundingBox.Intersect(boundingBox, tolerence)

if you want to create files using a cmd file, then you need to save the file using a windows character set and not UTF8 character set since whitespace is not the same!

I have mentioned it before, the naming convention for your markdown files where multi signatures are needed is problematic, it should have been using the input type as is the case with icons… but having to use whitespace in filenames is another ballgame and should be avoided for any cost!

What if you just changed whitespace to either nothing or replaced it by a hypen? Just do something! --> Orchid.Geometry.BoundingBox.Intersect(boundingBox,tolerence) --> Orchid.Geometry.BoundingBox.Intersect(boundingBox-tolerence)