16 September 2019
Setting ViewTemplate
Do you use view templates to control views, I do. Especially do I use view templates for views there is put on sheets. Therefore does the latest build contain a series of nodes for view templates. Besides are nodes for views extended.
25 June 2019
Move an entire model and its views
Have you ever witness the challenge of working with a model that is started by someone who didn’t know the importance of controlling the project origin!?
As a university and an estate owner do we inherit many models made in projects where the scenario is that someone forgot to control this at an early stage so the model could have been corrected. First when the project comes to the handover phase is it then discovered that this very critical error occurs.
Therefore, I took this challenge to code the bits and pieces to be able to move an entire model including moving elevations, sections, detailing, and 3D views, etc., also including adjustments for grids, crop boxes, views location on sheets. All in all, everything inside the project should be transformed by a given vector.
This work made me walk along many paths, developing a variety of nodes for grouping, views, viewports, and grids. More than 25 nodes have been created.
However, In the final scenario, I ended up only using a few of these nodes, while I continuously tried to figure smarter and smarter ways to tweak data. The nodes developed along the way is released also, while these could be used for other purposes and/or minor other tasks than moving the entire project.
move to origin (the final graph)
---
nodes for spatial element (room, space, and area)
nodes for view, viewport etc.
nodes for grouping etc.
nodes for grids etc.
24 April 2019
Minor release 134.5.0 / 202.5.0 and major release 210.0.0
Revit 2020 (and
Dynamo 2.1) has been released and therefore have I released my package for
2.1.x series. This has a huge impact on all version of the Orchid package since
a large reshuffle of node locations has taken place.
Unfordenetly is the problems concerning migration not being solved with the Dynamo 2.1 release, however, it was not viable any longer to wait for a fix of the migration problem while it was slowing down my development.
Unfordenetly is the problems concerning migration not being solved with the Dynamo 2.1 release, however, it was not viable any longer to wait for a fix of the migration problem while it was slowing down my development.
This rather
big issue will give users errors, and the only thing I can suggest is to address
complains over this error towards the dynamo team at dynamobim.com forum and/or
DynamoDS gitHub. I don’t find it suitable that I should correct this error,
this must be an Autodesk issue.
26 March 2019
BuiltInParameter, Transfer/Copy, central/linked files
In this update have I added several new features in different areas.
Nodes for BuiltInParameter
Nodes for copying and transferring elements between different document
Nodes for opening, save and closing central files
Nodes for linking files into documents
Nodes for BuiltInParameter
Nodes for copying and transferring elements between different document
Nodes for opening, save and closing central files
Nodes for linking files into documents
15 March 2019
Graphs...
I have seen it over and over again. Users calling Dynamo "graphs" as "scripts". Sorry but this is not what it is!
What we do with Dynamo is much smarter, it is directed graph technology. It is a much higher order way to do (visual) programming, than simple scripts known from ex. Java scripts, or even the way Python scripts is widely used in Custom Nodes... or scripts in Code Blocks.
Naming it "scripts" is to patronize what we actually do.
https://en.wikipedia.org/wiki/Directed_acyclic_graph
https://en.wikipedia.org/wiki/Visual_programming_language
https://en.wikipedia.org/wiki/Graph_rewriting
Try also to open a dynamo 1.3 file in a text editor...
Or take a look at the Dynamo Primer...
...and from https://primer.dynamobim.org/13_Best-Practice/13-2_Graph-Strategies.html
Reduce Complexity
As you develop your Dynamo graph and test ideas, it can quickly grow in size and complexity. While it is important that you create a functioning program, it is equally important to do it as simply as possible. Not only will your graph run faster and more predictably, you along with other users will understand its logic later on. The following are several ways that will help you clarify the logic of your graph.
[...]
Maintain Readability
In addition to making your graph as simple and efficient as possible, strive for graphic clarity. Despite your best efforts to make your graph intuitive with logical groupings, relationships might not be readily apparent. A simple Note inside of a Group or renaming a slider can save you or another user from unnecessary confusion or panning across the graph. The following are several ways that will help you apply graphic consistency within and across your graphs.
It does matter to use a "language" thoroughly. Giving up language is giving up the core of whatever a culture stands for. Therefore, I don’t think it is a good idea to let "slang" become the language!
Please let us use the right notation... it is graphs, not scripts!
What we do with Dynamo is much smarter, it is directed graph technology. It is a much higher order way to do (visual) programming, than simple scripts known from ex. Java scripts, or even the way Python scripts is widely used in Custom Nodes... or scripts in Code Blocks.
Naming it "scripts" is to patronize what we actually do.
https://en.wikipedia.org/wiki/Directed_acyclic_graph
https://en.wikipedia.org/wiki/Visual_programming_language
https://en.wikipedia.org/wiki/Graph_rewriting
Try also to open a dynamo 1.3 file in a text editor...
<Connectors>
<Dynamo.Graph.Connectors.ConnectorModel ... />
</Connectors>Or take a look at the Dynamo Primer...
...and from https://primer.dynamobim.org/13_Best-Practice/13-2_Graph-Strategies.html
Reduce Complexity
As you develop your Dynamo graph and test ideas, it can quickly grow in size and complexity. While it is important that you create a functioning program, it is equally important to do it as simply as possible. Not only will your graph run faster and more predictably, you along with other users will understand its logic later on. The following are several ways that will help you clarify the logic of your graph.
[...]
Maintain Readability
In addition to making your graph as simple and efficient as possible, strive for graphic clarity. Despite your best efforts to make your graph intuitive with logical groupings, relationships might not be readily apparent. A simple Note inside of a Group or renaming a slider can save you or another user from unnecessary confusion or panning across the graph. The following are several ways that will help you apply graphic consistency within and across your graphs.
It does matter to use a "language" thoroughly. Giving up language is giving up the core of whatever a culture stands for. Therefore, I don’t think it is a good idea to let "slang" become the language!
Please let us use the right notation... it is graphs, not scripts!
10 March 2019
New nodes for materials
The update x.4.1 includes a new branch for “Materials” and +100 new nodes handling generic material-, graphical-, appearance-, physical-, and thermal assets.
Material general
Graphics
Physical and Thermal
Appearance
Material general
Graphics
Physical and Thermal
Appearance
25 February 2019
IFC export and some other new nodes
The major update release (134.4.0 and 202.4.0) includes nodes for IFX export.
The nodes is build using the API from the IFC exporter 18.4.0 (for dynamo 1.3.x) and 19.1.0 (for dynamo 2.0.x), meaning the exporter must be installed to use these nodes!
Building the exporter nodes made me realize that some project nodes also was needed
Dropdown for families in the project and selection of all elements by family in the document added.
String.Substring and String.Replace added, these takes lists as input!
can be used for "manually" migration of dynamo files
https://forum.dynamobim.com/t/dynamocore/31912/13
https://forum.dynamobim.com/t/migrate-custom-nodes-to-zero-touch-nodes/31585/8
The nodes is build using the API from the IFC exporter 18.4.0 (for dynamo 1.3.x) and 19.1.0 (for dynamo 2.0.x), meaning the exporter must be installed to use these nodes!
Building the exporter nodes made me realize that some project nodes also was needed
Dropdown for families in the project and selection of all elements by family in the document added.
String.Substring and String.Replace added, these takes lists as input!
can be used for "manually" migration of dynamo files
https://forum.dynamobim.com/t/dynamocore/31912/13
https://forum.dynamobim.com/t/migrate-custom-nodes-to-zero-touch-nodes/31585/8
09 February 2019
Open new view ... active view
I have made a node for opening a new view, this new view will then be the active view when the graph is finished and the dynamo application again is idle. However, this is only one half of what I would like to be able to do with my node. My goal was to be able to close the other open windows in the same process.
That is not possible at the moment due to the way Dynamo works. If it should be possible I need the ability to use events inside a method in Dynamo like this post by Jeremy Tammik describes.
Therefore, is the workaround at the moment as following. Add the “OpenView” node in a graph and then execute the graph and do whatever is needed. When you eventually has finished doing whatever you should, then save and closes the file.
When the file is re-open will the last view be the default view unless starting view is set, in that case, will it be the starting view and that would be correct in those cases.
This new node cannot be called as a background action!
That is not possible at the moment due to the way Dynamo works. If it should be possible I need the ability to use events inside a method in Dynamo like this post by Jeremy Tammik describes.
Therefore, is the workaround at the moment as following. Add the “OpenView” node in a graph and then execute the graph and do whatever is needed. When you eventually has finished doing whatever you should, then save and closes the file.
When the file is re-open will the last view be the default view unless starting view is set, in that case, will it be the starting view and that would be correct in those cases.
This new node cannot be called as a background action!
04 February 2019
Associate and Category
Orchid version 134.3.11 / 202.3.11 has been released.
The latest update includes a larger extension of nodes for association.
New node for nested associated elements in families (orange box in image) and node for parameters to verify if "HasAssociated" elements.
Association for global parameters. Associate, GetAssociate and HasAssociated.
Verify if "Family" and FamilyType" has associated elements
Several nodes for Category. Get all built in categories, categories in document, categories by category type and lastly get the category type from categories.
New node for SetType. The node takes an "element" and a "familyType". the element gets the "FamilyType". This can be used when elements need a new type ex. when randomizing. Besides is two new nodes for random created. These nodes take a "range" and return random number(s) in the range. The OOTB node gives the random number in the range 0 to 1.
The latest update includes a larger extension of nodes for association.
New node for nested associated elements in families (orange box in image) and node for parameters to verify if "HasAssociated" elements.
Association for global parameters. Associate, GetAssociate and HasAssociated.
Verify if "Family" and FamilyType" has associated elements
Several nodes for Category. Get all built in categories, categories in document, categories by category type and lastly get the category type from categories.
New node for SetType. The node takes an "element" and a "familyType". the element gets the "FamilyType". This can be used when elements need a new type ex. when randomizing. Besides is two new nodes for random created. These nodes take a "range" and return random number(s) in the range. The OOTB node gives the random number in the range 0 to 1.
03 February 2019
Migrate Custom Nodes to Zero Touch nodes
Yet another time has a user problems in migrating a graph using Custom Nodes which are deprecated to the comparative Zero Touch node. It seems there still exist users who cling to to my long-gone DanEDU package which was a CN based package because it is a job to migrate it using my new ZT based package (Orchid)
I have tried if there was any possibility to add old CN nodes in my migration, but that is not possible.
However, I did try to solve this issue for the user, and figured that it is doable to do a “manually” migration using a notepad editor, and it was not that difficult...
It is a good idea to make a dummy file with the corresponding nodes you want to use because you need to know where the assemblies are stored and what the names are, the easiest is to create a graph with the nodes you know you need and then open this file in a notepad so you have the strings you need to replace values with!
The below example is from a 1.3.x graph, since the old graph most likely is from the era with the old layout before the 2.0.x versions.
The below is the node "List.Clean|DanEDU"
example where a “codeblock” with the connector
Therefore be exceptional observant towards these guid’s!
Likewise do not change the x, y position for the node ex.
REPLACE to “List.Clean” node
The first string to replace is
-– this will replace all the CN nodes functions!!! -–
Next string to replace is
Then add the assembly in the end of the line with
extend this to
Move on to the other nodes, replacing only the last two strings per node!
Thats it... all the other strings from the “old” node will be removed when you open the graph, then you are good to go...
Try this out by your self...
danedu nodes.dyn
danedu nodes-migrated.dyn
I have tried if there was any possibility to add old CN nodes in my migration, but that is not possible.
However, I did try to solve this issue for the user, and figured that it is doable to do a “manually” migration using a notepad editor, and it was not that difficult...
It is a good idea to make a dummy file with the corresponding nodes you want to use because you need to know where the assemblies are stored and what the names are, the easiest is to create a graph with the nodes you know you need and then open this file in a notepad so you have the strings you need to replace values with!
The below example is from a 1.3.x graph, since the old graph most likely is from the era with the old layout before the 2.0.x versions.
The below is the node "List.Clean|DanEDU"
<Dynamo.Graph.Nodes.CustomNodes.Function guid="e4e4649b-af37-41d3-bde8-29c4e9181d4a" type="Dynamo.Graph.Nodes.CustomNodes.Function" nickname="List.Clean|DanEDU" x="281.221049098559" y="999.174659610855" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false">
<PortInfo index="0" default="False" />
<PortInfo index="1" default="True" />
<ID value="f39ad724-9216-46d6-9cfc-0e9bb8a71360" />
<Name value="List.Clean|DanEDU" />
<Description value="Remove empty list, null and blank values
- former named as RemoveNull" />
<Inputs>
<Input value="list" />
<Input value="searchFor" />
</Inputs>
<Outputs>
<Output value="list" />
</Outputs>
</Dynamo.Graph.Nodes.CustomNodes.Function>
The below is the ZT node “List.Clean” in the Orchid package
<Dynamo.Graph.Nodes.ZeroTouch.DSFunction guid="f166a310-a158-4778-b709-8eb190e878c8" type="Dynamo.Graph.Nodes.ZeroTouch.DSFunction" nickname="List.Clean" x="-0.0783702393594012" y="999.174659610855" isVisible="true" isUpstreamVisible="true" lacing="Shortest" isSelectedInput="False" IsFrozen="false" isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">
<PortInfo index="0" default="False" />
<PortInfo index="1" default="True" />
</Dynamo.Graph.Nodes.ZeroTouch.DSFunction>
The most important part to keep is the guid mention in the first line after the function, ex. guid="e4e4649b-af37-41d3-bde8-29c4e9181d4a". The guid is the id used in the graph as the connector!
example where a “codeblock” with the connector
guid="f7fc68c8-1239-46d9-848c-ef958450c6de" connects to the “List.Clean|DanEDU” node
<Dynamo.Graph.Connectors.ConnectorModel start="f7fc68c8-1239-46d9-848c-ef958450c6de" start_index="0" end="e4e4649b-af37-41d3-bde8-29c4e9181d4a" end_index="0" portType="0" />
Therefore be exceptional observant towards these guid’s!
Likewise do not change the x, y position for the node ex.
x="281.221049098559" y="999.174659610855"
REPLACE to “List.Clean” node
The first string to replace is
Dynamo.Graph.Nodes.CustomNodes.Function with Dynamo.Graph.Nodes.ZeroTouch.DSFunction-– this will replace all the CN nodes functions!!! -–
Next string to replace is
nickname="List.Clean|DanEDU" with nickname="List.Clean"
Then add the assembly in the end of the line with
isPinned="false">extend this to
isPinned="false" assembly="..\..\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages\Orchid\bin\OrchidGeneric.dll" function="Orchid.Generic.Core.List.Clean@var[]..[],var[]..[]">
Move on to the other nodes, replacing only the last two strings per node!
Thats it... all the other strings from the “old” node will be removed when you open the graph, then you are good to go...
Try this out by your self...
danedu nodes.dyn
danedu nodes-migrated.dyn
This post is originally published at dynamobim.org
21 January 2019
HasAssociated and Convert
New release there includes some new nodes...
Check if family parameter has associated element (...in upper right corner).
PostEdit: Associate nodes is updated
Node there converts shared parameters to family parameters.
After the last update of all family document nodes, is all nodes also updated changing the output to the most suited instead of document as output.
Check if family parameter has associated element (...in upper right corner).
PostEdit: Associate nodes is updated
Node there converts shared parameters to family parameters.
After the last update of all family document nodes, is all nodes also updated changing the output to the most suited instead of document as output.
This post is originally published at dynamobim.org
AddIfcParameters and updates
Orchid version 134.3.10 / 202.3.10 has been released.
The largest change in this version is that the package has been refactored to comply with naming conventions.
The next largest change is all FamilyDocument nodes don’t pass the document as an output, likewise, other nodes there passed project documents. I have made this rather large change to be able to support ”ListLevel” better, I have noticed many users have problems understanding that the output changes dramatically for passing the opened document when list level is used. Therefore do all now need to use the DataStream.Await to let documents being passed.
Updated family document example...
One of the new nodes is AddIfcParameters, this one adds the four most important IFC parameters.
Parameters are found in the IFC Shared Parameters.txt that works together with the Revit IFC exporter!
http://help.autodesk.com/view/RVT/2019/ENU/?guid=GUID-7119A8C3-A0EE-4568-8C35-750410D867C9
https://github.com/Autodesk/revit-ifc/tree/master/Source/RevitIFCTools
Parameter example...
I have also changed the icon layout for all nodes. All large icons are now 128x128 px, and I have started to use a green and yellow color in icons. Family document icons have got a new border to show they are only for Family documents. I am still trying to keep the general layout used by the Dynamo team.
The largest change in this version is that the package has been refactored to comply with naming conventions.
The next largest change is all FamilyDocument nodes don’t pass the document as an output, likewise, other nodes there passed project documents. I have made this rather large change to be able to support ”ListLevel” better, I have noticed many users have problems understanding that the output changes dramatically for passing the opened document when list level is used. Therefore do all now need to use the DataStream.Await to let documents being passed.
Updated family document example...
One of the new nodes is AddIfcParameters, this one adds the four most important IFC parameters.
Parameters are found in the IFC Shared Parameters.txt that works together with the Revit IFC exporter!
http://help.autodesk.com/view/RVT/2019/ENU/?guid=GUID-7119A8C3-A0EE-4568-8C35-750410D867C9
https://github.com/Autodesk/revit-ifc/tree/master/Source/RevitIFCTools
| PARAM | 3c9ac775-15e4-4ba5-8edb-4167e3fb4151 | IFC CAD Layer | TEXT |
| PARAM | 8df7e965-feaf-403f-8290-d4c289c99840 | IfcDescription | TEXT |
| PARAM | a3e2f9a7-f184-4d16-80e7-349181e17d3d | IfcExportAs | TEXT |
| PARAM | 9a17f9c0-c41b-4ceb-8279-b20e789fa3a8 | IfcExportType | TEXT |
Parameter example...
I have also changed the icon layout for all nodes. All large icons are now 128x128 px, and I have started to use a green and yellow color in icons. Family document icons have got a new border to show they are only for Family documents. I am still trying to keep the general layout used by the Dynamo team.
This post is originally published at dynamobim.org
FamilyName
I have made some supplemental nodes for Element and ElementType to get FamilyName and Name for ElementType!
The new FamilyName nodes might come handy when it is needed to figure if a wall is a Curtain Wall or a Basic Wall :-)
The new FamilyName nodes might come handy when it is needed to figure if a wall is a Curtain Wall or a Basic Wall :-)
This post is originally published at dynamobim.org
Shared Parameters
Yet another update (132.3.9 / 201.3.9)… new nodes created for Shared Parameters.
The idea with the “SetFile” node is to be able to set a temporary SP file while doing stuff, and in the end, return to the original SP file. If you want to test it without any “Stuff”, then use the Circut node, set it to false and then you can verify that the SP file changes. Then test it with the Circuit set to true and you should end up with the file you had in your file (remember to reset between the two tests!).
The two “query” nodes get all the parameters in the SP file and group them either by type or by group name.
The idea with the “SetFile” node is to be able to set a temporary SP file while doing stuff, and in the end, return to the original SP file. If you want to test it without any “Stuff”, then use the Circut node, set it to false and then you can verify that the SP file changes. Then test it with the Circuit set to true and you should end up with the file you had in your file (remember to reset between the two tests!).
The two “query” nodes get all the parameters in the SP file and group them either by type or by group name.
This post is originally published at dynamobim.org
Subcategory nodes
more new nodes for getting families, familytypes, and nodes for subcategories.
-released in the 201.3.8 / 132.3.8 version of Orchid
-released in the 201.3.8 / 132.3.8 version of Orchid
This post is originally published at dynamobim.org
Orchid: new nodes
I have just updated to 132.3.7 / 201.3.7 versions. They both support the newly released 2.0.2 and 1.3.4 version of Dynamo as well.
One major change is that the two versions are now split into individual installers. I have evaluated that the time is up for this since the 2.0 version has been around for some time and that many new users don’t use the old 1.3 series anymore. However, there is still a world out there that need to be compatible with the 1.3 series. I will in the future develop against the 2.0 series but maintain the 1.3 series as long as it is possible without doing anything extra. Over time will the development of the 1.3 series stop.
By this version, I have also removed the last Custom Nodes meaning all nodes in the package is now Zero Touch nodes (The last four CN nodes for FEM-design).
This update also adds some new nodes and some updated nodes as well. Among these is the node there can tell the user if an update of the package exists!
new...
Does category/document contain?
Several nodes for materials
updated...
One major change is that the two versions are now split into individual installers. I have evaluated that the time is up for this since the 2.0 version has been around for some time and that many new users don’t use the old 1.3 series anymore. However, there is still a world out there that need to be compatible with the 1.3 series. I will in the future develop against the 2.0 series but maintain the 1.3 series as long as it is possible without doing anything extra. Over time will the development of the 1.3 series stop.
By this version, I have also removed the last Custom Nodes meaning all nodes in the package is now Zero Touch nodes (The last four CN nodes for FEM-design).
This update also adds some new nodes and some updated nodes as well. Among these is the node there can tell the user if an update of the package exists!
new...
Does category/document contain?
Several nodes for materials
updated...
This post is originally published at dynamobim.org
Print nodes
I have made a new set of Print nodes, incl. a new node for the “ActiveView” that handles any kind of view incl. sheet view, which the OOTB node do not handle!
This post is originally published at dynamobim.org
Compound structures nodes
I have started to expand my nodes for compound structures (system family)...
This post is originally published at dynamobim.org
System variables nodes
In the establishment of the Orchid sample collection did I recognize the need for using system variables for directories. Therefore have I made nodes for this.
The "About" nodes help the user maintaining the package. Place the "Update" node at the canvas and it will look if an update is available. In case there is, the node will open a web browser with the GitHub address.
The "About" nodes help the user maintaining the package. Place the "Update" node at the canvas and it will look if an update is available. In case there is, the node will open a web browser with the GitHub address.
This post is originally published at dynamobim.org
Parameter nodes
I have Improved the Parameter nodes and extended it with two more nodes.
The AddSharedParameter node and the AddProjectParameter can now be used to update category binding if the parameter exists in the project in advance. Furthermore is the ChangeCategory node used for changing/updating category binding. The DeleteParameter node is for removing/deleting a parameter in the project.
This post is originally published at dynamobim.org
Distribute dynamo in an organizational context
There is on occasional basis questions concerning “How to distribute Dynamo and Dynamo packages” especially in an organizational context. The main problem seems to be how to update and maintain that users in a network share the same packages.
I have previously argued for a solution that included “Inno Setup” from http://www.jrsoftware.org this is the same installer used by the dynamo-team to distribute Dynamo, and most important, it is freeware but the developers would be happy for donations :-)
There has been some debate in another post, where I argued that the added article that described how to do it using notepad++ was a very limited solution. I will try to explain why.
Let's say you have an organization where the environment consists of workstations and laptops, a mixed environment, which is very common nowadays.
One option would be that you can have a server location for your packages, but this only solves the problem for the workstations, this is not a good solution for the laptops. Well then use VPN… no, not really. It is a limitation if your environment is dependent on a VPN tunnel for “ordinary” work done on your laptop, this should only be the case in time-limited work processes. This is why licenses are being distributed as they are… usually something there just looks for a valid license but nothing else than that. This is being solved in many ways.
So you are left now with an organization where no one has a shared connection and we want something to work the same way on all computers… especially do we want it to be updated whenever something new is done.
On the other hand do the BIM-manager not want to disturb the IT/Server people over and over again, for updating some odd thing called dynamo…
This is why Inno Setup is the answer. Go talk with the IT admins and let them understand that they need to let the login procedure add two executables. One for the machine startup and one for the user login.
Most of the below-shown code (iss files) can be set up using third parties tools for Inno Setup, but there is some line of Pascal code needed, just copy it, edit it and you should be good to go.
The main idea is, that the BIM manager can maintain--on his/ her personal computer--how the organizational environment should look like. When changes occur, then simply compile new executables and copy the files to the agreed location with the IT admins, Then next time someone restarts/login, then changes will be updated automatically… and individually! However, maintained central :-)
What is being handled on a machine level should include privileges for powerusers or admins, by doing this, then “shared” packages cannot be changed. This can be setup in a way so it still works concerning the “read/write” problem. However, this method can be extended into being a “fixmyproblem” executable users can run from start bottom if something occurs. In that case simply skip checking for the version number.
Dynamo (machine).iss
Dynamo (user).iss
I have previously argued for a solution that included “Inno Setup” from http://www.jrsoftware.org this is the same installer used by the dynamo-team to distribute Dynamo, and most important, it is freeware but the developers would be happy for donations :-)
There has been some debate in another post, where I argued that the added article that described how to do it using notepad++ was a very limited solution. I will try to explain why.
Let's say you have an organization where the environment consists of workstations and laptops, a mixed environment, which is very common nowadays.
One option would be that you can have a server location for your packages, but this only solves the problem for the workstations, this is not a good solution for the laptops. Well then use VPN… no, not really. It is a limitation if your environment is dependent on a VPN tunnel for “ordinary” work done on your laptop, this should only be the case in time-limited work processes. This is why licenses are being distributed as they are… usually something there just looks for a valid license but nothing else than that. This is being solved in many ways.
So you are left now with an organization where no one has a shared connection and we want something to work the same way on all computers… especially do we want it to be updated whenever something new is done.
On the other hand do the BIM-manager not want to disturb the IT/Server people over and over again, for updating some odd thing called dynamo…
This is why Inno Setup is the answer. Go talk with the IT admins and let them understand that they need to let the login procedure add two executables. One for the machine startup and one for the user login.
Most of the below-shown code (iss files) can be set up using third parties tools for Inno Setup, but there is some line of Pascal code needed, just copy it, edit it and you should be good to go.
The main idea is, that the BIM manager can maintain--on his/ her personal computer--how the organizational environment should look like. When changes occur, then simply compile new executables and copy the files to the agreed location with the IT admins, Then next time someone restarts/login, then changes will be updated automatically… and individually! However, maintained central :-)
What is being handled on a machine level should include privileges for powerusers or admins, by doing this, then “shared” packages cannot be changed. This can be setup in a way so it still works concerning the “read/write” problem. However, this method can be extended into being a “fixmyproblem” executable users can run from start bottom if something occurs. In that case simply skip checking for the version number.
Dynamo (machine).iss
Preprocessor variables
;My Dynamo path
;Replace --> (your login)
#dim sourcePackages[4]
#define sourcePackages[0] "C:\Users\(your login)\AppData\Roaming\Dynamo\Content\packages"
#define sourcePackages[1] "C:\Users\(your login)\AppData\Roaming\Dynamo\Dynamo Revit\1.3\packages"
#define sourcePackages[2] "C:\Users\(your login)\AppData\Roaming\Dynamo\Dynamo Revit\2.0\packages"
;Dynamo path
;Replace --> (your organization id)
#dim destinationPackages[3]
#define destinationPackages[0] "{commonappdata}\Dynamo\(your organization id)\All\packages"
#define destinationPackages[1] "{commonappdata}\Dynamo\(your organization id)\130\packages"
#define destinationPackages[2] "{commonappdata}\Dynamo\(your organization id)\200\packages"
[Setup]
;SourceDir=..\
;give a valid path where your output exe files should be compiled to!
OutputDir=userdocs:\SoftDev\
OutputBaseFilename=Dynamo_machine
AppName=Dynamo
;Versionnumber must be higher to install updates --> I use dates
AppVersion=2018.1101.0
;Replace --> author
AppCopyright= author
;Replace --> organization
AppPublisher= organization
RestartIfNeededByRun=false
AllowCancelDuringInstall=false
CreateAppDir=false
UsePreviousGroup=false
AppendDefaultGroupName=false
SolidCompression=true
Compression=lzma2/ultra
InternalCompressLevel=ultra
Uninstallable=false
;Normally will changes on a computer level in an organization require more than user privileges
PrivilegesRequired=poweruser
;PrivilegesRequired=none
[InstallDelete]
;Clean old packages
Type: filesandordirs; Name: {#destinationPackages[0]}
Type: filesandordirs; Name: {#destinationPackages[1]}
Type: filesandordirs; Name: {#destinationPackages[2]}
[Files]
;Packages to include
;Do only select those that shold be common, you might have several more packages installed by yourself
;Version specific packages, means that it takes those that are for either 1.3 og 2.0 environment
;In the example is all packages in the "source" folder selected!
Source: {#sourcePackages[1]}\*; DestDir: {#destinationPackages[1]}; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[2]}\*; DestDir: {#destinationPackages[2]}; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
;Common packages, means that the package is used both in the 1.3 og 2.0 environment
;In the example is specific packages in the "source" selected!
Source: {#sourcePackages[0]}\Dynamic CSharp Interpreter\*; DestDir: {#destinationPackages[0]}\Dynamic CSharp Interpreter; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\archi-lab.net\*; DestDir: {#destinationPackages[0]}\archi-lab.net; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Data-Shapes\*; DestDir: {#destinationPackages[0]}\Data-Shapes; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Rhythm\*; DestDir: {#destinationPackages[0]}\Rhythm; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\spring nodes\*; DestDir: {#destinationPackages[0]}\spring nodes; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Ampersand\*; DestDir: {#destinationPackages[0]}\Ampersand; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\BumbleBee\*; DestDir: {#destinationPackages[0]}\BumbleBee; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\MEPover\*; DestDir: {#destinationPackages[0]}\MEPover; Excludes: Backup\; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Structural Analysis for Dynamo\*; DestDir: {#destinationPackages[0]}\Structural Analysis for Dynamo; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Optimo\*; DestDir: {#destinationPackages[0]}\Optimo; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Honeybee\*; DestDir: {#destinationPackages[0]}\Honeybee; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
Source: {#sourcePackages[0]}\Ladybug\*; DestDir: {#destinationPackages[0]}\Ladybug; Excludes: dyf\backup; Flags: recursesubdirs createallsubdirs
[Registry]
;Version number
;Replace --> (your organization id)
Root: HKLM; Subkey: Software\(your organization id) ; ValueType: string; ValueName: Dynamo; ValueData: {#SetupSetting("AppVersion")}
[Code]
//Get the AppVersion
function CurrentVersion(): String;
begin
Result := ExpandConstant('{#SetupSetting("AppVersion")}');
end;
//Get the Registry value
//Replace --> (your organization id)
function GetInstalledVersion(): String;
var
InstalledVersion: String;
begin
InstalledVersion:= '';
RegQueryStringValue(HKLM, 'Software\(your organization id)', 'Dynamo', InstalledVersion);
Result:= InstalledVersion;
end;
//On initialize, check if higher value
function InitializeSetup(): boolean;
begin
if (GetInstalledVersion() < CurrentVersion()) then
result := true
else
result := false;
end;
Dynamo (user).iss
;Preprocessor variables
;My Dynamo path
#dim dynamoPath[2]
#define dynamoPath[0] "Dynamo\Dynamo Revit\1.3"
#define dynamoPath[1] "Dynamo\Dynamo Revit\2.0"
[Setup]
SourceDir=..\
;give a valid path where your output exe files should be compiled to!
OutputDir=userdocs:\SoftDev\
OutputBaseFilename=DTU_Dynamo_user
AppName=Dynamo
;Versionnumber must be higher to install updates --> I use dates
AppVersion=2018.1001.0
;Replace --> author
AppCopyright= author
;Replace --> organization
AppPublisher= organization
RestartIfNeededByRun=false
AllowCancelDuringInstall=false
CreateAppDir=false
UsePreviousGroup=false
AppendDefaultGroupName=false
SolidCompression=true
Compression=lzma2/ultra
InternalCompressLevel=ultra
Uninstallable=false
PrivilegesRequired=none
[Files]
;Default filestructure
;This part is ONLY needed if dynamo hasnt been installed and activated before this executable is being activated!
;look in the attached zip file for default content needed by the executable is runned before dynamo has been activated!
;Notice the source folder location if you want to use the default (from the zip file) content!
Source: Content\*.*; DestDir: {userappdata}; Flags: createallsubdirs recursesubdirs; Permissions: powerusers-full
[Registry]
;Version number
;Replace --> (your organization id)
Root: HKCU; Subkey: Software\(your organization id); ValueType: string; ValueName: Dynamo; ValueData: {#SetupSetting("AppVersion")}
[code]
//Get the AppVersion
function CurrentVersion(): String;
begin
Result := ExpandConstant('{#SetupSetting("AppVersion")}');
end;
//Get the Registry value
//Replace --> (your organization id)
function GetInstalledVersion(): String;
var
InstalledVersion: String;
begin
InstalledVersion:= '';
RegQueryStringValue(HKCU, 'Software\(your organization id)', 'Dynamo', InstalledVersion);
Result:= InstalledVersion;
end;
//On initialize, check if higher value
function InitializeSetup(): boolean;
begin
if (GetInstalledVersion() < CurrentVersion()) then
result := true
else
result := false;
end;
//Modify the XML document
procedure DynamoXML(const AFileName, APath, AValue: string);
var
XMLDocument, XMLNewNode, XMLRootNode : Variant;
begin
XMLDocument := CreateOleObject('Msxml2.DOMDocument.6.0');
XMLDocument.async := False;
XMLDocument.load(AFileName);
if XMLDocument.parseError.errorCode <> 0 then
exit;
XMLNewNode := XMLDocument.createElement('string');
XMLDocument.setProperty('SelectionLanguage', 'XPath');
XMLRootNode := XMLDocument.selectSingleNode(APath);
XMLRootNode.appendChild (XMLNewNode);
XMLRootNode.lastChild.text := AValue;
XMLDocument.save(AFileName);
end;
//On exit, modify
//Replace --> (your organization id)
procedure CurStepChanged(CurStep: TSetupStep);
begin
if CurStep = ssPostInstall then
begin
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[0]}\DynamoSettings.xml'),'//BackupFiles',ExpandConstant('{userappdata}\Dynamo\Dynamo Revit\backup\backup.DYN'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[0]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{userappdata}\{#dynamoPath[0]}'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[0]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{commonappdata}\Dynamo\All'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[0]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{commonappdata}\Dynamo\130'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[1]}\DynamoSettings.xml'),'//BackupFiles',ExpandConstant('{userappdata}\Dynamo\Dynamo Revit\backup\backup.DYN'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[1]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{userappdata}\{#dynamoPath[1]}'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[1]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{commonappdata}\Dynamo\All'));
DynamoXML(ExpandConstant('{userappdata}\{#dynamoPath[1]}\DynamoSettings.xml'),'//CustomPackageFolders',ExpandConstant('{commonappdata}\Dynamo\200'));
end;
end;
This post is originally published at dynamobim.org
Subscribe to:
Posts (Atom)