KTransue

So happy, Rene. Always happy for you to blow holes in my arguments ... You do it with such finesse! It appears "crow" is on the menu again ... (I keep embarrassing myself … I'm gonna have to learn to keep quiet). I've been running through your responses and there are definitely things I either missed or took a left turn on. A few of my issues, though, I’ll still defend. And, I'll keep doing what I do best ... Looking for all of the frustrating ways that'll lead a desperate man in front of a bus, and I've found enough of them that I had to start writing them all down to keep a path back to them, like bread crumbs in the forest. And, I've knocked it on its butt several times in the last two hours, just trying to find something consistent that I can pass along as fodder for continuing conversation. Too many to summarize here, though, without doing another deep dive first, but this time I have your input to lean on as well (and I really do appreciate that!). I've proven a couple of your responses true, haven't gotten to a couple, and a few I still can't get to due to brain fog and Chief programming idiosyncrasies (e.g. greyed out selections that shouldn't be greyed out, etc.). Each of them burns up some more time, and now I just want coffee or a nap, or both. However, I will concede that even without employing a true application system designer, they've still managed to get 80% of the way there, and we can probably find a way to get around that last 20%, just as we have in every other version. I just feel sorry for those that will be left confused, frustrated, and hopeless. On the other hand, it does provide more opportunities to teach, so there's that. The overarching point I was trying to make in my post wasn't the correctness of each bullet point -- there are many more -- but that the system design itself is incomplete and lacking, and the resulting PM behavior is underdressed, with holes in its genes (pun intended). The PM system's current state is born of a design that's trying to reinvent the wheel, and it's designed to rely on human behavior modification and habit more than it relies on systemization. Technically, though, I took your responses to heart, and it seems you're right … there are ways to force things to work ... if you’re curious enough to look for alternatives, resourceful enough to find them, committed enough to apply them, and rigorous enough to remember them. I know I'm probably spitting in the wind, but damn it, I want all this stuff to be as good as it can be and I just wish they'd ask for help; not just "reports" and "suggestions"! Sorry everybody ... I'll climb back down off my high horse now ... Oh, and I really don't know where this should be posted. It seems that this thread is better attended than some others, and it's more than a suggestion, and it's not a feature request, which leaves "bug report" and I don't yet have enough details written down to list all of those.

Hey folks, After evaluating X17’s new Project Management system in real-world use, I’ve pulled together a summary of how it works, where it shines, and where it’s falling short—along with a few serious risks for anyone relying on it for production work. This is a summary of a longer, more detailed critique I’ve written (with scenarios, risk cases, and proposed improvements). I’ll post that here or submit it directly to Chief if there’s interest. This isn’t a rant—it’s meant to help prevent avoidable problems and encourage practical feedback from those using the system daily. What It’s Supposed to Do: Chief now groups your plans, layouts, and assets into a single project file (.caproj) stored in your Documents folder. Chief manages the structure and linking. This is meant to: • Keep everything organized • Eliminate broken plan-layout links • Simplify project sharing and exports That’s the goal. But it’s not quite working as intended yet. What’s Not Working (and Why It Matters): 1. Layouts lose their links to plans when imported. You have to reconnect them manually every time. Risk: Incorrect or mismatched plans can get printed or submitted—potentially triggering permit rejection, construction errors, or liability for the designer. 2. Duplicate files are accepted without warning or distinction. Chief allows files with the same name to coexist in the project—even if they contain different content. Risk: Users can unknowingly work on the wrong version, or issue a file that appears correct but contains outdated or unapproved content—risking rework, confusion, or legal exposure. 3. No metadata or file history is visible. No tracking of who made changes or when. Risk: Teams have no way to verify the status or history of a file, leading to loss of accountability, inability to verify approvals, or untraceable errors in submitted documents. 4. There’s no clean way to share or extract a subset of a project—like multiple design options. You can export/import individual files, but not a bundle that retains internal structure or references. Risk: Collaborators can’t isolate just the pieces they need, and reviewers may receive extraneous or obsolete content—introducing major clarity issues and potential misinterpretation of the design intent. 5. If a team member is unavailable, their work is locked away. Project containers live in hidden folders. No export = no access. Risk: Deadlines can be missed, approvals delayed, or teams left unable to submit or revise work without access to another user’s machine—an operational and contractual risk. Why It Matters: These aren’t just workflow annoyances. If a designer delivers incorrect plans, or can’t deliver at all, the blame lands squarely on the designer—not the software. These failure points can trigger missed deadlines, rejected permits, lost revenue, or worse—career and legal consequences tied to what should have been a manageable design flow. What Would Make It Better: • Prompts on import for duplicate filenames • File tagging (draft, issued, archived) • Metadata tracking: author, modified date, version • Support grouped import/export of project subsets, like multiple design options, with links and structure intact • Persistent plan-layout linking across exports/imports • Shared-access fallback or override for unavailable team members Happy to share the full document if folks are interested. It goes deeper into each point, shows examples of where these issues crop up, and offers practical suggestions. Thanks for reading. Hope this helps someone avoid trouble.

Don't let him kid you ... It was spite, pure and simple. Hahaha! I had high hopes that I could use RTRT on my new killer 16" M2 Max MacBook Pro (12 CPU cores, 38 GPU cores, and 96GB RAM!). So, last February, I took it with me to our Chief Experts Total Immersion Summit to try it out with Rene's new state-of-the-art external GPU ... but the GPU didn't have Mac support. And I had already exceeded my return window. Still love my Macs but -- I have to admit -- I did cry a little.

