Joe_Carrick

Currently, the manual method is probably the best. I've been fighting this problem for some time and have repeatedly asked CA to provide a "Room Context" for user macros. That is the only way that user macros are going to be able to be used to consistently format the Room Labels as we want and match the schedule.

My Roof Planes are all on the level they exist on. IOW: 1st floor roof is on level 1 2nd floor roof is on level 2 3rd floor roof is on level 3 My Roof Reference Layer Set then shows the adjacent floor's roof while the current floor's roof is also displayed.

It's also possible that the "Room Type" is specified as a "Court".

Maybe not, but that's about the only time I might use it. This is actually something that I do in a 3D perspective view.

Sorry Eric, that's not a very good solution - even though CA provides that ability.

Special Roof Reference Layerset is what I use. This Layerset is defined to just show Roof Planes, Ridge Caps and Roof Gutters along with the Main Wall Layer.

Sherry, User Macros are Plan Specific. You can simply select all macros in TMM and export them. Then in other plans import the json file using TMM. I you import them into your template they will be available in all new plans.

Do you need this to display the same in the Finish Schedule? Should the room number include the floor + schedule number? ie: 101, 102, 103, ... 201, 202, 203, ....?

Scott, Don't forget that vents may need to have auto fire dampers, depending on the jurisdiction.

I've done it for another user several times using Ruby macros to read the csv file.

I agree with Richard on this issue. Dims 12" or more should be displayed as '-" Dims < 12" should be displayed as " That's the way I have my defaults set up and it works perfectly. It would be great if when a specific dimension needed to be moved for graphic clarity that a leader be constructed automatically (option) connect to the dimension line. Note that I generally try to limit small dimensions in the plans wherever possible.

That would be my guess but maybe it's just a missing or corrupt file on your system. You might want to contact Customer Support.

What version of Chief are you using? I can't duplicate this so I have no idea what could be wrong.

If you are talking about what happens when you pan/zoom/rotate in a 3D perspective - this is normal because the lines have to be recreated by software. Standard Render Mode OTOH is done in Hardware by the GPU. X9 has alleviated this a bit by switching to Standard Mode while a pan/zoom/rotate is being done - but it switches back when that's finished and then recreates the lines. It's best while working to just use Standard Mode. Only use the other modes when you want to prepare an "artistic" render to print.

One of the users reported a problem with the Counter Tops Package. Basically for a Custom Counter Top with a Sink or other hole, the net area was being reported rather than the gross area. I have fixed that and anyone who has this package can PM me with their email address and I will email the replacement. -Joe

Yes, and it has been requested. Maybe it will be in X10 - maybe not. I kind of understand CA's reluctance to allow Ruby to do certain things to a Chief Project. OTOH, there are a lot of other facilities that a malicious programmer could use to mess things up - totally outside of Chief or Ruby. For that reason I really hope they will ease up on some of the limits and provide much more flexibility. There's so much more data available in the model that isn't exposed to Ruby. If it was all available, I could create a set of "fully annotated" ConDocs in just a fraction of the time it takes currently.

I've never had a problem with Ruby Safe Level 0 or 1. Safe Level 2 blocks almost all file access which really cripples Ruby. I suppose that a malicious Chief user could write a macro that could wreck havoc by deleting files or something - but as long as you trust the source there shouldn't be any problems.

AV software (not all) sometimes finds an exe or dll that appears to be infected - or is just suspicious. When that happens it adds the "name" to a list of files to "block" or "totally eliminate the contents" by setting the length in the file header to 0. If there's a legitimate file by the same name the AV software can really mess things up. I think some AV software actually comes installed with a list of "block these files". I can't say for certain that McAfee does it exactly this way but it certainly causes problems in some cases - however it makes the determination. Not all AV software takes this approach - but some do.

Terrain Retaining Walls just don't work very well for this configuration. The best way I know of is to draw it as a Railing Wall then open the dbx and Set it to a Solid Wall Add a Top Rail (maybe a 3x12 "Handrail") Adjust the Railing Height in the Newels/Balusters Tab Click "Foundation Wall" in the Foundation Tab Set the Materials as desired

I like to actually use a different Wall Type since both sides will be an exterior finish. We still need to have the sides reversed to prevent Chief from thinking it should be snapping to the corner.

It's also useful to have that wall type defined with either a "Blank" linestyle or a "white/background color". But you can also just set it as "Invisible".

One thing that can help to identify when the macro isn't working: Select a room Open TMM Select the Ceiling Height Label macro If it shows "Evaluation Error" check the "Show Evaluation Error" That will provide more detail on what & where the problem is.

OK, edit that macro line so that it is only: cRequired = ["Float Class.rb"] I'm also going to email the other 2 rb files.

I for one have never been happy with McAfee. Their AV is extremely aggressive and often blocks legitimate software. I use Avast or Eset and have no problems.

Alan, You have to use the "Default Room Label" and manually type %Ceiling Height Label%. It will not work in a RTB. For existing Rooms, make sure you use "Automatic Label" and uncheck/check "show label".