Alaskan_Son

Jason, I feel like you're investing an awful lot of time and energy to solve something that's really a very minor issue at worst (linking a re-named plan file to layout). And to boot, the method you're using isn't something I think Chief ever intended and therefore you may end up having some notable problems if you or anyone else adopts it in their regular workflow. What happens a month from now for example when Chief releases X13 and they suddenly change the behavior? Will it have been worth all the hassle? Just a thought.

Don’t have the time or inclination to go into all the nuances in a quick post, but I think you’ll avoid a lot of problems by just placing that text box in your PLAN and just sending it to layout from there. That way it resides in the same place that the global is being initiated. Also, just FYI, as a general rule, there needs to be a screen redraw/refresh of some sort in order for macros to update. This could be panning/zooming, but it also happens when you print. Not saying this will solve your current problem. Just something to be aware of.

Per the IRC (and most all the derivative codes), the clear headroom must be 6'-8" "....in all parts of the stairway". Does not meet code in my opinion.

Had you read and perhaps responded to Kevin's post in this thread, you would have had your answer a long time ago.

@robdyck, as you've already found, this isn't currently possible. The floor structure can only exist inside the defined room. The footings are below and therefore outside the defined room. This means you can't push your floor definition down there.

As Levis already pointed out, there are other good reasons not to use room fills, but for this one, you just need to turn off the "Rooms" layer.

Pretty sure the thread was just deleted by the OP because he or she felt it had gotten too far off track.

True tale.

You don’t even need any polylines. You can just use the Room Fill.

Check 3D>Camera View Options>Toggle Textures. I'm guessing you have Textures toggled off.

I wasn't suggesting using the CAD Detail itslef. Only stealing a snap from the CAD Detail in the form of a line or point. If you dimension to a Cross Section Line you're doing the exact same thing. Cross Section Lines are nothing more than a temporary CAD objects and don't remain tied to the model either. Glenn knows this which is why is he said... Both methods require dimensioning to CAD. The question is this.... Is it faster to created a CAD Detail From View and then copy/paste from there or is it faster to move your camera twice. P.S. There are also TONS of situations where cross section lines aren't even going to be an option and where a CAD Detail From View is the only viable method for accurate snap points.

I don't see how this is any faster than simply creating a quick CAD Detail From View. If you have no snaps to start with it means you weren't cutting the object with your camera meaning you would be required to reposition a camera at least twice and you would still be dimensioning to a dumb CAD object (i.e. there would be no functional difference from stealing snaps from the CAD Detail). For the camera cutting the beam you would already have snaps and we wouldn't be having the conversation in the first place.

There are several in the Core Catalog under Exteriors>Vehicles>Cars

Can you please clarify what you mean by this? Just trying to learn. I'm not 100% sure, but I think he's referring to the Interpolation you're using ----> "#{code}" Interpolation isn't really a code block. It's just a little trick to insert code into a string.

You're probably doing something wrong then. If you can SEE the top of your beam and if that line is drawn in the CAD Detail From View, you should surely be able to snap to the line in your CAD Detail From View. Either copy that line directly, or snap another CAD object to it and then Cut/Copy and PASTE HOLD POSITION (Edit>Paste>Paste Hold Position or Control+Alt+V) your snap reference line back into your elevation view.

I didn't study all your methodology or syntax in great deal, but just doing a quick once over, I see that you appear to have a typo in the last line of your code_data macro...

To get otherwise inaccessible snaps, I use CAD Detail From View. Copy a line from that newly created CAD Detail and then Paste Hold Position back into your Elevation View.

Those look like Arc Centers and Ends. Toggle them off.

One of the most fundamental pieces of the puzzle is this: You can USE your global variables in as many macros as you wish but you need to make sure you only DEFINE the global variable in a single location. Also, in order to use the global variable, the macro that defines the variable needs to be executed somewhere in your view (it can either return a blank value or it can be dragged off to the side).

For this one, you just need to use the escape character (backslash) like this... ”24\”” Don’t have time to answer the second part right now.

There's a reason I didn't list any of the reasons and its because they're all over the board and many are too complicated and seemingly random to describe. Something as simple as building a new floor will do it though.

Nice outside the box thinking! I've used that method in the past myself but I stopped suggesting it because it's just too finnicky. You can just put a filled poly-line (invisible line style) to mask the unwanted portion or add a bunch of carriage returns to push the unwanted text out of view, but that only solves the most minor problem. The real problem is that you'll lose your work anytime the Living Area label gets re-generated. There are a number of operations that will cause it to regenrate, but when it happens, its going to annoy you. Just beware.

Long explanation short: Unlike many other object attributes or name:value pairs, living.area (along with most of Chief's built in "Global" macros) is not something Chief has created a Ruby method for. Text macros (onscreen string substitution) using the %name% approach is a Chief construct . Ruby is something different. It can be used in text macros but it doesn't have to be and commonly isn't. Chief knows what living.area means and replaces it with the appropriate text string but Ruby has no idea what living.area means so in your example above, you're essentially trying to divide nonsense by 2 which results in an error so Chief just doesn't do it.

Took me a few minutes to figure this one out, but it can be changed. Long story short, the material for those Parametric (non-library symbol or "smart") Door Styles seems to be sort of hard coded but you can trick Chief into changing the referenced material. Here's how... Open the desired Door Default and take note of the door style being used. If a parametric door style is already being used all you need to do is click on the Material tab and change your material there. You're done. If you're using a Library door though... Change the Door Style to one of the parametric door style (other than Glass Slab). Click on the Material tab and change the Door (Interior) and/or Door (Exterior) color to what you want the default to be and click Okay. Click Okay again to close out your Door Default. Open the Door Default right back up and change your Door Style back to the proper door (you should have taken note of which one it was earlier so you can quickly search the library to find it). Click Okay. Now you can drop one of those doors into your plan and whenever you change from the default library door to one of the parametric door styles, it should use those new material settings. Please note that you need to do this for each and every one of your Door Defaults though.