Confusion about lacing logic

I’m confused about what would cause this behavior. If you see the image below, in my head both of the branches should produce the same output. But one produces an error and the other does not, would someone be willing to explain the difference between using a list.map and running a lacing @L2.

Hello @jonah.peeleN2575 - Doing a mock-up of your data it’s working for me, so I wonder if your lines are coming in a funny way?

Are all your Object.Types correct? (List.Map will suppress errors). The error message looks like the Surface.ByLoft function is trying to be called on something that isn’t a curve input.

It should the same object types since the same dynamo edges are used for each branch. I think this behavior has only shown up in the Revit2024 dynamo installation and wasn’t happening in R23. For reference I’m using Dynamo v2.19.3.

the issue seems to consistent regardless of the geometry type. The one difference I can see is I’m using a transpose before my call. I’m not sure if that would somehow change the object type. The warning is pointing out that it is expecting an object array, but inputting an ArrayList[ ]. My instinct is guessing that an explicit cast is being missed somewhere.

Here is another example same issue, but creating nurbs this time.

@L3 with auto lacing on that nurbs curve example, and I think the loft one.

The node expects a list, so setting it to @L2 with auto lacing means it will go INTO that list so you’re passing a single point into the node which I think is that error - hard to confirm without seeing it though and I am lot at the CPU right now.

The warnings show what inputs were processed

I am not able to reproduce, which indicates an issue with your environment.

Which Dynamo build are you in?
Is it Dynamo Sandbox or an integration?
if an integration, which one?
Do you have any custom packages installed that are in conflict with your Dynamo build (i.e. a .net4 package in Dynamo 3.0 or vice versa)?
Any packages with their own list class?
Can you share the graph which is causing the issue?

This post and the following conversation may offer some insight. You probably have a package (or add-in) with some interoperability issues. Do all of your Lists come back as ArrayLists when you use Object.Type?

2 Likes

I had no idea Orchid could cause that. Removing Orchid fixed the issue.

2 Likes