Alaskan_Son

No no no. Leave everything alone. You shouldn’t have changed the floor height or moved the roof. The only single change you had to make is the one I showed above.

As Joey alluded to... Terrain Specification>General>Building Pad>Subfloor Height Above Terrain That's exactly what the setting is for. It controls how the first floor sub-floor (absolute zero) is set in reference to the terrain elevation data (sea level).

I’ve had the same issue for years with a number of systems that utilize macros in schedules. My workaround is to shift the schedule back and forth real quick with the arrow keys or to use a recorded macro to do the same with a hotkey.

Once generated, Materials Lists are static. They are NOT connected to the plan anymore. If you make changes to the plan and then want to see a Materials List that reflects those changes, then you have to generate a new Materials List. Now if you want to keep from entering things like pricing information all over again, then you need to add the information via the Components Panel of your various objects (preferably at the Default level) and/or by utilizing the Master List (which you’ll just have to read up on).

I suggest opening the Help Files (via Help>Launch Help or by pressing the F1 key) and searching "Displaying Walls" because there are a LOT of nuances with how walls display depending on: Whether you're in a plan view or in a 3D view Whether or not the wall is a Pony Wall Whether or not the wall is set to Invisible Whether or not the wall is a Railing wall Whether or not the wall is a Foundation Wall and whether or not that foundation wall has a footing Whether or not the wall is an Automatically generated Attic Wall Whether or not the wall is on the foundation level Etc. That being said, in general, there are 3 basic layers and layer behaviors you should be aware of for basic plan view display of normal walls: Walls, Normal (or whatever layer you may have manually placed your wall on): This layer decides whether or not the wall is disaplyed at all. Walls, Layers: If this layer is displayed, the wall and all of its relevant layers (more on this below) are displayed based on the line style and fill settings in the wall definition (which may or may not be controlled by Layer). If this layer is NOT displayed, then only the Interior and Exterior surfaces (or extents) of the wall are drawn, and those lines are controlled by the layer settings (not by the Wall Definition). Walls, Main Layer Only: If this layer is displayed then only the Main Layers of the wall are displayed. If Walls, Layers is also displayed, then the line style and fill settings from the wall definition are used, otherwise, the layer settings are used.

To expand on and consolidate the advice already given by the gentlemen above: The line color and weight for those Top Edge lines is controlled by the layer on which the opening is placed. The line style for the same Top Edge lines cannot be changed. Its hard coded as a dashed line. "Openings, Header Lines" can optionally be used and the line color, weight, and style can all be set as desired but those lines are drawn at the Main Layer extents, not at the finish layer extents, PLUS that layer ("Openings, Header Lines") controls the display of Header Lines for all openings which usually isn't what we want. Unfortunately, you'll likely either have to manually overlay CAD to get what you want, or change your drafting standard a bit. I would suggest you send in a suggestion to Tech Support requesting that we be given more refined control over the way Top Edge Lines are drawn.

Contrary to whatever you might think you know, the real reason is because old Francois Mansard wasn’t nearly as good a manager as he was a designer. He ordered way to much roofing and not nearly enough siding.

@IvanCyr, A few quick tips/critiques: I would start by asking myself some more specific questions such as: What if the word doesn't start with an uppercase letter? What if the word is all uppercase? Don't forget that when it comes to coding these things, it's important that you consider letter case. Do I only want to remove the word (substring) if it is at the end of the string or do I also want to remove the word if it exists in the middle of the string? Do I want to only remove that specific substring or do I want to remove everything after it as well? What do I do if my string starts with the substring? The #String delete() method doesn't look for specific words. It looks for the characters you have listed. What you're telling Ruby is that you want to remove every instance of the capital letter V, every instance of the capital letter I, every instance of the capital letter E, and every instance of the capital letter W. This would change "West Wing Electrical Plan View" to "est ing lectrical Plan iew". Not really what you want. This one on the other hand is using a regular expression to keep everything except for the capital letter V and everything that comes after it. This means something like "Vaulted Entry Reflected Ceiling Plan View" would return completely blank, something like "Kitchen Version 1" would simply return "Kitchen", something like "Electrical plan view" would return unchanged, and that "Framing Plan View 1st Floor" and Framing Plan View 2nd Floor" would both simply return "Framing Plan ". This approach might get you what you want most of the time, but I personally think the code is pretty vague and not nearly specific enough to avoid undesirable results (that will show up when you're least expecting them of course). The .delete_suffix method wasn't added to Ruby until Ruby version 2.5. Currently Chief uses Ruby version 2.4. You can however use the .chomp method to delete a suffix like so: %automatic_label.chomp(" View")%which will specifically remove the word "View" when preceded by a single space but only if the string ends with that exact word (substring). Anyway, like I said, I would start by asking myself how I might deal with at least the various scenarios I mentioned above (that is IF they could possibly ever arise) and then write my code a bit more explicitly. If you're not pretty deliberate and purposeful with your coding you'll almost certainly end up with an unpleasant surprise at some point.

