I tried the detail component on the fly. In this example, it’s equivalent to flattening all the inputs, curves, family types, and views one-to-one. Though generating many duplicates of family types and views isn’t necessary. More refined control can be achieved in terms of data structure and loop logic. If it were me, I’d call it a day once I got all the detail components. Forget about the technicalities of certain nodes. @bvs1982
doc = DocumentManager.Instance.CurrentDBDocument
uidoc = DocumentManager.Instance.CurrentUIApplication.ActiveUIDocument
curve_cols = [c.ToRevitType() for c in IN[0]]
symbol_cols = UnwrapElement(IN[1])
view_cols = UnwrapElement(IN[2])
detail_components = []
TransactionManager.Instance.EnsureInTransaction(doc)
for curve, symbol, view in zip(curve_cols, symbol_cols, view_cols):
d_com = doc.Create.NewFamilyInstance(curve, symbol, view)
detail_components.append(d_com)
TransactionManager.Instance.TransactionTaskDone()
OUT = detail_components
I don’t know if we are talking about the same stuff in this regard.
I am not duplicating anything, nor do i want to.
I have X Floor Plan Views and i need to place Line Based Detail Families over
the Walls from the Linked Model on each Floor Plan View.
The Line Based Detail Families can be different depending on
the Wall Type in the Linked Model.
Your code doesn’t work for me, thanks for the help though (because ).
Flattening won’t work no?
How is Dynamo supposed to know which Line Based Detail Family goes
on which Floor Plan View like this?
I still wonder what big the difference is with this node (the one on the right in the image ),
other the Line Based Detail Family vs. in Project Detail Line.
The example I posted is with multiple views. It might be worth posting a small example file with just a few curves on just a few views. Again, it’s hard to tell exactly what’s going on when you keep going back and forth between examples. I know you want it to work with your specific scenario, but if the structure works on a small scale it will work on a large scale.
My other inclination was that one of your views is invalid for the curves you’re providing but if you’ve confirmed each view and set of curves works independently then that’s not the case.
The one true option to ensure this works is to use the API like @BimAmbit is suggesting. Then you’ll be able to code everything to your exact use case.
I thought i was pretty clear. And my examples never really changed, only the sample size.
As i am not into the API / Python yet (still… i know )
I (already excepted) that we have to do it Floor Plan by Floor Plan, which is fine .
I just hoped for a solution.
Thanks everyone for trying to help .
I mean upload an actual file that we can replicate your case with. We understand what you’re trying to accomplish but you have to understand that there will always be a disconnect between you executing your graph and us only being able to see what you’ve run/posted. We’ve already shown that it’s possible with your nodes and structure. If you’re still having issues then we need to be able to replicate your exact scenario.
That wasn’t clear to me. But will do, but i have to strip the files a bit, because
i am not sure i can share the original files. So i will upload a file next week.
Well partially.
I never got confirnation you got it to work for different (Floor Plan) Views.
It looked like you used the same View in your example.
If needed i can share the .dyn already.
Only thing you need to test it is a Model with a Linked model
with some different Wall Types and a Line Based Detail Family with a few types.
I need to clean the .dyn a little then.
EDIT
Just if anyone is interested in having a peek.
Only the Grey and Pink Groups matter. The Green part is working (for a single View).
The Pink Group is the part where this topic is about basically.
You have to change the Dictionary and have your own Line Based Detail Family.
I will upload a file which goes with the .dyn somewhere next week. DynamoBIM_EDIT.dyn (95.0 KB)
You can’t see the full name to see that they’re different but it’s just two duplicate views. I’ve confirmed it works. That’s why we’re asking for more information and the specifics of your Revit file. Sharing the dyn is a decent start but we need the dyn and rvt to recreate your exact scenario. We don’t know if the issue is with a family or a view or a package version or a setting. We need as much of your original environment as possible to ensure we’re not missing anything important.
Been keeping an eye on this convo… was goi g to keep out of it as I recall this node is problematic to use with lacing as the inputs aren’t strictly controlled but the Python expects them in an explicit configuration… But exactly what that is I don’t recall as the use case is WAAAAAAAAAY down on my list of priorities (drawing detail lines in bulk is usually a sign of a bad workflow in my opinion, so ‘knowing’ this has little value relative to my personal beliefs on the topic). @Nick_Boyts seems to have stated the required structure though - the input for curve must be @L1 to work.
I have also been busy today with job stuff (building so many generative layout tools that my head is awash in coordinate systems), and as we don’t have a sample Revit project replicating the intent to go with the Dynamo graph I haven’t had time to dig into it between tasks. Perhaps Monday…
Thanks for ‘intervening’. I will provide a sample
sometime next week. However i really think
my structure is fine and the problem is in the node. I tried like every combination of Levels and Lacing. But i am happily proven wrong
(after providing a sample).
FYI
I know (though they aren’t Detail Lines but Line Based Detail Families but same difference).
But using them is kinda forced upon us by our client.
).
)
.
.
.