BenMerritt

If you're using a font that doesn't actually have an italic variant installed, trying to make some instances of that font italic can cause issues when printing. You may want to look in the system font settings (Start → Settings → Personalization → Fonts) to see if the font you're trying to use has an italic face.

GPU issues like this often involve very specific hardware/software combinations that are extremely difficult to reliably replicate. We can run tests all day on a Windows 11 machine with a GTX 1050, but the chance that it'll behave the same as your machine with your GTX 1050 is slim to none. It's frustrating for both us and our customers, but it's an unfortunate reality in the world of graphics programming. We're well aware of these techniques and use them where appropriate. These "Device Removed" errors are a specific class of error that is nearly impossible to recover from without restarting the entire rendering subsystem, which is an extremely complicated operation. As far as reporting goes, our rendering team has found that even a full stack trace and all the diagnostic information we're able to glean from the GPU drivers is rarely enough to reliably diagnose this kind of issue. On a system with correctly functioning hardware and drivers, a userspace process should be completely unable to cause a blue-screen condition; the operating system is, by design, responsible for preventing any operations that would lead to one. Any case where an application can trigger such a condition is a driver or hardware problem. There may sometimes be a corresponding bug in the software that triggers the driver bug, but in many cases, the software isn't doing anything technically "wrong"; it just encounters a condition that the drivers were supposed to handle correctly but failed to do so. We've found that trying a variety of driver versions sometimes fixes these issues, but it's still a hit-or-miss process.

For cases where you've got a specific action you're trying to carry out in a specific plan, and the software consistently performs more slowly than you'd expect, it's generally best to submit a case to our tech support team with the plan file and full details on how to trigger the slowdown. Especially in cases like this where it's just hanging for a few seconds after a specific operation in a plan view, there's often analysis we can perform with our debugging tools to isolate the cause.

This sounds like a known issue in X12 on Macs with Retina displays. Using a non-Retina screen (or possibly reducing your screen resolution) may help. Another workaround is to take a screenshot of the PDF in the Preview app and import that into your plan as an image. If what you're experiencing is in fact the issue I'm thinking of, it's also fixed in X13.

We do keep debugging maps on hand for precisely this scenario, and they're often quite helpful for at least narrowing down where to look for the issue.

If you print a view with just CAD in it, you should generally get a vector PDF. There are some things that will add raster elements to the PDF, such as: Embedded raster images Other PDFs embedded in the plan/layout Camera/elevation views (except for plot-line views without color fill) CAD with transparent lines/fills (when not using Chief Architect Print to PDF)

It looks to me like this is already possible. Binding "Straight Exterior Wall" to "W, Space" and "Curved Exterior Wall" to "W, C, Space" works as I'd expect it to on my machine. Of course, this requires manually customizing your hotkeys.

In that case, if you can get away with it, I'd just use soffits. They're a little clunkier to edit, but at least in real life, a non-recessed tray ceiling is basically just a soffit.

The issue is that the ceiling finish in the family room and the hallway is different from the ceiling finish in the dining room and kitchen, as you can see if you delete the tray ceiling: Tray ceilings will "flood fill" into adjacent rooms through invisible walls if the ceiling heights are the same. This is useful for non-recessed tray ceilings, but it's admittedly less useful for recessed ones. Changing the ceiling material in those rooms to all be the same color would fix the warning. Alternatively, if you want to keep the color difference, you can use the "Explode Tray Ceiling" command to break the tray ceiling polyline down into its component ceiling planes and then pull back the large "outer" ceiling plane that has overflowed into the adjacent rooms:

