Alaskan_Son

I would call that a bug. Not sure if there's any way to stop it from happening and still leave Auto Roof's turned on, but in case it helps you find a solution, here's what's happening: Notice how the overhang is changing to match the baseline offset for the lower pitch roof plane. If you give some sort of buffer such as a short section of perpendicular hip wall to help disconnect the gable wall from being controlled by that railing wall, you'll get more expected behavior:

Definitely not possible with a single roof plane. The answer to your question is actually right there in the name. Its a roof plane (a flat surface on which a straight line joining any two points on it would wholly lie) and the roof being described above is anything but. It can only be modeled with multiple planes/faces. The trusses on the other hand are completely possible. That's one of the main benefits of using roof planes instead of Faces or the Terrain tools: That being said, you could also optionally change the roof pitch several time (once for each and every truss), generating new trusses after each pitch change in order to get your trusses. Once you had the trusses generated you could then use whatever method you wanted to model the rest.

Multiple roof planes pretty much exactly as Gene described. You essentially need to create a wire frame of using the ridge, the fascia, and the rafters. You can fill it in with either Roof Planes or Faces. You can also optionally play with using a Terrain. You may want to check out this thread:

Are you talking about something like this?

I can definitely help provide you with a system for this. Looks like you're right down the road. Let's get together and we'll set you up with something.

No. They're completely separate plans. We were simply discussing issues related to dealing with 2 plan files that happen to share the same name.

You'll have to manually add a callout or text box with the %room.schedule_number% macro in it to each room. You can also add the %schedule_number% macro to your room label, but I don't like that option because it grossly limits your formatting options for that portion of your room label.

A Room Divider set to NOT Invisible will stop the started tread from generating. It may however start casing issues with any wall mounted grab rail.

I don't think the OP has any issue understanding how to control wall materials. A wall's Materials are driven by the Wall Type Definition. Whatever material is being used in the Wall Type Definition is the Default Material for that Wall Layer. If a wall is painted using the Material Painter or if one of the surface's Materials is changed in the Wall's material tab, then that particular surface will no longer be using the default. This is all pretty basic stuff. What the OP is specifically asking about is something else entirely: There are settings in the Material Defaults for "Walls (Exterior)" and for "Walls (Interior)/Soffits" that don't seem to have any affect on walls. That's the issue being discussed. It's really an unusual default setting because it doesn't actually seem to have an effective place in the hierarchy.

Your room has no ceiling finish: ...and you don't have any manually drawn ceiling planes in the plan either.

This particular issue perplexes me as well and it’s something that keeps me awake at night every couple years or so. I feel like I’ve figured out more of the nuances on a couple different occasions but as of right now, I only know a few things: 1. The Interior Wall material setting is used for the automatic stair enclosure walls on interior stairs. 2. The Interior Wall material setting is used for library previews. 3. Both Interior and Exterior Wall material defaults are assigned to the Rooms’ Materials. I seem to recall figuring out when these kick in at one point, but I can’t remember anymore. It may be that they no longer do what they once did, or it may be that it’s only under the rarest of unique circumstances that they do anything, maybe in those odd scenarios where Chief needs to fill in an area automatically and there’s no clear wall to use as the basis. I don’t know. Maybe I am simply misremembering and I’ve never figured it out, but I absolutely seem to have some memory of certain exterior walls on some covered entries taking on that Exterior Wall Material default. No matter though, I agree It’s certainly not clear what they do or when they kick in. And it doesn’t seem to be anywhere in the Help files either.

I get it. That wouldn't fix the problem for me though. Not only does it not solve the problem with the identical tabs themselves, but it also only works when the text box is in view.

That's wouldn't be my problem. This would be my problem: 2 files with the same name open at the same time. This is something that would happen a lot in my workflow too. No, I think I'll stick with my current system. I just know I would end up making a mess of the wrong plan all the time.

Thank you for chiming in. I think you helped nudge me that extra bit I needed. Its clear to me that having files with the same name (whether Chief handles it fine or not) is going to cause me problems. I just know I would have a MAJOR problem keeping track of which plan I was working on without a clear identifier right there in the name if the plan. I have a big enough problem managing open program tabs sometimes.

Ya, this would be a problem for me as well. I actually already have this problem to a smaller extent because I do some manual syncing sometimes and end up having 2 files with the same name showing up on the list. To deal with this, I've learned to float over the name and wait for the popup showing the file path before I open it:

Oh, I see what you're saying. We can do that in Windows but Chief still displays the actual file name. Same with linking to layout. We can link to an alias but the link immediately grabs onto the actual file and not the alias.

