Alaskan_Son

Not sure what exactly you mean by system macros, but I assume you're talking about the available object attributes or name:value pairs. You can access those using the OOB ObjectProperties macros provided by Chief. Joe also posted some slightly modified versions of those macros here... Not sure what exactly you're referring to either Chop. There's nothing special about the version of Ruby Chief is using. They're currently using Ruby version 2.4.0. What is it that you would like them to publish?

Give it a shot and you'll see what I mean. If you're using %floor_number% as the prefix, the schedule has to be placed onto the current floor and include only rooms from that floor. If you set the schedule to include all floors and place it on floor 1 for example, all the room numbers in that schedule will use 1 as the prefix and the numbers won't match whats being shown in your room labels themselves.

There are a handful of different custom text macro solutions that could be used and that I would be happy to write for a fee, but for your particular use case, you don't really even need any custom macros. Simply create a text box that looks like this... #%room.schedule_number% %room.name% %room.internal_area% sq ft In order to get the floor number you just need to either change the prefix in the schedule to the appropriate number for the floor it represents or you could also optionally use %floor_number% as the prefix which would work for all floors, but you would need to place each schedule on the appropriate floor for that to work correctly.

You can also get into the habit of placing objects onto custom layers so that you can specifically toggle off layers for objects you really don't need to see in any given view. For example, do you really need that chandelier with 500,000 faces while you're only modeling a cabinet in the bathroom downstairs? I sometimes use working layer sets that are set up very specifically for this reason.

When you import SKP files into Chief, they are no longer SKP files, so it's not the file type causing you problems. It's almost certainly the face count as Tommy suggested. Sketchup has a handful of Polygon Reduction plug-ins you could try, but better yet would probably be adjusting your modeling habits. If you need super accurate symbols then there's only so much you can do, but as much as possible I would consider these quick tips... Only model the details that you actually need. Take a toilet for example...If you never need to show the lid open, don't model the inside of the bowl, don't model the inside of the tank, don't model the seat, and just make the main body, the seat, and the lid all part of the same solid object instead of 3 separate objects with faces that will never be seen. All those extra internal faces are just unnecessary. You could very very easily model a toilet that looks the exact same as another this way but with only 10% of the faces. Only model TO the level of detail that you actually need. Take these 3 following symbols for example... They're just some generic rings. The one on the left is 1728 faces, the one in the middle is 288 faces, and the one on the right is 72 faces. The one on the left was modeled using a perfect circle for the extrusion path and a perfect circle for the extrusion profile. The one in the middle was modeled using a perfect circle for the extrusion path and a hexagon for the extrusion profile. The one on the right was using a 12 sided polygon for the extrusion path, and a hexagon for the extrusion profile. I just turned up the smoothing angle as necessary to help reduce the edginess (see attached files)... 3 rings.calibz If I were trying to model a standalone marble centerpiece for a high end rendering I would probably use the symbol on the left. If it was a floatie to toss into a pool I might use the one in the middle, and if it were part of small chain with 40 links then I would likely use the one on the right. For the latter example, you can see how a chain with 69,000 faces could pretty easily be reduced to 2,900 with hardly a noticeable difference.

Yep. You're right. Got it. Thanks. And yes, the first 2 are for the same.

Does anyone know what these particular attributes were added to framing objects for, how they were intended to be used, or where they pull their information from? @Dermot or anyone else at Chief maybe? concrete_volume......................... 0 cu ft form_area............................... 0 sq ft rebar_count................................. 4 rebar_extension......................... 20 in rebar_size.................................. 5 stirrup_count............................... 8 stirrup_overlap.......................... 5 in stirrup_size................................ 3 They all seem like they could provide us with some handy information but most of them also seem like they would need information from other objects. Any help in understanding what these are would be appreciated. Thanks.

For clean, simple, crisp looking elevation views that are super easy to set up, I typically use and recommend Plot Lines, using Pattern Line Defaults, Pattern Line Defaults set to gray and a very small line weight, and using Sun Follows Camera. Here's a quick video...

I could be wrong, but I think this is what the OP is after (exaggerated for clarity)... Does that look about right? If so, there is no easy way to do this automatically in Chief. Manual roof planes only; using either a baseline running at an off angle in plan view, or by using the Baseline Angle in the Roof Plane Specifications.

