Didn’t realize we’d have the conversation all ready, but discussing the cost/benefit of enabling selected 3rd party packages with the person managing the environment is the way to go.
As an example, let’s say that after you populate your buildings you wanted to generate the best paths of travel between 10 points on site. The VASA package can do this today in about 20 minutes of setup time (or less). Authoring something like that yoruself would take an order of 20 days if you know C# well, 40 days if you know Python well, and a half year if you don’t know either. This presents your company with 3 options, which we’ll quickly cost estimate by assuming every hour spent costs $100 :
- Vet and deploy VASA the same way they vet and deploy Dynamo and Revit and get the production time down to 30 minutes. This requires the infosec team do some work, but it shouldn’t take more than a half day total to get a ‘yes’ or ‘no’, and a half hour to do the deployment. The net cost is $500 on this option and you get an automation and some degree of support as long as the package author maintains support..
- Custom author the code and vet and deploy that. We’ll assume they can bring in someone who knows Python well but the infosec team still needs to review that custom code and deploy it so you’re at 40 days and 5 hours of time which costs $32,500.
- Don’t automate anything and keep doing stuff via manual picks and clicks. If this was viable you wouldn’t be here so no need to do the math, but we’ll quickly note that the sunk cost is infinity as every project suffers.
Now is there $32500 worth of value in not having the automation? If it’s a one time thing, no. But if it’s a one time thing you don’t have to lock your walls to the roof level automatically; Build a schedule and make the change manually. if it’s a 10x thing I’d argue the solution is the same. If it’s a 10000x thing then we’re certainly in the ‘do it automatically’ range of things, and certainly the cost savings justifies the infosec team to validate the package.
That said we can give some guidance all the same, just don’t set this as a blocker right off the bat.
The node requests a LIST of curves as the outline. Since you’re providing polycurves it appears to be trying to join them all together. Try setting the curve input to @L1, and if that doesn’t work try using a PolyCurve.Curves node and setting the input to @L2.
You might need an update to Revit as this node was added in Dynamo 2.16.
If the company is concerned enough about security that they are restricting packages but they haven’t yet deployed Revit 2023.1 it’s a bad sign. You’re exposed to at least one CVE that prevents malicious actors being able to execute arbitrary code as if they were Revit. If you don’t have this, you’re going to have to work out the offset in another way - you’re looking at a BIG lift for that.
The node doesn’t actually constraint the value, but sets it to the correct height. Might not be super clear though. You can see where this happens in the source code here: DynamoRevit/src/Libraries/RevitNodes/Elements/Wall.cs at 5baf61bef428ec5dd287f98ec94599a4d9e2c26e · DynamoDS/DynamoRevit · GitHub
Fortunately the “fix” is just two new nodes rather than a separate branch as you have it now:
The added time is likely negligible as it’s still in one transaction, but if you’ve got bindings in the file things will slow down so be sure to read up on Element Binding.