Hide/compile Dynamo scripts from end users?

#1

Hello all,

I think the new Dynamo player is awesome!

However, the next step is to hide the actual graph to the end user.
Is this possible in any ways? That is, to prevent the Player’s user to actually get or view the dynamo graph?

For consultants, this is quite important when we need to deploy scripts to the clients’ offices.

Otherwise, is there a way to export the whole graph as code? like the “Node to code” command, but for the whole graph…?

Thank you

Regards

Gio

0 Likes

#2

The idea behind Dynamo is not to hide anything from others. If you want to “hide” everything, you need to code in C# as an addin instead.

5 Likes

#3

I don’t think it’s possible to “hide” a Dynamo file like that. You can make it Read Only so users can’t make changes, but you can’t keep someone from opening the file itself, especially if you’re handing it over to a client.

You can select your whole graph and use Node to Code but there are a few limitations - you can’t convert custom nodes and you can’t convert a handful of OOTB nodes either (they don’t have direct translations to DesignScript.) You can however deconstruct any custom nodes you use and try converting them, or just wrap the entire graph in a custom node. However, if your goal was to get rid of any custom nodes and only use DesignScript this obviously doesn’t help.

0 Likes

#4

No matter how tricky you will try to do it, it will be possible to reverse engine it. Unless it is coded in C# as “One” node, but then… why use Dynamo, make an addin instead.

1 Like

#5

What does that even mean?

I thought the idea behind Dynamo was to provide Revit with a graphical scripting environment, like Grasshopper, and we are still waiting.

You are saying that not only we (architects non programmers) need to beta-test Dynamo (this can’t possibly be a full release, right?) and spend entire days to put together 10 nodes into a working script, but then we need to give it away so that other architects and designers can quickly modify it, adapting it to other tasks, while avoiding to call us again?

I don’t know about this…

Not to talk about liability: you do not want to have some junior person messing up with your script and then make some serious damage to a large Revit project. Not good.

Thank you for the quick reply, though,

Regards

Gio

0 Likes

#6

Huh?

It can take a little while to get comfortable with Dynamo but eventually you’ll be able to do this stuff in no time. That’s part of the appeal of Dynamo - quick creation and modification of scripts on the fly.

I generally wouldn’t suggest designing scripts directly for other companies (except for firms who do this as a service). The point should not be to make your life easier by streamlining someone else’s work. Educate others when necessary but don’t do their work for them then not expect them to just walk away with it. That being said, another great thing about Dynamo is that it is open source and there’s a great community willing to share ideas and code to benefit everyone.

This is why I mentioned setting your nodes to read-only. Users will be able to run the node but not modify it directly.

2 Likes

#7

Offering a first open access to coding is probably one of the best feature of Dynamo and cannot be reversed. The solution would be to use it first as a learning tool and then to go a step forward, with Python for instance before stepping into C#. I am not sure since I don’t use it yet, but would it be worth it to consider using rather Revit Python Shell after a while?
http://chris-malcolm.com/projects/malcstools/p/revit-python-shell-vs-dynamo
PyRevit would also provide a solution for executing an IExternalCommand from a C# assembly instead of executing a Python script:


But this becomes highly technical and is far beyond me at the moment. Any comments are welcome…

0 Likes

#8

Sorry if I sound harsh here - I’m trying to open the eyes of several others who have expressed concerns with this type of stuff in the past and it’s hard to phrase this nicely.

This is exactly what it is. Many of the differences are tied to the differences between the two programs they primarily interface with - Revit and Rhino. So the advantages of Dynamo are due to advantages in Revit, and advantages in Grasshopper are due to advantages in Rhino.

As of now I am not aware of a means of distributing a Grasshopper graph/script which disallows users reverse engineering it.