You're welcome. In your quest to understand these settings, which one to use and when, and how your drawing habits might be affecting things, here's a question for yourself that I would suggest you explore... "Why am I drawing with my snap grid set to 1/16" while my dimensions are set to round to the nearest 1/4?" I'm not even necessarily suggesting you're doing anything wrong. I just think it's worth looking into.

Important to pick the right tool for the task for sure.

I might not use that exact same approach, but I more or less agree. I was honestly trying to avoid getting into a ridiculously complicated discussion. That discussion would involve all sorts of things starting with Grid Snap Theory and ending with Guberfield's Rounding Accuracy Paradox. I just didn't want to get into it all.

It's the result of Chief's Grid Rounding behavior. I don't have the time or inclination to explain it at the moment, but it's working as designed. The unexpected dimension being displayed is simply the result of where that dimension segment happens to land on the rounding grid. Either change to Distance Rounding in your Dimension Defaults or change the rounding accuracy for that dimension.

...or 1. Cut the shed from the plan 2 Build the deck. 3. Check Retain Automatically Generated Framing After Deck Room Is Deleted (or whatever it’s called). 4. Turn Auto Deck Framing Off. 5. Change deck walls to No Room Definition. 6. Paste Hold Position the shed back where it was.

Email me over the details and an example plan and I’ll take a look, but just off the top? Yes. An hour sounds about right.

It can be done but requires some custom macros.

This is something I too would like to see and something I requested a number of years ago. Maybe add your support over there...

On that particular plan, the easiest solution is to simply check Ignore Top (2nd) Floor in your Build Roof dialog.

Very nice! Just a friendly reminder, but don't forget how handy the Help Files can be. A quick search would have turned this up and saved a little of your trial and error time...

1. Ya, that one is no good. 2. Same, but do as Eric suggested and use the actual ceiling framing and you'll be in better shape. 3. Not sure what you mean. It's pretty easy to either set up an elevation view at the desired angle and then drawn the p-solid in that view, and it's equally as easy to simply rotate the p-solid after the fact. 4. Quick tip. You have to select the object by the appropriate face to get the desired rotational behavior. Also, try group selecting the object before rotating to get more expected results.

Oh, I see. Totally misunderstood. You’re not actually responsible for getting the plans stamped. Sounds like a different workflow than what we typically deal with. Sounds like you must be doing a pretty good job on your drawings too if you never hear back. As a builder myself I rarely draw for other builders. I did just do one project for another builder here this spring though that did something similar to what you’re talking about. Their engineer literally just took a red pen and marked up the paper drawings all over the place. They’re just using that set of marked up plans, but that’s also in an area that doesn’t have any permitting requirements.

Varies quite a bit from one locality to the next, but generally speaking, my experience for residential drawings is this: We draw plans as thoroughly as we reasonably can including any elements derived from our own rough calcs. We send those drawings to engineer. They send back required calcs and notes regarding what should be changed/added/deleted, we make changes, resubmit, and when all is right, engineer approves. This isn’t always the case and some engineers draw their own pages, but the above has been my experience in the overwhelming majority of cases. If you’re not hearing back, I suspect it’s because the files you provided were so far outside what they need or expect to see that they figured it wasn’t worth the hassle.

I’ve typically modeled those overframes in one of 2 ways... -Manually using solids -Using trusses that are essentially just rafters (edited as necessary in truss detail). In both cases though I’ve typically used a Truss Base for underneath the over-frame area.

Yes. This is true but it can be just as much of a bad thing as a it is a good thing since those annotation objects then might not jive with the visual display in layout. I really don’t mind the manual updating though. I do it one view at a time and take the opportunity to proof each page while doing so.

This is not entirely true. If you place a wall onto anything other than it's Default layer, it loses some of it's automated layer behaviors. For example, attic walls generated by that wall are no longer automatically placed onto the "Walls, Attic" layer and if you were to change that wall to an invisible wall, it will no longer be automatically moved to the "Walls, Invisible" layer. These are just a couple really quick repercussions that come to mind. There may be others I'm not currently thinking of.