Ouch. Having spent an hour this morning on the phone with my Internet provider, I feel your pain. We don't have an official list, unfortunately, although I'd like to see us provide something like that in the future. (I'm not the one who manages that sort of thing, though). We generally try to keep an eye on the forums and note issues that our customers are running into, though (gotta do something while the code is building!), so dropping a thread here or contacting the support team, although perhaps not the most expedient solution in all cases, is probably your best bet for the time being when Chief behaves in a way that seems unexpected.

There's a known issue in X13 (sorry, my fault!) where form fields in editable PDFs won't render correctly. I'm working on a fix. In the meantime, you may be able to work around the issue by opening the PDF in your preferred PDF viewer, printing it to another PDF, and importing that into Chief.

As currently designed, tray ceilings will "flow through" invisible walls, with the main goal being to allow tray ceilings to span multiple rooms. Exploding the tray ceiling is probably the easiest way to override that behavior in this case, at least if you're planning to recess it into the ceiling structure above it.

The tray ceiling has automatically "overflowed" from the dining area into the kitchen and the great room because all three rooms have the same ceiling elevation. If you set all three rooms to use the same ceiling finish, the error will go away. Alternatively, you can explode the tray ceiling and "cut back" the large ceiling plane to fit in just one room.

The resolution after import will depend in part on whether your PDF contains vector data (lines, arcs, etc.) or raster data (i.e. scanned images). As a general rule, if it doesn't look sharp when you zoom in using another PDF viewer, it won't look sharp in Chief. If you have a PDF that does look sharp in other viewers but is pixelated in Chief, that can sometimes happen in X12 and prior versions for particularly complicated PDFs. The best workaround for now is to convert the PDF to a high-resolution image using external software and then import that image into Chief.

If I recall correctly (haven't worked on doors for a while), this should be coming from your interior/exterior door defaults. Basically, symbol doors use the plan's "generic" default materials, while parametric (non-library) doors pull their materials from a specific default door. Also note that unless you check "Separate Trim and Materials on Each Side" (General panel), interior doors will only use the interior material, not the exterior material.

X13 should include a fix, at least for the versions of this problem that we've studied so far.

The short version is that Chief is trying very, very hard to find the best place to put the move handle. This polyline, in addition to its complexity, is shaped in a way that makes one of our internal algorithms have to sift through more data than usual, and it bogs down. The marquee select bypasses that part of the code. Unfortunately, the issue is likely to persist after extruding the polyline. Converting the solid to a symbol should help, though.

If this is caused by what I think it might be, then yes, that's precisely the issue. Reducing the number of spline segments before converting the splines to polylines would have improved the performance somewhat (at the cost of reduced detail).

For splines, you can do this with the "New Segment Angle" option: I suspect that I may know what's causing the slowdown in this case, although I can't confirm that with certainty at the moment. You may be able to work around the issue by marquee-selecting the spline instead of doing a single click. If you do end up submitting this to tech support, feel free to suggest that they send it my way so I can at least make some notes on it; that may make it easier for us to triage the issue.

There might be nothing wrong with what you're doing to import the PDF. On Macs with Retina displays, we've found that PDFs will sometimes be drawn at the wrong resolution, and this may be what you're seeing here. You might find that running Chief on a non-Retina display helps, if you have one available.

By design, the ceiling plane will extend across room divider walls when the rooms on both sides have the same ceiling height. This can be rather confusing behavior at times, especially for recessed trey ceilings, but without that behavior, it would be more difficult to produce trey ceilings that intentionally span room dividers. One way to deal with these cases is, as Eric suggested, to draw a regular interior wall and add a doorway that covers the entire wall surface. Given the configuration of the walls in this plan, though, it's probably easier to use the "Explode Trey Ceiling" tool and then pull the edge of the ceiling plane back so it doesn't extend into the kitchen area. Of course, then you'd probably want to put that ceiling plane on a layer that's hidden in the plan view so it's not cluttering the drawing. Neither of those is really a perfect solution, of course, but hopefully it'll get you into a state where the plan at least looks the way you'd like it to.

If you have any suggestions on what you'd like to see improved with it, I'd be happy to hear them. The diagram in its current form wasn't really designed to be a true "preview"; it's currently only useful as a rough guide to the meanings of the various height controls, which makes its value pretty limited for experienced users.

I haven't looked very closely, but the issues with the images in the most recent comparison look to me like JPEG compression artifacts, which have nothing to do with the ray-trace itself. If the screenshots were compressed as PNG (or as JPEG with a higher quality factor), they'd probably look better. (Of course, then they might be large enough that they would exceed the limit on the file size of attachments.) Then again, I'm working using a remote desktop tool, so everything on my screen looks it has JPEG compression artifacts...

It's also possible to leverage the unit system to handle the conversion for you, which is useful when you don't want to look up conversion constants: area.convert_to("sq m").round(2)

This behavior (at least when the rooms on either side of the divider have the same ceiling height) is actually intentional; it tries to "flood fill" the largest area of flat ceiling possible so it's not left with awkward gaps that can't be filled except with manual custom ceiling planes. Additionally, without that behavior, it would be impossible to have a trey ceiling polyline span a room divider, which is useful for some kinds of "open plan" designs. What is a bug is having it span room dividers when the ceiling isn't flat. That should be addressed (at least for the common cases) in the next update.