Hi,
I want to declare a few variables that could hold a string for example, so that I can just type that variable in any code block without having to type the whole string every time. Is this possible, and if so, how?
Simply, in a code block somewhereâŚ
def st1()
{
return=âReally long string i donât want to type each timeâ;
};
Then use st1() in the code blocks throughout your script.
Have you looked at the design script language guide here 
plenty of good tips in there.
2 Likes
Thanks! I should really go through all the design script basics one of these days.
2 Likes
Yes replying to a 3 year old thread⌠@jacob.small - Ron Allen
Is there a way to assign a code block a variable with an input or a set then pick up those variables elsewhere like a traditional variable? I was following along with this <> on Youtube, and tried to store the âlogoâ and âDocumentsâ into a variable but didnât get values out from the code blocks on the other side. Looking at ways to reduce the looong connectors for âglobalâ variablesâŚ
Currently, this is still not possible. The only thing you can call directly is a function. If your variable is constant (between projects/runs/whatever) you could technically write it to a function and call the function. However, this workaround does not allow you to define the âvariableâ with an input - it must be hard coded.
2 Likes
A few options:
-
You can store the values by serializing them into the graph with a Data.Remember node. These can be picked up and put wherever. This would require you build the data to be remembered, connect the result to the input of a remember node for each use youâll have, run the graph, disconnect the inputs, run the graph again, and save the graph. You will have to manage and deploy this package to all users acordingly, and any âsave asâ before data was opened could cause loss of content.
-
You can declare a definition as @Nick_Boyts showed above. Convert all of your nodes into design script and return the final result in the definition. This would re-execute the entirety of the code each time, which shouldnât impact much for reading an image, but would be undesirable for reading the pixels.
-
You could build a custom node which returns the data you want, input free. This would require deploying and maintaining it as a package, internally or on the package manager. That will be much easier than maintaining raw code in the graph IMO. This will also require executing the entirety in each run, but could include a Remember node and creative use of âfrozenâ nodes in the custom node to combine the benefits of #1 & #2, with the easier maintenance, reduction of runtime and easier reuse. The package Generative Design at Hogwarts which I put together for AU 2020 did this a lot.
-
You could serialize the data into an external source, and read that in after the fact by Design Script or Python. Deserialization can be tricky, and concurrent file access could be an issue.
Maybe Extensible Storage?
Would certainly work as a location to store the data, but it would require a custom node or Python to access the content.
Iâve always been hopeful weâll see something like âTelepathyâ for Grasshopper built into wiring options one day. They use a send/receive node setup with a named list of variables. It would rely on a portion of Dynamo that can update components dynamically, so doubt a custom node setup would work. Grasshopper is âalways onâ so I appreciate itâs quite different.
Sharing just in case it helps give the dev team ideas. Might be of interest to @solamour as well.
3 Likes
Ah yes thatâs pretty handy! Telepathy is a bit different in that you see the collected variable but hidden wires are a similar effective outcome.
1 Like
Coolio - Then this will be in the next release of Dynamo 
5 Likes
@solamour
While yourâe at it, a workflow that integrates ML with point cloud Wall recognition, or Floor and so on, wouldnât be too hard after Telepathy 
Sounds as easier to me
5 Likes
Hah⌠that oneâs a little bigger than hiding a wire! 
But duly noted itâs a want.
4 Likes
I think half the AEC developer community is trying to crack that currently (the other half gave up). There are recognition models out there but none of them make it an easy process - need ML ability to use them I think.
1 Like
I find a lot of those focusing on that problem are hung up on the wrong thing. Meshing the objects on demand (ie: what MR applications do) and processing that into a lightweight start to your project and is likely to produce a more useful base data set for ML applications.
3 Likes
Yes I expect just forming a 3D mesh will be the formal version 1 approach we see hit the mainstream to their expectations. Many people are focusing on generating native elements which is a can of worms for every single category of element (e.g. wall thicknesses needing wall types, and the realisation walls are variable thickness due to construction accuracy/bowing etc.).
2 Likes
I see youâre keeping the pretty dynamo looks hidden away in the Daily Builds
On another note, itâs nice to see that hidden wires are being implemented. That should make the graphs much cleaner and easier to manage.
I hope there would also be a way to quickly check a list of connections to a specific node with hidden wires. Maybe it could be a separate list window when you right click on a node to âshow list of connectionsâ or it could be incorporated into a sidebar. Then clicking on the items in the list could zoom the screen to that node.
1 Like
Hi @sed07 - We are hard at work fixing a bunch of bugs and interactions with the Visual Refresh stuff⌠it wonât be stuck behind Daily Builds forever! 
We have plans to let it all out into the wild in the next release of Dynamo, all going well.
We donât currently have plans to ship in 2.13 an extension that does this, but what we are planning to come out of the box is as follows:
- Selecting a node with hidden wires shows a âghostedâ version of those wires, which you can interact with
- Output ports will have a context menu that enables you to interact with the hidden wires (Similar to the on-wire context menu we are adding)
- On-wire right click context menu enables hiding/showing of wires and breaking of connections
The extension is a good idea thoughâŚcould be a great addition from the community? 
If not, we can evaluate how the above lands and see if itâs needed.
Screenshot showing a ghosted wire ad the right-click wire menu:
Screenshot showing the output port context menu for said wire:
2 Likes
After my reply, I actually got excited and went ahead and downloaded the Daily Build to take a look at. Itâs pretty neat! Is there somewhere you guys accept community feedback from Daily Build testers?
I was able to figure out the wire stuff, but didnât notice that clicking on the arrow on the output did something.
Without going into an extension, I had a couple of ideas. Iâm not sure if they are something that you are working on already, but Iâll mention them anyway.
-
Maybe it would be nice to be able to select multiple wires in a more flexible way (like a window selection, but only if no nodes are also included in the selection), because right now if thereâs a lot of connections it would be a hassle to control each one individually.
-
Another idea would be to make the output menu have a second option to show wires, and maybe also add the option to select connections (which would show all the connections, not just the one for a single wire).
1 Like