A couple of questions - 2

[adi]

So as I am trying to continue to learn Revit, dynamo, navisworks, python and the API’s I keep getting to a point where I am often not sure how one thing is affecting the other. Right now I have the following questions and any help is really appreciated.

1. Dynamo is not built for collaborative use. But Revit is.
   Revit checks out model elements from the central model for each user.

When we are making project wide changes such changing instance or type parameters, how are the conflicts based on ownership resolved?

2. Another thing UID :
   Revit assigns a GUID and ID to each element.
   How do dynamo and Revit individually affect these when we make changes.
   Ex- I replace a family type with another family type or I replace a family with another family.
   The obvious thing is to learn by doing but I am trying to understand the logic behind it. A blue print of when and how your changes are affecting the UID’s or GUIDs.

It’s very easy to break Revit models by doing project wide changes.
I have already searched the forum and been through a couple of threads but nothing exactly answers these questions.

3. Dynaworks/revitpython/etc.
   I am not a software developer and this might be a really noob question to ask.
   But how do people make these packages:
   Ex- Dynaworks - I am guessing it is somehow using navisworks data through the navisworks api. How are the nodes using/calling navisowrks api through dynamo?
   The reason I ask this question is simple - sometimes I would just like to add a functionality which is not yet there.
   Such as adding Numpy/Scipy functionality to python nodes that so that I could do simple matrix operations.
   (There is a post on the forum regarding that which says - dynamo Python nodes are iron python based … numpy scipy libraries are not built for iron python … head hurts)

I could really use some help here.

IFC GUID vs Revit ID

Revits unique and IFC GUID is two different IDs. After what I understand the IFC guide is shorter to minimize the lenght and thereby size. It is a “forumla/function” for this convertion. I have two questions: Is IFC GUID something that can be exctracted directly, or do I need to first get the Revit ID and convert it? Is there a node for this? Has anyone made something for this?

Getting the GUID from a SharedParameterElement

I’m attempting to generate a list of GUID’s from input SharedParameterElements. The snoop tool illustrates what I am going after. [image] Here is my current node layout to help illustrate the process I’m going through currently… [image] The python node is where things are getting hung up. I’ve done some research and tried to reverse engineer elements that I’ve gotten from other python scripts, but am having some issues, admittedly I don’t know enough about python scripting to know what I’m …

Thanks
-Aditya

[jacob.small]

1. Fairly certain that Dynamo and any other Revit API accessed efforts in a workshare enabled model is really just like having you do the work but SUPER fast. You’re still running Revit first, Dynamo is just doing the clicks for you.

Try a simple sheet renaming script, but ‘check out’ a sheet name by attempting the edit as a different user on a different CPU first. It will fail with the standard Revit ‘need to sync’ message and no changes will be applied to the model (it’s one button not 30).

2. Elements are assigned a UID and a ID on creation. UID is formula driven. ID is just the next number in the database. When syncing the work with central the ID can change (when you downloaded the content from central it didn’t know that your coworker was going to push new elements into the database before you did. UID never changes. This is the case if it is Dynamo making the content or a user. Also changing parameter values won’t change ID or UID, only new and deleted elements require ID/UID addition or deletion.

[Gytaco]

There are no blueprints for ElementIds, UID(they arent really guids) anyway. This is all internal code and unless Autodesk shares it(you dont really need to know) all i know is ElementIds may change when central files reconcile UID’s dont. Sync to central does all the rest of the work. As for Revit dynamo can only work within the confines of the Revit API. AKA the same rules apply to a user in a workshared environment as dynamo. If items are checked out when you run a transaction dynamo will roll back the transaction. So there are user permissions you would need to deal with prior to running anything.

Dynamo has the ability to read any dll and expose classes, methods and properties with that files just by using Import.

If you are a noob to programming then your probably going to have a tough time understanding how dll’s work let alone how to build something like DynaWorks. There’s nothing too complex in there but it does require a reasonable understanding of OOP, COM, dotnet references(Reflections, Collections). If your not sure what I am talking about then I would go get a learn to program book and start with that.

As for DynaWorks, it simply exposes functions that are in the COM API with a wrapper that makes reading the nodes user friendly and also passes out various results in internal classes so as not to expose the original classes to the Dynamo node creation class methods or create any work Navis API instances already deliver. This has dependancies on a number of Dynamo dll’s that create custom nodes in the actual package aswell.

As for python I assume you would do it the same way(I am not a Python dev), write wrappers for python import the various libraries from whatever sources (Dynamo, Numpy), build the source with a dotnet compiler and you would have access to those objects. Alternatively I believe a few people have written python parsers so you just load your py scripts and it executes, but there are others better able to answer that question. This all depends whether you want nodes to work with or are you looking to extend python script nodes with other packages support. The former will be much easier then the latter.