Alaskan_Son

I only had a chance to play with it for a little bit but I concur. I’m relatively positive it has something to do with the new solid behaviors Chief introduced in X12. For now, I would suggest either converting to a symbol or using a 3-D molding line.

This should not even be a question. Not maybe...DEFINITELY you should send it to Chief.

If you're using X11 or X12, use a Bifold Door>Options>Door Panels>Custom And BTW, this was not posted in the appropriate forum section. This should have been posted in General Q&A. The Tips and Techniques section is where you post your own tips and tricks.

Even without a plan I can see that the schedule was likely a Room Finish Schedule converted to text since the columns shown and contents thereof cannot be done with a Room Finish Schedule otherwise. Rooms don't have an Object Information tab which you really need to add the types of notations you want, and so I would recommend you switch to using Notes and a Note Schedule instead. With some relatively simple macros and a small adjustment to your workflow you can automate everything except for the columns where you want to be adding notations manually, and with Notes, doing so can be done very easily while still keeping the schedule live.

This particular issue is really a complex problem and each person has to figure out what works best for them. Sure you can throw out any outdated sets when you stop by the job, but sometimes those outdated sets have a bunch of notes/markups to help with a particular subcontractor's process, and you just threw all those out too. And sure, you can just stop using subs who can't seem to remember to use the more current plan iteration, but is it really their job to keep up with all your constant changes or is it your job to go out of your way to make sure they're constantly supplied with the most current information and made fully aware of any changes that have been made? Also, don't forget these plans get passed around from company owners to project supervisors to site foremen to carpenters who may give their copy to the plumber and so on and so on. It's a bit of a dance for sure but the vast majority of the responsibility lies at the feet of the GC in my opinion. It's a tough job we have, but we just need to find a way to gracefully make sure everyone is on the same page...it's really our main job. On a side note, I'd say any of us who have a major problem with this might want to take a serious look at why we have to keep changing plans so much...maybe we should refine our design/drafting process a bit.

I normally try to stay out of issues I haven't come across on my own, but I'm gonna go ahead and send this one in myself. I can very easily spell out the procedure to reproduce and hopefully it will help them sort out not only this issue but other similar library object material issues as well. For the record, you can reproduce with the following steps: Copy a Wall Type from the Core Catalog Paste that Wall Type into your User Catalog Open Object IN THE LIBRARY, and modify something about it. It could be just about anything...wall type name, wall layer thickness, something on the Structure tab, almost anything. Draw with that wall from the library in the current plan and open it. All should be fine. Open a new plan, draw with that wall from the library in the new plan, and open it. All should be broken but wall in library should still look correct. Close down Chief, open it back up, start a new plan, and open that wall in the library. It should be equally broken in the library now too.

For the record, I can very easily recreate in X11 as well.

It's impossible to make sure everyone is using the most current set of plans without having a unique identifier and specifically spelling it out that they should be using the pan set with that specific identifier. It could be a version number or anything. I personally think the most dependable thing to use though is a date/time stamp. Again though, somebody has to make sure everyone is aware of the correct date/time stamp though, and as Robert pointed out, that may or may not be your job.

I'm probably going to have to be done playing with this for now, but the behavior is super weird. I can purposely get a wall to go rogue and sometimes I can fix it by simply placing another wall type in the library. The behavior of the library objects change though depending on whether you're in the same plan, you start a new plan, or you restart the program. Restarting the program is what seems to make the library object totally and permanently broke and unfixable though. Here's my conclusion for whatever it's worth...Create your wall type in plan and then add to library. Do not edit the wall type after it has been placed in library. If you do it this way, the wall seems to remain stable. There's definitely a reproducible bug that needs to be fixed here though. I think the reason many of us have never seen it is that we don't typically edit wall types while they're in the library. I'm honestly not sure I ever had up until I was troubleshooting this stuff for you today.

I was actually able to reproduce easily by copying the entire wall type folder as you described. From that point forward, every time I have tried to copy and redefine a wall in my user library, I get the buggy behavior as well.

Both of those files seem to contain zero data. Looks like some other people were having problems with attachments here recently as well. Maybe try emailing to me at alaskansons@gmail.com

Post a plan that contains your desired wall type as well as an exported library object with one of those corrupted wall types.

Did you check the layer your wall is assigned to like I mentioned? Click on the Layer tab. What Layer is it assigned to? And was it EVER assigned to a different layer? Not sure how you're adding to your library, but no matter what, I would strongly suggest you start with a brand new wall. Don't try to fix or reuse one that has already been corrupted. EDIT: I had originally suggested trying to copy and paste from the user library which I had found to work well for the OP's purposes during some quick troubleshooting, but after further testing, I was able to reproduce the issue as spelled out in the OP and found that the most stable method for the intended was instead to create wall type in the plan and then add to library. Do not edit the wall type after it has been placed in library.

Default Settings>Wall>General Wall>Resize About

This is a weird question because it appears as if though you are asking about a window schedule but the details you mention are very object and plan specific and most of that stuff wouldn't be shown in a schedule at all in most plans. I think you'll need to be a bit more specific as to what you're trying to accomplish; otherwise, my answer to you would be to handle with notes in the schedule and/or with detail drawings and notes in the plan.

Challenge!

Call. We'll never know till the OP plays his cards though.

In all seriousness, totally random guess, but I’m betting you don’t have the electrical note type set to display in any of your note schedules.

Okay then.

Not me!! I had to futz around with it for a bit. I remember the problem being posted by a couple other people in the past and decided to go ahead and troubleshoot it this morning.

Oh, I know that's not true. I appreciate the vote of confidence though.

Not sure if this is the problem in your case or not, but one thing I've found that can trigger those corrupted Wall Types is if the Wall Type in your library is assigned to anything other than the Default layer. I won't pretend to know why, but once a wall in the library has been assigned to ANY layer other than the default, it will become corrupted from that point forward, even after it is changed back to the default. Try to see if you can create your wall type on the default layer, add that to your library, and see if that one consistently works in new plans.

Post the plan and I'm sure we could have it sorted for you in a matter of minutes.

I (possibly errantly) assumed that with all the back and forth and troubleshooting both with tech support and here in this thread that surely someone had already mentioned that and that I had just glossed over it. This is typically one of the very first things people check, and if it wasn't checked, you could of course very well be right.

That may be worth a shot, but that won't likely solve your problem if it's a driver issue.