It is absolutely a full release, and calling t a beta indicates that you either haven’t yet figured out how to use the software or that you don’t know what a beta release means. What do you feel is missing from declaring it a full release? Design the entire building cover to cover in 30 seconds so you don’t have to do anything? Should it do your timesheets each week as well? Please add some backup to what makes it ‘lacking’ so that the developers and the community can dedicate some time to making those types of features.

  1. If it takes days to assemble 10 nodes you are either doing something very ground breaking and above the likely limits of the built in stuff, or are doing something wrong and should run through the primer, cover to cover, skipping no exercises, prior to spending the effort.
  2. No one said you have to give anything away. 1/3 of my stuff stays in house. 1/3 goes to consultants. And 1/3 gets shared here in bits and pieces. Feel free to use it or anything anyone else posts here. If it’s that proprietary than feel free to keep it to yourself and go into business as a ‘send me your file and I’ll fix it’ type of firm.
  3. This statement sounds an aweful lot like the old ‘why should we give our CAD/BIM files to consultants?’ argument. Most who stood their ground on that hill closed up shop a long time ago.

Every task a junior users does in a BIM environment needs to be monitored, Dynamo or not. Everyone has had some junior user delete an entire level because the redlines of the detail sheets crossed it out… idiots are idiots. Heck even in the hand drafting days a junior user with some stickyback could ruin the master floor plan but that didn’t stop people from progressing. Watch and monitor their progress. It’s a tale older than time itself.

6 Likes

#9

Issues and related solutions could be different from one office to another, depending on its scale, internal skills, geographical location and competitors, and I am not sure that one discourse could fit to everyone. But the openess of Dynamo is something we have to compose with anyway, even if people don’t see immediate advantages in it. In some situations, it still represents a complete switch that is not fully understood and supported and the task may become unpleasant. The complete openess should remain a choice to fit everybody’s needs.

2 Likes

#10

@Giovanni_Succi

I get payed to educate the people we send our scripts to in our projects.
They ask me to explain in detail, and i love the responses i get.

"Wow…this took me ages… and see me now…"
Maybe my approach to this is different, but the most wonderfull thing I learned is to look at a problem and see the opportunities that problem gives you.
I am not just a modeler anymore. Giving means getting back. Love it…

Marcel

6 Likes

#11

@Giovanni_Succi
I think you have misunderstood what this community is all about. If you want help, it is expected that the relevant material is revealed/shared.
Writing that you think you have invented something so valuable that it must not be seen by others, made me reflect, that you should go elsewhere.
You cant hide dynamo graphs, that’s as simple as it gets. You can write protect them, but they will be readable. Only way is, to include nodes there are coded in C#.
That made me say that you should consider doing addins instead, since you would have the full control over that.
Dynamo includes some level of sharing, addin does not!

1 Like

#13

Yna,

I agree. Everyone has different situations.

This is why, for me, with the release of the new Player, I have immediately thought that the next natural step would be an option, somewhere, that allows to hide the script from the end user. Just for the Player.

I can think of numerous instances when I would want to deploy scripts to the team and prevent any editing of the graph, because, as BIM manager, I need control over what the team does, as much as possible.

If a client asks me to train in some basic scripting, that a different cattle of fish altogether.

Thank you

Regards

Gio

0 Likes

#14

I don’t know if it would entirely suit your needs but this discussion could interest you:


(I can see that some posts have been deleted over there since that time :slight_smile: )
Just to start from a common background, here is another one:

Now I will try let the specialists talk about that and silently follow this highly interesting discussion :grinning:

2 Likes

#15

Actually for most of us it does. You are welcome to be an exception but don’t plan on getting much out of it if you won’t put into it. The program and most of its contents are open source, are intended to be that, and will continue to be so. If you want it otherwise than perhaps try something else.

Keep in mind that you actually did come here to ask for input on this specific topic. The things @erfajo pointed out are very true, on point, and constructed in a way which allowed for a dialog around your alternatives.

