Sounds like a sizable amount of work. If you manage to get your package updated for 2025 it would be amazing though. I think I may end up reverting to 2024 for a bit since im so dependent on so many of my graphs. But hopefully packages catch up to 2025 updates. Progress is pain sometimes :')
1 Like
I think differently, and I assume lots of users do too.
You are right if you see Layouts only as Sheets, when you are in a printing process. But in Dynamo you are looking at Layouts as the tabs in the drawing, as the work spaces. So it should be possible to select the Model as a Layout, to draw geometry on.
When ignoring the Model tab, it is not possible anymore to use Layouts as reference to the workspace (or using workarounds as “null means Model” and apply that in the custom functions). But there are also no nodes to maintain Layouts as Sheets, so there is no reason to consider Layouts as Sheets.
For your explaination that it is not possible to make modifications to the Model tab, that’s true, but that logic must be applied in the intended functions. And some functionality can be applied to the Model (make current tab), but that is not possible now as node (without a workaround to set the CTAB variable).
That the documentation claims that Model is not a Layout, that contradicts with the AutoCAD API where the Model is in fact a Dictionary Entry between the Layout tabs.
1 Like
This is 10000% a discrepancy between the API and the UI, which i doubt will ever be addressed as it’d take a conceptual overhaul of sorts that I doubt users would appreciate.
That said…
I would argue that this is true for every reference of “model space” as a block too. As a former UI only user this took me awhile to wrap my head around, but eventually it made sense (in fact regular Dynamo didn’t even let it sink in, but poking at the DWG file structure via the API is when it clicked for me). We ahve to remember that users don’t necessarily comprehend the underlaying concepts of the API thanks to the consistency and intuitiveness of the AutoCAD UI. As such it’s on leaders in the community to educate new users.
THis might mean that @zachri.jensen or I have to say “model space is a block” in a forum post once every 20 days or so until the end of time, but I’m ok with that.
I do think it would be nice to refer to model space more directly than currently provided, and many nodes should have default input for ModelSpace as 99.9% of users are working there. Some of that might be addressed in 2025.1 but I working with 2023 for the time being.
I know the API and UI is not the same 
I was using it as a contra argument. If “Modelspace is not a Layout because the documentation says so” is true, then “Modelspace is a Layout because the API handles it that way” is also true.
From my point of view (as a user although I understand it from a programmer’s view too), referring to a space as a block is not user friendly, like you describe. So, I would rather refer to a Layout as working space, which went well in previous versions as I used a custom Layout object. Now it became available as Core object, but surprisingly the Modelspace is blocked.
That means, I cannot use the more convenient Layout as input node, or I must treat null as replacement for Modelspace, or I have to stick with a custom Layout object and loose the core connection, or I have to downgrade my nodes to accept a block instead of a Layout. That’s why I would like to see the Model as a Layout, which in my opinion is much more descriptive for users.
Anyway, it is extremely difficult to create a 100% user-friendly and clear usage of objects. That starts with small things: which category to use, when to start a node name with ‘Get’ and when not, and ends with bigger things. Each time I open my code, I also see things I would decide differently now 
@zachri.jensen
Maybe it’s not related as a bug but when a package have descriptions or node structure that takes a lot of width it seems that there is a limitation how much we can drag the library to the right. Maybe it’s as it should be or will it be a possibility to make it wider? I know that we can pan to the right as well but…
FYI.
I added “Set Rotation” and "Rotation ? " for labels to the roadmap as a need for C3D 2025. It was implemented in Camber package for 2023 (that not will be updated) and these nodes wasn’t added from in 2025.1 upgrade
2 Likes
At some point the node input descriptions just aren’t going to fit.
I can see a ambitious node author creating a new layer with all of the following inputs: [layername, description, linetypename, lineweightname, transparency, color, isoff, isfrozen, ishidden, islocked, isplottable, materialtypename, plotstylename, and viewportvisibilitydefault]. And if the library is made wide enough to show all of that there won’t be any screen left…
Well, that is a good and acceptable reason. I agree with you, it shouldn’t be that much information under the node name, instead it would have been better if it appeared if you hover over the node.
Of course the description and the inputs in the library doesn’t need to take that much space and of course we want big canvas to develop in, but who need a canvas when we have a lot of nice nodes 
3 Likes
Doesn’t it? I thought it was visible in a tooltip.
I couldn’t think of different node names because basically they have the same nodes. One with strings as input, the other with objects. I’ll review them next week.
1 Like
Well that was true, didn’t thought about that just saw that the description had enough space…, what I meant is that if it was possible to make the description shorter or maybe on two lines? (Probably not possible in the VS application but maybe how it is reviewed in the library?)
That is something I can’t change
1 Like
The problem is this is the same node name, so the overrides are surfaced to let the users who aren’t looking at tooltips know which one they want.
If one node was named ‘Layer.CreateByTypes’ and the other ‘Layer.CreateByNames’ things are much easier to parse out without the overrides needing to be displayed in a more reasonable manor. That or make the Layer.Create with only a few required inputs (name for sure) and then allow nodes to set the bulk of the properties after the fact.
1 Like
No, not really and I got another error message than you when I tried to export the solids I created from text using the Civil Node Model text
I also tried to possibility to select the solids and export them separately in a separate graph
1 Like
We can test these scenarios if you’re able to share the datasets. Feel free to email or DM me.
1 Like
Update:
Adam was nice enough to update Sheetset Manager for 2025 support: Request to Make AMR Sheetset Manager Package Work W/ Civil 3D 2025 · Issue #8 · AdammReilly/AMR_dynSSetMgr · GitHub
2 Likes
I’ve been looking forward to this, and I’m happy to see this go live finally!
I’m looking at the script I’ve made before with Civil3DToolkit and found that there does not seem to be a node compatible with BlockReferenceExtensions.GetGeometry. Combining Object.Explode and Object.Geometry perfectly works as a workaround, but it would be nice if we could use Object.Geometry for BlockReference as well.
There is a Block.Objects node available (also before 2025.1):
That should do the trick.
I wrote a blog once, where I took the geometry from an XRef (which is also a Block) with this node. It is written in Dutch but there is a nice translate button on top:
1 Like
I don’t believe this works as well for Dynamic blocks. Am I missing something?