Showing posts with label Bug. Show all posts
Showing posts with label Bug. Show all posts

Wednesday, August 05, 2020

Ramp Slope is Still a Second Class Citizen

Wrote about this before in 2013. Ramps and the Slope Annotation don't like each other. In the past we could work around their unfriendliness by dragging a working slope annotation from an adjacent floor to the ramp. That no longer works since as far back as 2019.

I'm reasonably sure Ramps have a slope... odd that the annotation doesn't think so? I wrote another post in 2013 too that describes using an adaptive point family to add some graphics to a floor posing as a ramp which might also permit using the slope annotation on it instead. Yet another thing to experiment with.

Then again it might just be better to ignore the ramp feature entirely in favor of Floors?




Thursday, April 28, 2016

Revit 2017 - Associate Family Parameter Tool Tip

It's the little stuff...

Revit 2017 is missing the tool tip for the Associate Family Parameter button that it took awhile to get. Now it's tool tip-less again.


It makes me sad for that little sneaky button :(

Sunday, April 17, 2016

Orientation is not Managed by View Template

When we choose to assign a View Template (VT) to a View, that makes the template the view's boss. It takes over control of each setting we choose to make it enforce. In this image notice the parameters that are gray, not editable?


Those are being managed by the View Template. I've got to edit the VT to change one of those parameters or use Enable Temporary View Properties to override them briefly.

I noticed yesterday that the Orientation parameter does not behave like other View Properties even when a VT thinks it is in charge of it. This is the VT's dialog showing it is currently assigned to Project North; we can choose either Project North or True North. The check in the Include column (on the right side) indicates we want the VT to take over.


Therefore I find it counter intuitive that we can still interact with and change the Orientation parameter in the Properties Palette even though the VT is in charge.


If the VT is changed the view will follow along as expected. I wouldn't expect to be able to change it back in the View's properties with the VT in charge, but I can. This means the Orientation parameter is affected (managed half-heartedly) by a VT but it isn't truly in charge of the parameter, not like it is for other parameters.

It is inconsistent, perhaps a bug?

Friday, January 08, 2016

Text Box Boundary Quirk

I read a thread at AUGI describing an issue where the Show Border option to create a box surrounding text fails to completely surround the text it contains. First, if you weren't aware of it, each Text type has a type parameter called Show Border.


The Show Border feature worked fine until I used the Underline override to put a line under the NOTES: heading. It also happens if I use any of the other overrides; Bold or Italic.

I created the following video to show what happened.



Seems easy enough to resolve, just use separate text for the heading. Unfortunately I found that Show Border fails to work properly if the text is altered later too. Just adding a new line to the text is enough to confuse the border/box. Sadly this means the concept of Show Border is fatally flawed...

Wednesday, January 06, 2016

Doors and a Sliver of a Room

Following on my post yesterday regarding Doors and Rooms, if you happen to have a room that is NOT at least 14 inches deep you will find that Revit is unwilling to report either its To Room or From Room parameter. If you've been reading this blog a long time you may remember a post I wrote which included a short video that mentions this issue?

A room like pictured below will work because it is 14" deep.


However the room pictured below won't be recognized and the corresponding parameters will be blank, in this case the To Room parameters.


If you are familiar with the Room Calculation Point (I call it RcP) feature it can be used to influence this issue.


Keep in mind it will also negatively affect which room you can regard as the To Room, if not for this door specifically any other doors that need the opposite behavior.

The Room Calculation Point (RcP) feature was added to doors to provide a way to change how the To Room assignment is controlled. Originally the To Room value for a door was (still is without the RcP being enabled) decided based on the side of the wall the door swings in toward.

There are doors which must swing out of a room but still belong to the room they swing from. For example a classroom's door (like shown in the images above) often swings outward to the corridor (often set into an alcove), for exiting requirements usually. However we still think of and document the door as belonging to the classroom, not the corridor.

If the door is placed so that the panel swings into the classroom (using stock doors) then the To Room parameter is assigned to the classroom. If we then flip its orientation so the panel swings out of the classroom the To Room value remains associated with the classroom (check out the post I mention above for a video of this behavior).

The RcP feature changes that behavior to alter the To Room value to follow the flip of the door orientation regardless, which means in my example, and the images above, the To Room value would change to reference the Corridor instead.

May you have sliverless designs...

Tuesday, February 10, 2015

Revit MEP - Detail Callout Bias or Gotcha

Many of Revit mEp families use a nested annotation symbol to provide the standard graphics we are used to seeing in electrical documentation. Here's a little example of a few of these families.


If you created a Callout view and these symbols vanish my bet is that you've used a Detail Callout. Here's what a Detail Callout view of the same families looks like.


It's definitely a quirky thing, but these nested annotations in outlets don't show up in Detail Callout view. Feel free to start trying adjustments to Visibility/Graphics, Detail Level, Discipline and more...I've been down the road already. I'm pretty sure we're looking at a bug, or at least a conundrum brought about by the way these nested annotations work.

This view type is also fussy about creating other elements, like a room/space for example. As such I understand that this view type is intended as the last stop or end of the road with regard to drafting up a detail, for detailing not modeling with. It's just odd that these annotation elements won't appear in the view.

If you want an enlarged plan to show these annotation then avoid the Detail Callout, use the Floor Plan type instead.

Thursday, October 06, 2011

Assigning a Dimension Oddity

Received a question via email asking why Revit seemed unwilling to assign a Shared Parameter that used the Duct Size type to a dimension string. Here's what the SP properties looked like.


The quirky part assumes that you want to select a dimension string and then associate it with the SP. This is what happens when you do that.


I've recorded a brief video to show the result too.


Wednesday, October 28, 2009

Dept. of Bugs - RAC - Structural Settings Missing

It appears that the new Subscription Advantage Pack has hidden the Structural Settings dialog. Prior to the update it was located on the Structure Panel on the Home ribbon tab. The update adds a new Ribbon tab called Structure, but no access to Structural Settings via a sneaky arrow at the base of one of the panels as might be expected.



There is no Structural Settings listed under Settings on the Manage Ribbon tab either. As a comparison, in Revit Structure there is a large button dedicated to this.


I think the Revit team is going to send someone out in a VW bus tomorrow to fix this personally. It's going to be called the Great VW Bus Structural Settings Fix Tour of 2009 or GVWBSSFT09 for short.

Wednesday, July 15, 2009

Spot Dimension and Underlay

Hiroshi Jacobs brought this item to my attention the other day. He also shared with me that he's been accepted to the Masters of Architecture program at Harvard!! Attaboy Hiroshi!! He currently works at RTKL in DC. Here's the issue.

There is currently a “bug/issue” (2009/2010) when you combine the use of these two features. First of all when you use the underlay feature you get to choose which Level of the project you’d like to add to your view as an “underlay”. The spot dimension tool lets us identify a point elevation or point coordinates on an element in the model.


In the image above you can see that combined they can have an undesireable result. The conditions for this are using an Underlay of a Level ABOVE the level of your current view and having a floor above in the same area as the intended location of a Spot Elevation.

When you place the spot dimension in an area where this underlay doesn’t compete for attention you get normal results. However when you put the spot dimension in an area where the underlay and its floor are present Revit will identify the spot elevation of the underlay, not the floor that it "should be" paying attention too.

Does tabbing permit you to choose the correct element? No it doesn't. If you use the Underlay Orientation: Reflected Ceiling Plan the Spot Elevation tool works as "expected", it does not "see" the floor above, if that makes any sense at all since the floor should be more visibleish? I'm confused...

Since I brought it up what happens when you switch between Underlay Orientation: Plan and Reflected Ceiling Plan? Let's see, watch the Spot Elevation that displays both top and bottom values for the underlay floor above. First with Underlay Orientation set to Plan.


Notice the values...now compare with Underlay Orientation: Reflected Ceiling Plan.


Does it matter if it is a floor or roof? Does the same thing for either. Interesting that the elevation values change depending on the Underlay orientation, increasing with the Reflected Ceiling Plan selection. Keep in mind that the floor is at Level 2 which is just 10'-0" above Level 1. I could understand the top vs. bottom display values switching places in the tag with the orientation change but not the elevation values becoming something they aren't.

Boiled down the underlay is “more important” than the current level’s elements when using the Spot Dimension tool. Keep this in mind when using the Spot Dimension tools and using an Underlay.

One more for the road: Spot Dimensions don't like Model Graphics Style: Wireframe. The tools won't "see" the surface unless you change to one of the other choices like Hidden Line. You can switch back to wireframe afterward and the values will stick. This is from an earlier "stump the chump" question and the answer.

Friday, May 01, 2009

Bug - Structural Columns - Paste Aligned

When you work with Structural columns you have the option to define them according to their Height or Depth relative to the level you are working on. This is in response to the fact that Revit used to only place them according to Depth and that was frustrating for most users. Having the choice is good!

When you want to propagate a Level's columns to another Level or Levels by using the Copy to Clipboard followed by a Paste Aligned - Select Levels by Name technique...you don't get a choice. Revit's code places the new columns using Depth regardless of the fact that you placed the originals using Height.

If you aren't careful you'll likely end up with a warning like this one.

Now the programmer will take issue with the "bug" designation because it works as written. True or not...it doesn't work the way I'd expect it to work.

The solution? When you use Paste Aligned, remember that the Level you are pasting from and the one above it should not be selected because the next set of columns above will be starting at a level and using a Depth placement logic instead of Height. Here's an image of the Paste Aligned Result when I select Level 3 for destination even though I selected the columns on Level 1 as the originals.
It is interesting that skipping Level 2 in the selection process produces a column whose Instance parameters end up "correct" though.

Unfortunately this image is from 2010 and that means it isn't "fixed" yet...and yes this is an "oldy" but not "goody".

Wednesday, April 29, 2009

Echo - IE8 and Revit = Not Good

David posted this on his blog after bumping into the issue himself and discussing it with support.

“Thank you for choosing Autodesk Support.

Internet Explorer 8 is not recommended to be installed when used with Revit 2009 64 bit. There is a known issue with the recent files screen. The Recent Files menu is an HTML based window and uses Internet Explorer and has not been designed to be used with IE8.

IE8 is also not recommended to be used with Revit 2010 as it has not been designed or tested with it. The same problem does not exist with the recent files screen in the same way but it is apparent that if you have the recent files window up and TAB+CTRL between your windows while using 64 bit and IE8, it will crash. You can use IE8 if you do not have the recent files window open.”


I know that I really don't care what IE is doing because I've been using either Google Chrome or Firefox for quite some time. The only time I have to use IE these days is when some embedded IE/Autodesk feature doesn't work in them. I hope that it doesn't become an installation requirement at some point to use it in order to use Revit etc.

Friday, November 07, 2008

Revit MEP - Heating and Cooling Loads - Isolate then Cancel Bug

Using the Heating and Cooling Loads feature choose to Isolate a space in the viewer.

You can crash Revit if you click the Cancel button before removing the Isolate option.
Want to cancel unscathed? Just make sure you uncheck the Isolate Space option FIRST!

Wednesday, August 13, 2008

Schedule Data Entry - Bug? Wierd?

Lately I've been seeing a recurring issue that could probably fit under or in my Dept. of Subtle. I need a bit more evidence to be sure it is a bug, though my "gut" says it is.

While editing a schedule and clicking in a field to type something I find that occasionally Revit won't let me enter anything. I've seen this on student computers at several offices and it happened again to me today on my new Laptop. The computer brand and configurations have been all over the map so I don't think it is a specific computer hardware sort of problem, though I thought so at first.

In order to resolve it I find that I must use the "Home" or "End" key to force Revit to move the cursor "into" the field. When I do that all is well for some period of time. It happened twice in one day but then not again. Wierd, strange...odd. I say all three.

If I get any more corroboration it would be useful to get some support requests looking at it.

Wednesday, July 16, 2008

Egress Math Error - Bug Report

For those who have downloaded the latest arc egress example, sorry! David Baldacchino pointed out a math error in my work. I've fixed it and have posted new files at the site again. I also tweaked the schedule formatting a tiny bit.

Download the fixed (project file) 2008 version CLICK HERE 2008 (792 kb)
Download the fixed (project file) 2009 version CLICK HERE 2009. (936 kb)

Download just the 2008 arc Family CLICK HERE. (188 kb)
Download just the 2009 arc Family CLICK HERE. (232 kb)

By the way, David provided me with an example that includes the arrow and dot but they can't resize with scale change so I haven't included that...yet.

Tuesday, June 24, 2008

Dept. of Subtle - Dimension Overrides and Openings

Hiroshi Jacobs shared this with me today. He came across it and thought I'd find it interesting. I did and do and figured I might as well share it and let him be my guest writer today! You may be familiar with Hiroshi already, or at least the little Revit site he started with his brother...you've heard of RevitCity right? He currently works as a designer with RTKL.

Here is what he wrote:

If you dimension both sides of an opening family (door, window, etc.) it won’t let you append a text value above or below the dimension:


Notice the 4’-0” grayed out in the below box? Well that is the height of the window being dimensioned… There is a checkbox parameter in the dimension style type properties which allows you to show the height of the opening family in the dimension string.


That’s cool, but what if I don’t want to show the height, I want to add “R.O.” below the dimension string – I can’t unless I dimension to something other than both sides of the window.

Thanks for the info Hiroshi!

Monday, January 07, 2008

January 2008 Leap Year Bug Update Available - New Build 20080101_2345

From a post by Scott Latch, Revit Architecture Product Manager, at AUGI's forums.

I am happy to announce that Autodesk has fixed the “Y2K8 bug”!

We just posted a new build (20080101_2345) of Revit Architecture, Revit Structure & Revit MEP that fixes the problem. It is still considered Web Update #3 because replacing the existing file was the fastest method of delivering it to the public. Therefore, the executable file names are the same as the previous build (20071102_2345).

We have updated the Web Update Enhancement Lists to add the following items:
Improves stability when editing groups, saving views/groups to the library or creating a new project with template set to “None”.
Improves stability when upgrading or linking a project from Autodesk Revit Building 8.1/Revit Structure 2 or older.


I would also like to inform everyone that we are only releasing this fix in the English version. Because of the time necessary to localize the update for the other languages, it would not be ready before February 1, 2008 when the problem will go away.


The Web Updates can be downloaded by going to:

RAC: Revit Architecture
RST: Revit Structure
RME: Revit MEP

Thanks to everyone for their patience while we work through this problem.

Thursday, October 25, 2007

Egress - Path of Travel - Uh oh...

Of all the stuff I've done over the last couple years the Egress/Path of Travel family has to be the biggest hit. It has generated more email requests than anything else. I'm glad I've managed to do something useful!! If only I charged money for it! 8-)

So I'm writing to let anyone who has actually used it that there is a bug present in Revit right now that messes it up. The little dot and arrow at the end of the line-based segment won't print as filled in the latest build of Revit. If it doesn't work in earlier builds no one has said so and I can't test it on any earlier builds now either. Don't look back...keep moving forward...new build...well in this case it is a slight step backward.

The "fix" according to Revit Support staff is to print the views that these are used in using "Raster" instead of "Vector". Phew...that was close, I thought I was going to have to come up with a different strategy for those little guys.

Hopefully the bug will be fixed in a future build. For what it is worth, this most likely affects any nested annotation symbol that uses a filled region.

Thursday, July 19, 2007

Image/DWG Import Issue

My friend David Baldacchino recently shared this with me and I can confirm the problem. If you link a dwg file that also contains an image file into your Revit project, Revit will crash when you save the file. You can link it in, but Revit will crash when you save. Ouch! This happens whether you save the dwg file in either 2004 or 2007 format. Tread lightly if you need this combination...good luck! If anyone has encountered this and found a way to defeat this feel free to share in a comment. Be certain to submit the issue to Revit support at Autodesk!