@ChiefPat971What these gentlemen are saying is that you’re working too hard at your testing. Chief works beautifully when you understand it. It appears that you’ve interpreted “exterior” and “interior” layers to be only the outer visible surface materials, and all else to be the main layer. The main layer should be only those things that make up the structural thickness of the walls. In this case, just the block itself; not the insulation, plaster, etc. that is applied to the structural block. The sprayed on insulation, air gap, interior and exterior material coatings, paint, etc. are all part of the inner and outer layers, inconsequential to the structure itself. If you design your walls that way, things will work out much better.

Well, that’s interesting. Because there’s no ”cabinet” directly below it, it probably is considered an “upper counter”, “elbow bar”, or “breakfast bar”, so it probably gets a gimme. But, because those same forward thinking code teams that approved a change to prevent .0002% of the people from hurting themselves might not realize that a cord is long enough to hang off either way, it might fail. I hate your kitchen design, by the way. Too many counters. Lol.

Just received an email from my electrician who forwarded a write up in Electrical Contractor magazine (www.ECMag.com) addressing this issue. The last paragraph of that article suggests that “One interesting solution is to raise the counter height for seating on one side. This creates a vertical area in the countertop for receptacle outlet placement”. So, basically, the same thing that has been done since the 1980’s … that every designer is trying to get rid of. LOL.

Interesting that they don't offer a correction on that ...

Electrical manufacturers don’t advertise, so when they want to sell a bazillion of their product they just come out with something (like pop up outlets) and work to get them mandated into the code. FYI … The NEC is revised by the "National Fire Protection Association’s Committee on the National Electrical Code". The organization is composed of 18 code-making panels (CMP) with IEC representatives on each panel as well as manufacturers, inspectors, users, installers, labor, consumers, testing labs, and special experts. If you really do want to see this change, there is a process … but it may take a while. In the mean time, the NEC is designed to be adopted by local and/or state governmental bodies. Local jurisdictions may choose to adopt the code in its entirety, with specific additions or exceptions, or they may choose not to adopt the code at all. Your best hope (any of you) is to contact your local jurisdiction and argue the ridiculousness of this code change before it gets adopted in your area.

Anyone hurt is too many, thus the reason for the codes in the first place. But, “you can’t save people from themselves” … Just gotta play the odds. And, based on the number of lottery tickets sold every week, 1 out of million may sound like a pretty good chance, but really we’re talking about .0001 percent of the population. The degree of “hurt” wasn’t clear, though they did end up with a hospital visit. I wonder, though, how many other injuries in the home also resulted in hospital visits. My guess is that this very small percentage is an even smaller percentage when compared with all the other things that could happen in a home. What might be next on the chopping block? Fireplaces? Stoves? Staircases? Tubs? Showers? There’s a point of reason here, and they’ve clearly exceeded it. I’ll climb down now off the soapbox. Thanks for allowing me to stand there for a minute.

Oh my God! I didn’t notice that! I stand corrected ... So, then, 162 per year! 162! That’s .00002%!

Countertop obstacles, aesthetics, and convenience aside, let's put this in perspective, just for grins ... The driving motivation for this code change was the CPSC's concern for safety in the kitchen (just the kitchen, mind you ... As it turns out, there are plenty of accessible receptacles in other parts of the home) ... Consumer Product Safety Commission (CPSC) data shows that between 1991 and 2020, an estimated 9,700 people, many of them children, were treated in United States emergency rooms for burns and other injuries after pulling on or running into power cords plugged into outlets installed below the island /peninsula work surfaces. So, of the 137,400,000 housing units in the United States, 9,700 people -- "many of them children" (so we can assume that it wasn't "most of them" -- hurt themselves by misusing common electrical receptacles. Assuming half of that number were children (4850), that's .004% -- or four thousandths of one percent -- had problems keeping their children away from the kitchen island electrical outlets. "Stop it, Junior! Get away from the island and go stick that in the outlet by the table!" Yeah, that seems like a good reason to inconvenience the entire rest of the country ...

For jurisdictions that have adopted the International Residential Code (IRC) — at least up through the ‘21 edition — the IRC still requires any countertop over 12” in width to have at least one receptacle, which means that an island is required to have at least one. Any requirement for additional receptacles is established by the typical determinations (24” from an edge/corner, etc). Receptacle type, capacity, and “placement” within the IRC requirement must adhere to the NEC rules, except that the IRC also disallows a receptacle to be underneath any countertop protrusion over 6”, which screws up my typical preference for making two of then readily available yet still out of sight by tucking them just under the countertop on the pilasters supporting the island’s dining ledge. No telling what will be in the ‘24 edition of the IRC, but that’s the way it is for now.

@MarkSirianni, @Chrisb222, Did you reach a conclusion? I also use a 16” MacBook Pro, as do several others here, but have not had the issues you’ve described. There is a thread on ChiefTalk that I’ve participated in regarding image transparency causing images to print as solid almost-black boxes, but I don’t think that is what you’re describing, right? My 2019 MB Pro 16” works well the way I’ve been using it, and I’ve not had the problems you’re describing, though I did load it with all the RAM it would hold. I’ve been advising another on the possible use of an eGPU solution and am curious about your conclusions.

Read back through this thread for a history of contemplation and consideration on this issue. We know the technical reasons why. What we don’t know, or didn’t at the time, is whether or not this issue can be addressed by the PDF generator in the first place, preventing it from becoming a problem at all.