I’m uncertain about the implications, though there are certainly many. It’d be wonderful if one could directly open and preview a Grasshopper script with RiR components from within Standard Grasshopper.
It’s peculiar that an RiR script is essentially a standard Grasshopper script but can’t be opened in regular Rhino. This necessitates naming the script with an RiR prefix for identification.
Having a message such as ‘This script contains Rhino-in-Revit components and requires opening via Revit’s Rhino.Inside add-on for full functionality’ would be beneficial.
You get a message when opening a GH file with unsupported contents now. I’m not seeing how this improves the workflow.
Rhino.Inside.Revit components require the Revit environment. Like you mentioned naming or putting into a particular folder can help prevent a user from opening outside that environment.
I apologize if my perspective may overlook the intricacies behind the ‘inside’ coding functionality. I’m mainly approaching this from an end-user standpoint, where the current setup feels a bit counterintuitive. When I encounter a .gh file, I expect that it opens in Grasshopper. If any mainstream plugins are missing, I can typically download them through the package manager. However, encountering RiR components without prior knowledge leaves users stuck.
From this viewpoint, It seems like your line of reasoning might eventually lead to the software diverging into separate entities, possibly resulting in files being saved in different formats, such as .gh and .ghr
While it’s accurate that Rhino.Inside.Revit components primarily function within the Revit environment, isn’t it possible to accomplish various tasks outside Revit’s API? Accessing data and libraries without direct API interaction might empower certain scripts to operate without being constrained by Revit’s memory limitations.
Side note, the inclusion of the value picker component within standard Grasshopper would be immensely advantageous.