Not sure what you mean.

@rgardnerand @Renerabbitt, do you guys ever have problems with a layout trying to read information from the wrong file if multiple versions using the same name are open at the same time? I would assume not but it does seem a little weird having several files with the same name open at the same time. In thinking this through, that might actually be my biggest concern aside from the file bloat. I'm not sure I would mentally be able to handle that very well. I could easily see myself with 2 version open at the same time and accidentally making a bunch of changes to the wrong one.

Yes, it has its potential problems but it also has some pretty massive benefits.

Okay. Ya, you guys are both using a variant of the first version I showed. You plan files are renamed for each new project since something like "Koenig_New.plan" would obviously need to be renamed "Smith_New.plan" when you start drawing for the Smith's. That in turn means the "Smith.layout" would need to be relinked when you first start the project, or am I missing something? The 2nd version/variant I suggested would alleviate the need for EVER relinking...even when starting a whole new project. The layout would get renamed but the plan name would always remain the exact same.

The actual PDF file name gets a unique identifier like so: Smith Prelim 1 Smith Prelim 2 Smith Cabinetry 1 Smith Cabinetry 2 Smith Permitting .... On the PDF pages though I just use the date stamp: I guess if multiple versions going out on the same day was a common problem for me, I might consider using an actual time stamp and not just the date. I used to included a manual version number on my PDF cover page but got tired of manually updating that. I realized at some point that a time/date stamp serves the same purposes without any of the extra work.

I can't speak for Rene, but I personally version PDF's only by date. Preliminary vs. Construction might get a different title or watermark of some sort, but versions I only reference using the date.

Can you show one of those folders expanded? I think you and Ryan are using 2 different (although similar) systems. His seems to be more like the first Option I showed above whereas yours seems to be more like the 2nd Option.

Yeah, that's different from what I described. The first version I showed describes a system with an identifying name being assigned to the plan and layout file (this is the one you seem to be using). The second version I showed (the one you just referenced but seem to contradict with your file naming description ) has no unique identified whatsoever. Every single plan and layout file across any and all projects would use the same name. What you just described has both the plan and layout files using a name that ties them to a specific project. Any unique identifiers in the name of your plan file would necessitate a re-linking at some point.

Interesting option. I might have to consider using it myself. Essentially your folder structure looks like this right? Smith Project |__________Version 1 Folder |__________Smith Plan |__________Smith Layout |__________Version 2 Folder |__________Smith Plan |__________Smith Layout |__________Version 3 Folder |__________Smith Plan |__________Smith Layout ...my only worries would be that I might have a difficult time searching for files since there would be tons with the same name, and that the identically named files might eventually cause problems with a layout trying to grab the wrong version. I assume the latter should never happen because I believe Chief will always look in the current folder first, but it feels like a potential problem. I guess I also don't like the idea of all the redundant files bloating my system. It does look super easy though so it might be worth it. It should be noted that this approach still requires re-linking for instances like what the OP has presented since the plan and layout files would both be getting new names. I wonder then if your system wouldn't be better served using this folder structure instead where (hypothetically at least) no relinking would ever be necessary: Smith Project |__________Version 1 Folder |__________My Plan |__________My Layout |__________Version 2 Folder |__________My Plan |__________My Layout Johnson Project |__________Version 1 Folder |__________My Plan |__________My Layout .... The system I currently use works more like this: Smith Project |__________Smith V1 Plan |__________Smith V1 Layout |__________Smith V2 Plan |__________Smith V3 Plan |__________Smith V4 Plan |__________Smith MAIN Plan |__________Smith MAIN Layout ...where the "MAIN" Plan and layout are always the current version. No need for re-linking for any given Project because I never change the name of the current file. Whenever I reach a fork in the road where I want a new version, I simply do a Save As, give the old version a Plan VX name and then immediately Save As again back to the Plan MAIN name. I will only version the layout if its something I know I'll want to return to. The biggest problem with my system is that simultaneously having access to multiple Layout version requires re-linking. It's not something I need very often, but your method would make that part incredibly easy. I could also modify my system to alleviate ever needing to re-linking for new projects by simply removing the unique name from my MAIN versions like this: Smith Project |__________Smith V1 Plan |__________Smith V1 Layout |__________Smith V2 Plan |__________MAIN Plan |__________MAIN Layout Johnson Project .... |__________MAIN Plan |__________MAIN Layout Hmmmm. I might be rethinking my file system here soon. I do kinda like that very first version I demonstrated above (the one I think you described in your post). I just have to decide whether the issues I mentioned are really going to be problems or not.