AgChief

Well that was easy enough.  And I had obviously done it before.  But I've slept since then...  

Also, naming the png file the same as the custom toolbar button did the trick.

Thanks!

Does anyone know 

1) How to get my custom toolbar button icon to show?  I was trying to edit the icon and pulled it off the toolbar and it disappeared.

2) How do I change the icon of that button?  Is it a simple matter of creating a button icon and name the file the same as the custom toolbar?  I noticed that's what the icons are named for the standard buttons.

How about this.  Instead of a door facing the Dining Room, make it a cased opening going to a hallway and create a mechanical closet by enclosing the water heater and A/C with double doors.  I try to avoid placing doors on "public" areas, or at least soften their presence with a cased opening.  I also placed a cased opening at the entrance to the Hall to the bedrooms for the same reason.

20 hours ago, TheKitchenAbode said:

 

Everything always runs fine as long as the plan remains below a certain level of complexity. Would be interesting if you would run this P-Solid stress test with your graphics cards to see how they perform.

 

Once the plan is loaded, first select the full screen icon and then record the time to reduce it by one magnification. Then reset it back to full screen and then record the time to increase it by one magnification.

 

P Solid Stress.plan

Latency/unresponsiveness has always been a huge aggravation for me with CA.  This simple test took my system about 6 seconds each to increase and decrease magnification.  How can a simple single (albeit large) Psolid bog down the software like this?  Is this typical with everyone's system?

Edited to say that I just noticed the 1/16" scale concrete pattern.  That's the reason it's so slow, I realize.  How does CA generate that?  CPU or GPU?

Not sure if this is what you're looking for, but it's a method I've done on lots of houses in Texas.  I just lowered the roof pitch on the back half of the house to a 6:12 so I could have the main left-to-right ridge defined by 13:12 roof pitches, framed from an interior wall about halfway toward the back of the house.  That frameline is really arbitrary until you want to determine how high you want the highest ridge.  Pull that roof plane forward and it'll lower the ridge.  Push it back and it'll raise it.  I never use the automatic roof function so all of these planes were done manually.

When I saved the chief file I saw that you're on a version older than x10.  I went ahead and saved it to x10 but I've uploaded some screen shots too.

Trying to Zip plan.zip

I haven't explored all the options for this and, really, I just had an idea and threw something on the wall to see if it would stick, but how about this: 

I had already created a wall type with 1x3 furring strips to create a rainscreen gap, so after I built the wall framing and the furring strips showed up, I thought the same could be applied to battens.  What I did was to create a wall type with the outer-most layer being a framing layer of 1x3's spaced at 16" oc to represent the battens.  Then you have to build wall framing for them to show in 3d and on the plan, and set auto-framing to "ON" to update the battens when editing the plan, etc.  The problem is that if you have to delete battens that aren't spaced correctly, or there are just too many (like at corners) you have to turn off auto-framing and you're back to square one if you change anything.

What you end up with are individual framing parts that are similar to psolids but are somewhat parametric, albeit very limited.  Addionally if you're just looking at the model without the framing, that exterior layer of battens will show up as one plane of material and cover the "boards" which, in this case, I just used vertical siding.

Board and Batten experiment.plan

18 minutes ago, Joe_Carrick said:

Here's my version of Object Properties.  It works much better IMO.

_Object Properties.json

Thanks, Joe!

On 2/15/2017 at 2:54 PM, Alaskan_Son said:

 

Looks like hat top_elevation attribute is more broke than I thought.  It works when placed directly into the label but otherwise the value is being reported as blank...

Please report those issues to tech support.

Reviewing this thread, I just noticed that my "ObjectProperties" is different, and I have absolutely no idea why.  Is your "ObjectProperties" the stock version or did you change it?  See the attached pic.

Joe, I dropped your name when I contacted tech support, so that's probably what sped things up!  

Thanks, Joe!  I've reported it too so maybe we'll get a quick fix.

Nope.  I'm not referring to "modelling" as I've been drafting on 2D Autocad for my entire professional career.  I'm simply referring to placing a note on the plans telling the framer where to set the top of the window.  When I've framed window openings and on every set of working drawings I've ever done where the top of the window is referenced, it is referred to as "Header Height", and as far as I've experienced it's been common nomenclature in this profession.  I've been doing this for over 25 years and have never, ever had an issue with a framer in terms of window placement height so believe me, all of these years I've obviously been doing something right.

This thread was intended to point out a potential bug and to see if anyone else had experienced it.  I'm certainly not an expert in Ruby, but I've had success with this macro in the past, and when it doesn't work after an update it logically follows that there's a bug.

Exactly.  It's not working after the x9 update, when it was working perfectly fine before.  Before the last update %top_elevation% returned the top of the window in inches, which I then formatted to feet and inches in a format (ie., 6'-10" H.H.) that my working drawings have had for years.  I never consider rough opening when I call out the header height so why would I go to the trouble of doing the math in an equation when that information is (or, has been and should be) provided by %top_elevation%?

I think the issue is that since top_elevation has the string formatting, the macro blows a fuse when it tries to evaluate a string in a real equation.

Thanks, Joe.  It looks like Chief has added formatting to %top_elevation%.  I can avoid the error by changing the original macro by substituting header_elevation for top_elevation in the macro.  Adding "owner." to the macro doesn't seem to have an effect.

