Alaskan_Son

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.

I took a quick look at that Pella macro this morning and it seems to have a handful of problems. In addition to the issue with the new Measurement class, there's also an issue with their use of the word "label" which currently conflicts with the name:value pair using the same name (an attribute that didn’t exist when the macro was originally written). There are other issues as well but I don't have the time or inclination to figure out what those are. For now, see if this modified version of the macro will work for you. Just DO NOT Migrate it. Leave it using the old deprecated behaviors. Pella quick mod.json And please report to Chief so they can incorporate a proper fix.

Carefully read the advice given by @rgardner and @JacobB given above, but if some nuance about how you're doing things still requires or otherwise results in those fractional values that you don't want to see, you can always using the round method to round your values: %schedule_number% - R.O. %width% X %height% %type_code% SH %bottom_elevation.round% - HH %header_elevation.round%

In addition to using Defaults and Style Palettes, you can also change one cabinet and use the Material Eyedropper/Painter, the Object Eyedropper/Painter tool and/or Match Properties.

Yes. Chief doesn't work this way and they have yet to provide any setting that allows us to do so. The best replacement option that I know of continues to be the method I mentioned earlier in the thread: Again, you can customize your hotkeys if desired to make the operation easier, but the basics are the same.

Your best bet is to just turn the arrow off and place one manually.

You are completely correct. The Structure setting does (or at least can) indeed affect other things in the model--particularly if you are lowering the roof so that the bottom of the defined structure starts to encroach into the ceiling and wall framing below. I corrected my post to reflect that. I guess I've very rarely had to lower any of my roof planes. I'm almost always making them higher so the Structure settings don't affect much of anything. I should have known better. Anyway, thanks for bringing this up. I stand corrected. The Structure depth should be changed if you're trying to lower a roof after it was initially built using the wrong settings. I'm not sure it matters if you're going to raise the roof, but as a matter of good habit, it should probably be changed in either case. Thanks again. Good catch.

Yes. I do this exact thing myself. Here are a couple examples with visuals: One option is to do as @Kbird1 suggested and just set you Drawing Sheet to be 22"x34" in Layout, but when you print, simply select Check Plot at>1/2 Scale: Example using 24x36 and 12x18 but same exact principle applies: If scale doesn't matter, you can also do as @VHampton suggested and simply use Fit To Paper. I would however note that the percentage completely depends on your title block and borders. For me, 100% works just fine for printing 24x36 to 11x17:

If a person is going to use trusses, then the Structure thickness won't even matter. It's all about setting the Baseline Height correctly. For existing roof planes that were initially drawn using the incorrect settings, I can think of at least a few options, but in all cases you are correct that the Structure Height should be changed to match the correct Truss Top Cord Depth. Check Trusses (no Birdsmouth) in your Roof Defaults, draw a new roof plane, open it, copy the baseline height, delete the roof plane, open your other existing roof plane(s), Lock Pitch, and paste that baseline height into the baseline field. Open another existing (but correct) roof plane, copy the baseline height, open your incorrect roof plane(s), Lock Pitch, and paste that baseline height into the baseline field. You can draw a truss, take a section view and simply measure how far your roof plane needs to move. After changing the Structure Depth as @Chrisb222 suggested, inspect the Vertical Structure Depth on the General tab. Lock pitch, and set the Baseline Height to Top of Plate+Vertical Structure Depth.

This isn't quite right (or its at least an incomplete picture). Changing the structure setting in Roof Defaults will only cause the roof to be lowered for newly drawn roof planes. It will not however affect any existing roof planes and even newly drawn roof planes will get set at the wrong height since rafter framed roofs get the baseline height set differently than it would if Trusses (no Birdsmouth) were checked.

@Chrisb222 already pointed out the main issues, but to clarify a bit: First thing to understand as that when you check Trusses (no Birdsmouth), 2 important things happen: 1). Chief changes the Structure Thickness to match your Default Truss Top Chord Depth. 2). Chief automatically places the Baseline height of the roof so that the bottom of the Truss Top Cord sits right on top of your wall at the Baseline. The above is true for BOTH automatically generated roofs and for manually drawn roofs (assuming you change the setting before manually drawing your roof). You can find all this information and more if you get into the habit of clicking the Help button. In this case, open the Build Roof dialog, click the little Help button down in the corner, and read up on the Trusses (no Birdsmouth) setting. Follow any related links if you don't find what you need in that particular article.