Yup, not only are there entirely different ways to label layout boxes and additional/different information that we have access to using those new label capabilities, but there have also been changes to macro naming requirements as well as the addition of NumberFormatter and Measurement Classes. Oh, and the added ability to insert code directly into text fields…just to name a few notable changes off the top that could affect the conversation.

For anyone reading along, please note that this thread is from 5 years ago and several version back. A good handful of things have changed since then.

Ya. I think that was their intention at one point but they found out so many of us use the feature still so they've left it in place. What I don't like even more than the inability to set those defaults is the fact you can't change a layout box to use Edge or Pattern Line Defaults after the fact. I feel like it should be a toggle right there in the layout box. I personally don't use Edge Line Defaults, but use Pattern Line Default all the time.

I personally use Pattern Line Defaults for almost all 3D views sent to layout. I like my pattern lines to be a lighter gray color with a zero line weight for most all color off views but I don’t want to change my Material Definition because I still like to be able to produce colored vector views with darker pattern lines.

Away from my computer but as I recall, those settings obey the last setting they were given during the Send to Layout operation. In other words, I think the “Default” (or at least the closest thing to it) is in the Send to Layout dialog. Again, that’s just from memory. It might be wrong, but it’s worth a look.

I'm not even sire what I'm looking at there. Those look like inverted dormers where the "dormer" is actually just an inset lower pitch roof with lap siding instead of shingles. Very strange. Can't advise without knowing what's actually happening there.

Whether the wall is displayed or not is controlled by the layer that the wall is placed on. Beyond that, the display is controlled by the Pony Wall Display settings for the Saved Plan View that you are using.

I personally wouldn't overthink it and wouldn't hesitate to just insert a standalone symbol inside an Opening for one off situations like this. Yes, it can be done in various ways with cabinets or doors but I don't see any real benefit in having to futz around with all those various settings and the typically undesirable plan view display. To show open and closed, just use 2 symbols placed on different layers.

Or is it possible that you're trying to snap to one or more objects that are part of a Block?

Object Snaps might be toggled on, but that doesn't mean the various types of Object Snaps aren't individually toggled off. Ares some of these that you need toggled off?

No. It’s a Furred Wall to avoid the room issue. And I agree. It’s the method I typically use as well.

You can also use the "Patterns, 3D Views" layer. The 2 settings are interconnected in that the one reverses the other. NOTE: You may have to click Rebuild 3D in order to see the results of using the "Patterns, 3D layer" as a toggle

3D>Toggle Patterns

@GeneDavis, there's actually more going on than meets the eye in that plan (and possibly other similar plans). It goes beyond improper calculation--in fact, it may not be a calculation issue at all but rather some other bug. Check this out... If you adjust the Fascia Top Height of RP-4 to match RP-5 then all your fascia will align. If however you open up RP-3 you'll see that it now has a different fascia height from what it was. Changes to RP-4 are affecting RP-3. Super weird for sure.

He just used a meticulously positioned 3D molding polyline.

of course CA (or Pella) should fix it. And no it’s not worth anything to me. I couldn’t care less. I don’t use Pella. For anyone who needs the macros to work NOW though, they can be patched quite easily as I’ve demonstrated.

I wasn’t even talking about that. I was just pointing out that there are at least 3 coding issues inside the macro. All but one can be avoided by not migrating and the other can be fixed by modifiying a couple of the label references as I did in the macro above. I hadn’t even noticed that each window type is using a different macro. For now, they can each be temporarily patched individually using the same approach I mentioned above.