Hide/compile Dynamo scripts from end users?


#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.


#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.


#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


#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!


#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


#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:


#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.


#16

@Giovanni_Succi Do you know what does Dynamo means?


#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.


#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


#19

@all in here

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

Marcel


#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.


#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.


#22

Building on Marcel’s idea, you could try this:

Do all of your coding in a Python node instead of using nodes directly. Or at least the important parts of the graph.

Store the Python code as a string on a website (access from multiple locations) or in a text file (local use only) placed on part of a local server which requires additional credentials to access.

Place a single Python from string node off the read file or web request node, and use some means of inputting the credentials to access the file/site.

EDIT:
If any of the bad monkey’s, or other powerhouse package managers ever do this with their work I will cry every day for the rest of my life.


#23

PyRevit can possibly do something similar, I could have quickly seen that on YouTube some months ago, I will try to check in which of the videos it would be:

Here are some good resources to learn Dynamo:

These links are related to nodes documentation:

These links are related to DesignScript:


#24

I, for one, won’t. Dynamo is about sharing, not about locking folks out. 'Nuff said.


#25

I tought i’d seen a post about a repository for working dynamo scripts…:slight_smile:
But the search isn’t helping me

Marcel


#26

Something like this?
https://dynamonodes.com/category/workflows/


#27

@Yna_Db

actually…no, it was on the forum
seen it on the Dutch Dynamo User Group aswell, the trello site
Marcel


#28

I think he is referring to a website that would allow you to run the actual .dyn without having to recreate it from a forum or ask someone to send it to you.