Hide/compile Dynamo scripts from end users?

FAQ
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?

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.

29

nooo…

The trello site is about sharing.

Marcel

30

DynaWeb, maybe?

Edit: late additions to this thread:

1 Like
31

Yes kinda like that. I haven’t had much/any time to test it yet, though I have installed the package.

32

OK, but you probably won’t run any program from that site, or will you?

33

@Yna_Db

Yeah…sure i will

I got to know them in person, good guys…

Marcel

34

This site?

The more I learn from you guys the more I feel like I need to move…

Edit:
Link won’t host right on my phone. Hopefully you guys can see it.

35

Thought it was called DDUG…
Anyways, the question was or here on the forum, or on LinkedIn

new question…
would a website like that do any good…in general…
For the project i’m working on i guess yes, all scripts up to date and running on all computers for all team members…

Marcel

36

Yes, here it is, we can even see you:

2 Likes
38

Where is Conrad

39

ok time for a cleanup, way to cozy this

40

Here is a way to share Dynamo generated geometry without having to share code :slight_smile:
Irrelevant to Revit workflows though.

Geometry is converted to serialized binary stream data using Geometry.SerializeAsSAB and saved to an external file.

Deserialize

Generated geometry could be shared without having to share code.
For example, a designer could share a pattern (with no flexible parameters) without having to share the code that generates it.
This could potentially be incorporated into a workflow that generates Revit elements.

Code for this pattern had been posted here. Hiding nothing

6 Likes
41

@Vikram_Subbaiah

Did this with my apprentice…mesmerized and hooked for he rest of her life she is.
Had to uninstall packages tho…to make it work

In short and to round up…sharing this made someone happy :slight_smile:

Thnx vikram

1 Like
42

Except for the few All Elements of … nodes, most other nodes either have code equivalents or alternatives
It is very much possible to have your definitions completely in a code block. I do so most of the time.

However, it’s better done right from the start, at regular intervals, not just by ‘Node to Code’ at the end.

2 Likes
43

Hi @Vikram_Subbaiah

“However, it’s better done right from the start, at regular intervals”

Why?What would change if not done at regular intervals?

Marcel

1 Like
44

You can then avoid including nodes that don’t work with Node to Code
There are alternatives that can be considered.

1 Like
45

Doing so periodically has several benefits:

  1. It’s easier to debug issues in nodes than it is with code block. Commenting out lines with /* code here */ can help with that process, but it’s not often as effective as it can become difficult to review all the outputs.

  2. It allows for “pickup points” of nested functions which can be referenced again in other graphs. IE: How often do you want to use a filter by X where you have to call the same seven functions repeatedly? Why not open a sandbox copy of the graph and re-run the results?

  3. If something causes an issue down the line you have multiple points to go back to.

  4. It allows side stepping node to code issues such as all elements of category, and other similar ‘uncodeblockable’ items. @Vikram_Subbaiah beat me to this one.

1 Like