I get that you want a way to keep people from touching your work. Sometimes I feel the same. I would guess that something like 20% of what I do doesn’t even make it beyond my desktop - not often finished but I made it work to a proof of concept. To have a functional means of doing this you can choose one of a few options:

  1. Never share your scripts and work in a silo. Just have the BIM team ask you to run the script, and have the consultant send you their model instead of sending them the script. Keep in mind this means that the community at large here and elsewhere won’t likely rush to help you out when you hit a wall with something beyond your skill set. Pit somethingg in if you want to get something out.

  2. Use something else to script or code. An add in isn’t editable. It can be distributed in a way which ensures you get paid for your work. It can require a password or log-in to run. It can even be time and/or path/file sensitive so it won’t run three years from now or on another job outside your server. This has been an option for you since the Revit API was introduced, and as a BIM manager you ought to have known that was the case prior to coming here. Note that the community built up around the development of that type of code has a similar ‘put something in to get something out’ mentality, often more so than here.

  3. Write a C# zero touch node for Dynamo. These function exactly like an add in, and as such will require you to work exactly like item #2. Ladybug and the space planning tools of Colin mccrone are examples of this.

8 Likes

#16

@Giovanni_Succi Do you know what does Dynamo means?

3 Likes

#17

As mentioned already, it’s not possible to compile a dynamo graph. But why compile a graph in the first place? This defeats the whole point of what Dynamo (and to the same extent, Grasshopper) is all about.

A graph is first and foremost a dynamic solution. You can change a single node, re-run the graph and get instant feedback. It’s the polar opposite of a static compiled solution. It can quickly be adapted to an evolving problem and grow together with your project. You can “debug” it fairly easily, because when an issue occurs, the problematic nodes hopefully get highlighted.

On the other hand, a plugin is pretty much a rigid black box that does something under the hood and produces a result in the end. As an end user, if you have a complex multi-step process, how can you easily verify the intermediate steps? You have to take the result at face value or do a ton of testing to make sure that waht you got is in the expected range.

And what do you do if you want something slightly different? If you’re lucky and have the source and the skills, you change the code, recompile, restart revit multiple times, re-deploy to all the users and so on and so forth… If you don’t have the code, or the original plugin developer isn’t interested in supporting you, you’re pretty much screwed.

Obviously, a graph’s dynamic behaviour comes at a price. You loose some performance, portability becomes more challenging and you may experience an occasional stability issue. But that’s life - you can’t have your cake and eat it too… If you’re not willing to sacrifice on any of those, then a scripted solution is not the right one for your workflow.

As a consultant, one of your main responsibilities is to inform your client of the possibilities, the advantages and disadvantages of each, understand the client’s needs and give your honest recommendation on the best course of action. You don’t nickel-and-dime them to death or you can be sure you’re never hearing back from them again.

If they’re paying you for a specific solution and not a one-time service, you better make sure that they get the entirety of what you agreed on and not just a mistery button that possibly just works. No sane person is going to keep working with you otherwise…

If you do a good job and if your client is smart, they’ll hire you again, ask to be trained or even offer you a permanent position. Remember what the I in BIM stands for. Your clients-to-be are now more informed than ever before. Our field is emerging into a new age and open and dynamic solutions like Dynamo, that try to empower the end user, have opened up countless new possibilities and have liberated a new generation of power users. Embrace it and you’ll have a place in that future or try and fight it and be left behind.

TLDR: don’t be a prick, treat your clients with the respect they deserve and you’ll get treated in kind. And if they do you wrong, it’s probably for the better not having to deal with those people ever again.

11 Likes

#18

Jacob, do not worry: the way you sound is absolutely irrelevant to me and to my questions about Dynamo.

