You can start from the custom Engine provided in the example 05-00_base 2 Objects_scripted engine.gh, to avoid the hassle of setting all required inputs and outputs manually.

<aside> 💡 Remember to associate the Assembler.dll library to your scripting component and then save the Grasshopper file: . right-click on the component body, select Manage Assemblies and locate AssemblerLib.dll on your computer. Unfortunately this operation must be done manually for each computer, since Grasshopper relies on an absolute path to find the library.

</aside>

<aside> 💡 If you use custom methods for Sender and/or Receiver selection, set the corresponding selection modes (Sender and/or Receiver) in the HeuristicsSettings component to -1

This custom mode is not exposed in the tooltip to avoid misuse from non-expert users

</aside>

Inside the Engine Scripting Component the structure is the following:

Custom code

• 0 - Input Sanity checks - hey, this part is on you, master programmer! Some code is provided, but if you want to catch more sophisticated errors, write your own traps.
• 1 - Reset and Initialize protocols - input casting to appropriate types (AssemblyObject), a call to the Assemblage class setup, in case of first execution or if a hard reset is called
  • 1.1 - assign to the proper delegates your custom methods for sender and receiver value computation and selection criteria (4 methods in total)
  • 1.2 - initialize the Assemblage (first round of compute values)
  • 1.3 - reset Settings check - re-initialise settings without losing the assemblage
• 2 - Update
  • 2.1 - check World Z-lock flag
  • 2.2 - call the Assemblage class update if “step” or “go” are active
• 3 - Output - output the Assemblage and a count for the number of objects

Custom additional code

• persistent variables: Assemblage, AOset, AOprevious objects, a boolean to make step possible
• your custom methods methods for sender and receiver value computation and selection criteria
• any other custom method and/or persistent variable that you want to be stored in the component as the assemblage grows (i.e. store solar radiation analysis, structural calculations, etc.)

Since the nature of Assembler is iterative, you can add functionalities like iterative analysis (ex. solar, structural, etc.) using external plugins (such as LadyBug, Karamba, etc.) in a couple of ways:

• using the plugins libraries and calling them from inside the custom engine (preferable)
• using standard component and definitions from the other plugins and put everything inside an Anemone loop, using a custom input for the updating data as a live variable update for Assembler - although this is possible (see for instance the Karamba and Kangaroo examples at the bottom of this page), it is not recommended as it creates difficulties in managing calculation overhangs and maintaining a coherent Anemone loop update

https://discourse.mcneel.com/t/combining-karamba-and-anemone/140542/4

https://www.grasshopper3d.com/group/kangaroo/forum/topics/kangaroo-inside-anemone-loop-to-change-geometry-during-simulation