This is true, but upon creation of a new elevation that uses those variables, the user is almost certainly going to be copying other stuff anyway, Might as well just group select that item as well. Regardless, it only takes a matter of seconds. Depending on the approach taken, the macro(s) could even be placed in a default label or default text box thereby alleviating the need to copy anything. Your suggested approach (using a Global hash with a unique key set by the user for each new plan) will work as well, but in large part, you're just kicking the can further down the road. Not only does each user have to remember to change that key with each and every new plan and for each and every new plan iteration, but they may even need to change it for each and every user. PLUS, the global hash would never even get populated until the CAD Detail were opened up. That means for every single session for every single plan, a person would have to first open that CAD Detail if they wanted to see the appropriate values. The bottom line is that if you're going to be using Global variables, you'll get the most stable, consistent, and predictable results if the macros that define the variables can be placed in the views that are using the variables. This isn't always possible, but when it is, I would highly recommend doing it. All other approaches rely on shutting down and restarting Chief, shutting down and restarting plans, opening specific dialogs during various operations or during each session, opening or scrolling through specific views in each plan or session, and/or maintaining some other complex routine to ensure accuracy.

Here’s one method that doesn’t require any macros:

By the way, you can also skip the use of Globals altogether and simply use a hash: Example Hash: name: test value: {:a => 1, :b => 2, :c => "apples"} Example Usage: %macros.test[:a]+macros.test[:b]% %macros.test[:c]% #=> "3 apples"

Just so you know, there are plenty of other solutions that haven't even been discussed. For example, why not place all these variable assignments into a single Parent macro? Set that macro to include nothing as its last line ("" or nil) and then wherever you want to use one of the variables you simply place both the Parent and the Child. Example: "parent" macro definition: $a = 1 $b = 2 $c = "apples" "" Placed into your desired label, note, callout, or text box: %parent%%$a+$b% %$c% #=> "3 apples" or one of several other optional formats; %macros.parent; "#{$a+$b} #{$c}"% All your assignments are made in a single place and because the parent macro is always placed with any child macros, the results are always accurate. You could also define Classes and Methods like so: "parent" macro definition: class MyClass def a 1 end def b 2 end def c "apples" end end MyClass.new Placed into your desired label, note, callout, or text box: %macros.parent.a+macros.parent.b% %macros.parent.c% #=> "3 apples" Again, all your assignments are made in a single place, and even though Classes and Methods are global by nature as well, they will always be accurate per the current plan because you're referencing the defining macro in every location that its being used.

No, not at all. Read my post again. Specifically this part... You place the required macro(s) into the required views in your template plan. Once and done. From that point forward, all you do is change the CAD Block or macro definition in a single place and any/all views that use any associated global variables will be updated as well. Because the defining macros live in the views where the variables are being used, the variables will always be accurate.

You've highlighted the key issue and that is this. A global variable must be properly defined before you can use the desired value in any given view. In my opinion, the best way to ensure this happens is to include the variable defining macros in any view that they are being used in. They can be placed off to the side, they can be made invisible, they can be made super small, they can be hidden...any number of things, but if the macros that set the desired value are placed in the same views where you are using the desired value then you'll always have the most current value as it pertains to that particular plan. In the specific scenario mentioned by the OP, that whole setup can potentially just be part of a CAD Block. That CAD Block can simply be dropped into any view where the macros are used. Update the CAD Block, and all views that contain the CAD Block will be updated as well. Yes, there are various other methods of dynamically naming or organizing variable values so that the value is linked to the specific plan. You can use the actual plan name, you can make a habit of incrementing a unique plan number with each new plan, you can simply copy and paste your macro definitions from a spreadsheet that assigns unique names to your variables, you can use macros that reference an external file (that again uses unique variable names for each plan), and so on. I personally don't think however that its worth jumping through all the hoops when you can just make sure your global defining macro(s) are present in the views where the values are being used.

They don't actually jump from one plan to another. The issue is simply that there's only one global memory to go along with any given instance of Chief. So, for all intents and purposes, any global variable can only have one value at any given time.

As some of the others have already pointed out, what you're talking about is actually a global variable, not a global macro. It would help if you were to communicate in the approrpiate terms. Chief does have some of what they call global macros, but those are a different thing entirely.

…or your “Walls, Attic” Layer is turned off.