Experiment

1

Would it be possible to create a graph or extension that gives me extra info on a .dyf, telling me based on the date if i can use it in R2022 R2023 etc.

@john_pierson

1 Like
2

You can definitely have a graph or extension read the dyf data and parse it for any useful information. You can also parse the pkg.json for similar information, but Revit info would only exist if the package author included it (assuming this is primarily directed at custom nodes/packages) and you don’t necessarily know where or what format that would be in. Full Revit support would also depend on things like Python version and API version.

What “date” are you using to identify Revit version and what’s the relationship? I think you can absolutely get something, but to get something that’s both accurate and scalable requires dealing with a lot of assumptions and unknowns.

1 Like
3

Thanks for your input.

Can you share your second thoughts on unknowns and such

4

I’m mainly just referencing what I brought up in the first section. Revit version isn’t a required field for a package and compatibility is dependent on multiple things, so identifying what version or versions are supported by a given node would likely be hard to define - though not strictly impossible. If the author includes version support in the description or package info anywhere, great, but you still have to work out how to identify that information. If you want to assign supported version(s) based on some value (like release date), you can, but there are multiple things that control whether a node will be supported in a given version of Revit or not. And again, some of those things may be available in the node or package info and some of them may not.

1 Like
5

Now I will say that the updates to the package manager should start to make this a lot easier. As package authors begin to add that information to their packages, we’ll be able to clearly identify support across versions since we’ll have a dedicated property for it (assuming that that info makes its way to the pkg.json). There could still be a need for otherwise extracting that data based on all the other assumptions though. So it really only takes care of one scenario, but it should help quite a bit.

1 Like
6

Came here to say this.

You could also write an extension to set a custom property of the DYF with the active Revit version info when editing it. Come to think of it… @solamour why don’t we edit the save feature to include the host info as well as the engine info?

1 Like
7

What’s ensuring that the active version is a valid version?

8

This is a very reasonable request :slight_smile: Not sure if there are any major knock-on effects here (i.e. running the same graph in different versions) but worth thinking through!

CC @achintya_bhat

1 Like
9

Assuming if you’re authoring it the active version is what you’re authoring for. If it doesn’t work there then it almost certainly won’t work in another build.

10

Yeah that makes sense, but I think a lot of authors will be publishing and updating from Sandbox since it’s faster than opening Revit just to publish a package. It’s an easy fix for the situation you’re describing, but it still only covers one scenario. Everything to make this process more streamlined (or better yet, automatic) is greatly appreciated. I just think there are a lot of holes still.

2 Likes
11

Absolutely doesn’t plug all the holes - in fact I see it as a stopgap for now. I know a lot of packages with significant use that are provided by professional development teams (won’t name names) that don’t provide compatibility information so we’re going to deal with the gaps for awhile still.

This is aimed at the dyfs and dyns though, not the packages, so it’s patching a different gap in my mind. Case in point - imagine you had “my awesome custom node.dyf” and “my useful graph.dyn” which don’t run in Revit 2027 due to some API changes. But you’re not even sure what the node should output. You can debug the DYN easily enough as the nodes return warnings… but the DYF just outputs null as the warnings on nodes therein are supressed. So you open the node but there isn’t any wayt o execute, so you copy the contents to the active DYN and wire stuff in… execept the Python node no longer accepts lacing controls so you’re getting nothing but “list of object instead of object” errors so you have to start hacking apart the code in a way where you can revert it…

Or you could try to open the previous version. Start Revit 2026 and try the graph… it fails so you try 2025… 2024… 2020 and it finally works yay! But that was 8 guesses and Dynamo goes back 12 years now which is a LOT of Revit builds to open. If it had just told you it was last saved in Revit 2013… you’d be up and reviewing the logic a heck of a lot faster.

2 Likes
12

I see what you’re saying. The initial creation of the dyf (assuming it’s not ZT) would be done in a supported version. That seems like an easy first step. That also feels like a convenient check for package authors - the package manager should then know which versions are supported by the individual nodes being included in a published package.

13

Correct on all points. ZT is an edge case in and of itself - managing the version information is certainly a best practice there, and likely worth touching on in the Primer.

14

That also makes me think that nodes should just have more information available in their Help section. If “authoring version” is automatically captured in the node, it should be surfaced in the UI somewhere. The same could be done for Dynamo authoring version and Python engine.

1 Like
15

Lets hope this experiment helps

1 Like
16

Problem with Python engine is that you can have infinite Python flavors in the same graph - the list risks getting long fast. I suppose storing it as Scripting Engines: [] is a possibility, but it gets less useful as a result.

All of these values if exposed in the UI of sat the properties menu will need a read only flag…

I also think we should add a list of ‘contributors’ automatically by way of the user ID being added to a property storing a list in sequential order (maybe with date and some other info too?), but that has GDPR concerns so might be a no go.

17

That’s fair. I’m less concerned with graphs and more focused on nodes for this data though. I think that’s where we see the most value. Having that data stored in the dyf means you could easily write a graph or extension to surface all that information for an entire dyn if you wanted to.

1 Like
18

I would probably look at cross referencing the dynamo version in the dyf with the Revit versions and making assumptions from there. Even read the python scripts and see if those are api specific.

2 Likes
19

I suppose I would read the .dyf as a text and conclude from there, I would not like to try either, ask Autodesk to develop haha