HumbleChief

The Xeons in my system have proven to be very fast at very few tasks, and very slow at many others. They are designed for heavy work loads over extended periods of time using multiple threads and cores like RayTracing can utilize but for everyday tasks they are just not a good choice. Plus they are now quite old. Where once they were termed a near super computer they are simply an old door stop technology today.

Good to know thanks for the follow up....

Honestly did not know there was an icon, can you go to View>Project Browser until you get it figured out?

Interesting to say the least. What makes that .plan such a beast? Or did I miss the explanation above?

No, my computer hangs for as little as 8 and as much as 17 seconds on a simple zoom via mouse wheel. 13 seconds to simply select the slab. 14 seconds to move an edge. I would say unusable with my system. ...and 12 seconds to simply close the file...That thing is evil and I've deleted it off my system just in case it will wake me in the middle of the night....

I'm out for now but nice work...and I found that problem with the formula but I'm seeing double about now so good night....

NICE!! Good night....

After reviewing that video I can see it does not work at all!! I was only looking at the bottom chord and not the top chord and where it meets the bottom chord. It seems each pitch needs a different roof structure to work consistently, which I guess by definition is pretty inconsistent..

Chop, I watched the formula fail with the roof structure as the pitches got lower. Near the end of the video. Everything seems to go OK then it failed and it looked like the roof structure size was effecting the result in an unpredictable way. Same simple plan as posted above. EDIT: After reviewing the video I can see it does not work at all!! I was only looking at the bottom chord and not the top chord and where it meets the bottom chord. Seems like the roof structure needs to change with each pitch, making Michael's point I think. truss formula 7.plan

Cannot get the formula to fail, just saying. Here's a plan file where it seems to work. Hope it helps. truss_formula_7.plan

...or these.

How about these settings.

I see attic walls when using the raise off plate setting, just sayin'. Help suggests it as a method for energy heels for trusses but that's pretty much all I know.

Same dbx - uncheck auto birds mouth and the raise off plate dbx is available. Can't find a difference when using either setting.

Interesting. I see you are using the 'raise/lower from ceiling height dbx and not the 'raise off plate' dbx.

Yes, this formula seems to work. Nice Chop... I didn't realize that Chief measured the roof overhang to the fascia and not the rafter end/framing. Or you can add the same 1 1/2" and 3/4" to the over hang dimension if you want the over hang to measure a true 24" to the rafter end/framing.

I wonder of you need to subtract the truss' top chord (3 1/2"?) from the result?

Justin, I've also had some luck by printing a complete PDF file from Chief, then printing that PDF to your printer, and reducing the resolution in Chief's print to PDF dbx. As a matter of fact I ALWAYS print to PDF first, then to the print house or to my local printer.

Got it William thanks...

I would like to create a corner cabinet for a closet (see image below) that's not the default 24" deep and am stumped. Is there a depth setting I'm missing? SOLVED: Looks like it can be created by dragging the door front in plan view but not in the cabinet dbx...maybe. Thanks

I have a layer set that purposefully eliminates all furniture as a couple contractors I work with find it distracting.

So I'm thinking regarding that first video, the first step is going to the defaults and make sure things are correct there, then frame build foundation etc. The thing I never really saw in the defaults dbx (illustrated in Steve's video, and I assume in Michael's post re: defaults) is what might be considered a top down (as the list reads) priority for the default settings, for everything foundation/framing related.

GREAT video Steve! Thanks for taking the time to post, clarifies some issues for me...

Agreed, but the conversation continues to ignore the built in, intentional, complexity, that, making a point above, many users do not mind and me thinks actually prefer as this thread I think illustrates. M_Gia even made the point above that Why do we have to calculate anything? That's the software's job IMO but again Chief users don't seem to mind. I mind a lot, but the complexity rules the day and the simplicity that could be incorporated in to the interface, without sacrificing and power, is simply ignored. Something I've learned to live with, with the software and most users on this forum at least, who simply do not find that important. EDIT: I can clearly see the benefits of some of Chief's complexity and the options it affords the user but think there are areas that can be improved...

Most likely an accurate analysis and am trying to think of a way to make Chief's system of defaults more complicated and less easy to understand but simply cannot. Perhaps the complexity is needed to create the most powerful options within the software, or Chief just really doesn't know or care to know how to simplify the interface and operations for their user base. I get the strong feeling that the software engineers, and those who think along similar lines, have no problem with the built in complexity and perhaps prefer it. I do not, and think there's quite a bit of laziness built in to the system that preserves that complexity at the expense of easier understanding and a simpler approach within the interface. A very simple but illustrative example. When setting the stem wall height the user is forced to use a calculation to determine the actual stem wall height. Yes it's only adding 1 1/2" for the sill plate but in my opinion that calculation should be completely hidden from the user. Again in my opinion, it's lazy interface programming to expose the user to the need to do unnecessary calculations in their heads when entering data in to a dbx. In this case that calculation would be completely unnecessary if the software did the work in the background (which could be argued is the job of software) . Enter the actual stem wall height, the software uses the sill plate depth, which exists on another tab, and figures it out WITHOUT the user having to do the work. Instead the user needs to do a calculation to get the stem wall correct, which again might be the preferable method for those who like that approach but why add that layer of complexity for the user? Someone is making that decision. "But it's only adding 1 1/2" to a basic value please get over yourself," but that's not the point. The point is that the programmers place the work of the software, which is to do that calculation, on the user. Not a great GUI philosophy in my opinion and this same attitude can be seen throughout Chief. Some would argue, and certainly will, that the complexity adds power to the software which it certainly does, but why not do both? Why can't we have the power and a simpler way to get to that power? Really, why not?