Joe_Carrick

Members
 View Profile  See their activity

  • Posts

    11783

  • Joined

  • Last visited

 Content Type 

Everything posted by Joe_Carrick

  1. Joe_Carrick
    Using "Paint" adds extra words to the material finish. Depending on the underlying material and other settings, it can result in a blending of the colors. Using the dbx actually results in a replacement rather than an extra - and as you see in your plan, a potential for unexpected results.
  2. Joe_Carrick
    I've been working on a macro package to do exactly that - using the room data combined with some Plines for the actual site areas. These attributes will just make it much easier to control.
  3. Joe_Carrick
    Edit that material's properties. Currently the transparency is 12%. ps: I prefer to assign the color in the cabinet dbx rather than using the "Paint" tool. It provides much better results
  4. Joe_Carrick
    Steve, Set the # of panels in the Garage Door dbx
  5. Joe_Carrick
    Do you really want the upper panel (gable end) to be out past the lower wall? If not, add a Wall Material Region (trim) at the top of the lower wall. This is the way it would normally be built.
  6. Joe_Carrick
    OK, I am going to make a suggestion to CA to add room attributes: include_in_FAR percent_FAR include_in_lot_coverage This will allow total flexibility in specifying what should be included or not.
  7. Joe_Carrick
    Ditto - I just tried it and the wall framing is showing in the RT. Something is different between what Michael and I are doing - vs what Rich and Chopsaw are doing.
  8. Joe_Carrick
    Interesting, I wonder if CA decided to ignore the Wall Framing in order to speed up the Ray Trace.
  9. Joe_Carrick
    Scott, It's interesting that you think I haven't thought this out. I have a PLine System that works exactly as you want with total flexibility to include whatever areas you want. I've had this system since X8 was released. The basic difference between my system and Michael's it that you don't have to change any formulas in macros - just what PLines are to be included. OTOH, some users want to use a combination of Rooms and PLines. It's just a matter of using room data for the building. A couple of things I've requested from CA are attributes for rooms include_in_FAR and include_in_Lot_Coverage. That would make it totally flexible. I agree with you that include_in_living_area isn't very useful for FAR but it is useful for Real Estate Building Analysis.
  10. Joe_Carrick
    So Far, it appears that most do not include Decks and Balconies - but all other enclosed above grade rooms are included. More votes are needed to get a realistic set of data. Please vote if you haven't already.
  11. Joe_Carrick
    I would normally consider the Basement only if it were Habitable Space - aka "Living Area" - or could be converted in the future. It's probably something most building departments would want to count just based on the future possibility. I will add to the POLL.
  12. Joe_Carrick
    I've found that different jurisdictions require different areas to be included in the Floor Area for the FAR calculation. I'm trying to put together a set that would cover as many cases as possible. Please respond to the Poll indicating what areas your local(s) require. Thanks.
  13. Joe_Carrick
    Most likely, the X9 Beta has been replaced by the X9 final release. Check the version number. It should be : 19.1.0.47x64
  14. Joe_Carrick
    Here's my version of Object Properties. It works much better IMO. _Object Properties.json
  15. Joe_Carrick
    Marc, Replace all instances in your macros of owner.top_elevation with (owner.header_elevation-owner.rough_opening_top) The problem is that X9 fails to initialize the top_elevation and bottom_elevation attributes. I reported this to Brian at CA and he acknowledged the problem. It's in their court to fix it but in the meantime, using the above alternative solves the problem.
  16. Joe_Carrick
    I received a notice from Brian at CA that he could reproduce the error and logged the issue.
  17. Joe_Carrick
    Did you contact Chief Tech Support?
  18. Joe_Carrick
    Ed, Have you updated the Library Catalogs since the final X9 release?
  19. Joe_Carrick
    Try this link instead https://kcclemo.neocities.org/creating-height-and-normal-maps/
  20. Joe_Carrick
    Steve, I always dimension in the Plan. It's much easier IMO. Of course, my Annoset & Layer Set is setup so that I can do this and just send the Site Plan to Layout. I never got the idea of using a CAD Detail Window for the Site Plan.
  21. Joe_Carrick
    Yes, and I've reported it to CA. I also had a macro for Vent Labels that used bottom_elevation that didn't work in X9. I've modified it to use other attributes but IMO CA should not make changes that cause things that worked to quit working.
  22. Joe_Carrick
    I agree with Michael. Of course he has exaggerated the Top and Bottom Rough Opening values - but it does illustrate the point.
  23. Joe_Carrick
    ps: Another way to see this is to open the Ruby Console and type: owner.top_elevation <enter> the result is nil or owner.top_elevation.nil? <enter> the result is true
  24. Joe_Carrick
    John, The owner simply eliminates the need to specify owner context. header elevation accounts for the rough_opening_top so if you change the macro to: arr = (header_elevation-rough_opening_top).round().divmod(12) "#{arr[0]}" "'-" "#{arr[1].round()}\" H.H." you will get the same result you did before. The problem currently is that the top_elevation is nil. It's neither a numerical value or a string. top_elevation.round() is the same as nil.round() which generates the error. CA needs to properly initiate the top_elevation & bottom_elevation attributes.
  25. Joe_Carrick
    John, Try this: arr = owner.header_elevation.round().divmod(12) "#{arr[0]}" "'-" "#{arr[1].round()}\" H.H."