Hey @jean !
Great package Quasar! A lot of useful things!!
I was giving a try to the ViewUtility.ElevationInRoom node and it seems to work pretty well, but it seems like all the views cut all the rooms short in height.
Do you know why this happens?
I tried to have a look at your repo to have a look at the code behind it but I can’t find the specific node.
Thanks,
Andrea
Thanks @ATassera, views cut height are adjustable with the offset parameter value, like as example below; and ZT Nodes repo is here
Thanks for your reply @jean !
The offset would create an homogeneous offset around the original crop of the view, so in order to get the height of the view correct I would have to set an incongruous offset that would probably be too big.
I was looking at the code. Is the reason why all the views get cropped too low this line maybe:
BoundingBoxXYZ bcrop = Utility.crop_box(bbox, Offset / 304.8);
I really don’t understand where that number 304.8 comes from.
Thanks for the help,
Andrea
@ATassera if you want shorter (than your room height) views you can provide minus offset value like " -200 " …
@jean sorry for the misunderstanding.
What I’m saying is that the room elevations are coming out shorter from your dynamo node (see the first image I posted above - the elevation has the correct width but a shorter height, hence the top of the room is cut out by the crop box). What I want is actually the view to have the same shape of the room with just an homogeneous offset around it. But, reading the code, it seems it doesn’t depend on that.
That’s why I was wondering if it was happening to you too that the ViewUtility.ElevationInRoom node generates views that have the correct width but the wrong height (again, like in my image above).
@ATassera, Elevations views’ crops are shaped based on the room boundingbox’s max and min values.
On top of that, desire offset will be applied. Which means if you use offset value " 0 ", view crops will be the same shape (height and width) with the room. One of my concern is the unit conversion because, in my node, I have already divided by 304.8 assuming that the project unit is millimeter.
Anyway, I will check again, is this node really have an issue or not?
Thanks mate, have a great day.
Thanks mate!
Let me know what you find out and have a great day you too 
Hi Jean,
Just noticed something with the view ViewPortAlignment. If there isn’t matching views and legends it can use the location of a legend for a view. Highlighted area below is where it put the view. Awesome node otherwise.
Quasar View Extension on Dynamo Version 2
Quasar Package version 2.x.xxx offers a view extension to organize the scripts. Upcoming features are under development. For now, please do enjoy as so.
The CopyLevelAndGridFromLinkedDocument node works,but if the code is run more than once, it copies the levels and grids again.
Can it be updated so that it doesn’t copy anymore once there are already grids and levels?
hi @Revit_Noob, thanks for trying out. My answer is if you’ve already successfully copied why do still need to use this node again.
in reality i will not of course, but it may happen 
just testing out the code
I’ll toss a good reason out there:
Let’s say the source file was updated as the design team made a change in floor to floor height to add another level.
If Dynamo maintains ownership of the Revit elements you can update the levels and elements / data built up on them by opening the graph which created them, and hitting run a second time.
See here for an example: Element Binding in Revit
Hi, Jean
I use Quasar create an element filter, but the DropdownSelection just output one list that is the last one selected. The DropdownSelection can output a list like a filter input list.
hi @zhao.zp, I do appreciate your feedback. May be, return a dictionary … like this:
{ "title" : [ "selected", "items" ] , ... }
Yeah~ but with another issue, When I frome the selection of the second of the last return to the third picture option that will show the option is empty.
nice one, thanks for the info … Let try it out later.