The following macro does give a valid result but "header_elevation" isn't what I'm looking for, as it accounts for the 1/2" at the top of the window for the rough opening then rounds up to the next whole number.  In this case it would result in 6'-11" instead of 6'-10"

arr = header_elevation.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

Like I mentioned, I think Chief must've added the quotes to the formatting to denote inches, which screws up my macro.  See the attached image to see the difference in the results.

Anyone else getting #EvaluationError# on macros since the x9 final release?  Things were working fine until the update to the final, non-beta, x9 version.  I have a set of working drawings to finish up.....

Here's the offending macro, it's purpose is to show the header height on a window label:

arr = top_elevation.round.divmod(12)

"#{arr[0]}" "'-" "#{arr[1].round}\" H.H."

evalerror.plan

Well that was easy enough!  Thanks!

However, I still think this is a bug because CA should create the hole automatically, regardless which floor the roof is displayed on.  Chief should determine that the roof covers a 1st floor ceiling, therefore should create the hole.

Ok, the next thing odd happening with this model:

The cheek walls on the dormers are being cut at the roof plane locations.  I suspect it's a problem with the two roof planes coming together at the gambrel pitch transition points, and being compounded by two ceiling planes below the roof planes created to 1) provide a 12" space for insulation and air gap between the roof decking and insulation; 2) provide gussets at the roof pitch transition where the support studs have been removed to open up the rooms.

Dormer_cheek_wall_problem.plan

I've racked my brain trying to figure out why my skylight won't show a shaft to the ceiling on my first floor master bath.  After placing a successful test skylight on the second floor, it occurred to me that the roof plane I was inserting the skylight into was generated from the first floor, but to draw a proper roof plan I have to display that roof plane on the 2nd floor.  I moved the roof plane to display on the first floor and BOOM it creates the skylight shaft correctly.  Tile the plan window and the section window and you can see what Chief does when you change the display floor.

Anyone else have this problem and created a solution, or is this a bug?  I'm leaning toward bug since the skylight shows correctly on all views, just doesn't create the shaft when the only thing different is the floor on which it's displayed.

Thanks!

Skylight_problem.plan

Thanks, Eric, that seemed to be the trick.  I need to study up more on floor levels and foundations.

just noticed the plan didn't upload, let me try again.....

On previous versions of this remodel, I've been able to drop the floor of the existing "Sunken Family Room" 5-1/2" and the other floors would remain at the proper "0" level. The clients have massively changed the plan, including moving the garage toward the front of the house, requiring that it be dropped 24" due to site conditions. After finally getting the garage to remain at 24" and stepping the rear porch appropriately down to the garage floor, I can't lower the Sunken Family Room floor down 5-1/2" without all the other rooms also dropping 5-1/2". I guess somewhere in the process I've set a default setting that I'm unaware of, maybe? I'm at a loss.

FloorLevels.plan

Hey John

 

“I think we might have a winner with this one!  These are the exact errors I'm getting.  All things being verified as working properly, this is the turd in the punch bowl variable that might be causing the issue since there are already known issues acknowledged by Chief with bringing x7 files forward - mainly the issue with the roof overhang encroaching into an interior room in 3d and elevation views, which I'm having a big issue with.”

​Have you gotten any answers from tech support regarding what to do? 

For now I am just going to use X7 for my X7 created .plan files. 

 

Thanks,

Kay

I haven't formally submitted the errors to support, just hit the button on the error window that says to "send report".  I've been too busy to write down exactly how it happens.

Going back to x7 might be the best thing to do, I'm just too stubborn to do it!

When you refer to the former X7 plan, are you activating a saved camera in that plan that was saved in X7? If so reopen the plan in X8, do not use any of the existing cameras, place a new camera and see if it problem reoccurs. I had some similar issues with cameras originally saved in X7. There have been some changes in the camera view settings in X8, l think there can be instances where these do not get properly readjusted when a X7 plan is converted to X8.

 

 

​Graham

Yep!  I'll keep an eye out today when I get back on that job.

I've been getting quite a few "Serious Errors" since upgrading to Windows 10 and/or X8 as well, although I'm not sure they've ever resulted in a crash. 

x2 with the "serious errors".  Mine seem to happen when I have a plan, a few elevation tabs, and a layout open at the same time.  I built the new system in my sig recently with an OEM install of W10, so it's not an issue of upgrading from W8.1.  I'm not above saying that I might have done something wrong with the build and it certainly might be a faulty hardware issue, but CA is the only software I have issues with.  The only thing I think might be causing it that I found out later that I shouldn't have done is to disable the integrated Intel graphics.  I don't think that should have anything to do with it since, generally, the installed GPU takes over anyway.

... For myself, I run smaller models on Chief, a raytrace in the background, MS Office and browser with the odd photo editing here and there. For this, my recently purchased $1,500 Alienware R3, Skylake 6700K, 8GB Ram and Navida GTX 745 runs everything without any sense of lag whatsoever. ....

Graham

Thanks Graham! This piece of info Will probably push me to get a new system. I don't raytrace, mainly because of the time and bog-down involved, and really the only other apps I'll have open other than CA are MS Outlook and maybe a few browser tabs. With that low of an overhead while working on Chief, I shouldn't see much lag at all, if any.

Now, if any of you want to donate to the cause, I take PayPal.....