My problems with Dynamo have to do with a few things:

  1. Tool-set: Dynamo has hundreds of nodes dealing with Lists, for example, and data processing, but a handful of native nodes dealing with drawing and modeling in Revit. They are improving, but it is obvious that originally Dynamo was built with more of a scientific background that Architects and designers should ever need to worry about. This is why in order to do the simplest things (that we need to do everyday) we have to resort to hacks, workarounds, custom packages and the advice of people who do mostly programming and scripting. Grasshopper is much more tied up with the nature of Rhino, that is, geometry and modeling. Also, it is more intuitive and oriented to designer; it is much more polished and refined. This has nothing to do with how Rhino and Revit differ but rather it has to do with product design, and the fact that Grasshopper has a longer developmental history.

  2. References: Dynamo lacks of complete reference manuals. Nowhere is there a complete documentation on Dynamo nodes, their data structure, or DesignScirpt. Most waste of time is due to knowing that a node even exists, and feeding the ones you know with the wrong type of data. This happens because there is no documentation on data types: where do I find a list of all nodes returning or accepting a certain data type? Where is the reference guide with all DesignScript keywords and their use? If there was such a resource I would save 50% of my scripting time. When I learned Lisp for Autocad there was no internet, or forums. I was able to use it because I had a reference manual. When I needed to solve a problem I would go look at each and every Lisp command, its input parameters and its outputs, and I would find the one I needed. Alone. This is how I wrote a few thousands lines program that would automatize drafting long bridge sections for bullet train tracks. Dynamo, instead, is unlearn-able, right now, and require constant inputs from forums like this and empirical examples.

  3. The Search feature still works badly, and has scarcely been improved. Do a search for “Set Parameter”. Why do I get 200 nodes half of which irrelevant to setting any parameter? Why is the first hit “UV.ByCooridnates”? Why “Get Family Parameter” and dozens of nodes with “parameter” in the name (and at different position within the name) come before “SetParameter.byName” which obviously is the one we were looking for? The search feature is also a huge waste of time, because of its design and implementation. And this is just one example, this happens for most searches. And I can see you rolling your eyes: <<you cannot even remember “SetParameter.ByName”?>> And again, no, after six month I have used Dynamo the last time, I don’t remember exactly that node’s name and I should not have to memorize it because no one can fix the search feature.

So, yeah, compared to other tools in the industry (like Grasshopper) Dynamo still feels like a beta release, but I understand it is an opinion driven by frustration, and many of you guys cannot agree. Its fine, you don’t have to.

I will talk about BIM management and the needs to control what the team runs on the main Revit model another time, but it is obvious that you guys seem to live in a romantic progrmmers’ “Commune” that has little or nothing to do with real life BIM practice… lucky you, seriously.

Regards

Gio

0 Likes

#19

@all in here

a node that runs the graph from an url?
is it possible?
Packages have to be there im sure.

Marcel

1 Like

#20

Clearly you aren’t paying attention then as these nodes exist in spades. There are a few things Dynamo can’t do out of the box that Revit can, but those are mostly due to the limits of Revit, not Dynamo.

I agree this is a problem, but if you check out the dictionary and Dynamo nodes website and others, than I’m sure you will find almost all the basic stuff is completely documented 10x over. Most often other stuff which is not documented is this way as it was published into the community by the users themselves - not AUTODESK, but by individuals who aren’t getting paid for that effort.

Did your version of Revit or Rhino or Grasshopper or AutoCAD 2018 come with such a hard copy manual? Most every program I’ve used since around 2005 sends you to their website instead of their local help file. Your desire to learn how to use a tool which is very different from the one you reference means that you will need to learn a new way to learn. You and your company will both be better off for this.

I agree this is cumbersome. It’s one of the reasons I use design script instead of nodes 80% of the time now. I happen to know that the team is working hard on updating this in a release. In the meantime it is possible (and was coded by a designer and a few students in less than 20 hours) to make keyboard shortcuts for any individual node, even custom ones. This was possible for them to implement because it is open source, unlike early releases of Revit, Autocad, Rhino, Grasshopper, etc.

Remember this is still version 1. Early Grasshopper wasn’t really any better as I hear (though I didn’t use it).

Almost of us design and document buildings for a living. We aren’t professional coders by trade. We do use code to our advantage but you do as well. We ARE a community. We do share ideas, thoughts, skills, scripts, graphs, reference content and the like. We do this openly as we all feel we are infinitely stronger as a result of this exchange.

As far as the reasons a BIM manager would want to lock out a graph, this is the valuable part of the conversation and should be discussed. As I pointed out in my previous post, there are lots of ways to accomplish the ‘lockout’ which could be of benefit to you. Not knowing any specifics of what you are doing, how you are doing it, and who you want to be able to do it means we can’t give you the right solution for your case though.

7 Likes

#21

@Giovanni_Succi

At this time it is not possible. That’s the fact, and if you can handle it or not that’s another issue.

However, if your programming skills can solve the problem, it would be great for all of us.

0 Likes