BenMerritt

If you don't have easy access to the currently activated computer, it's also possible to deactivate remotely from your Digital Locker. This knowledge base article covers the procedure.

In my experience, C:\ProgramData shouldn't be stored in the cloud. Windows 11 likes to put many of your user folders (Documents, Pictures, etc.) in OneDrive, but I've never seen it try to sync files outside the user directory. You might try creating a new empty folder under "C:\ProgramData\Chief Architect Premier X16" to verify that your user account is able to access the directory outside of Chief Architect.

Cases like this particular one are tricky to model automatically because of topological issues; we try to punch a hole in some of the generated ceiling planes, but if that hole goes right up to the edge of the ceiling plane into which we're trying to punch it, that breaks the geometric representation. If you add the tray ceiling before the fireplace and then explode the tray ceiling, you may be able to manually edit the ceiling planes to achieve the effect you're looking for.

I'd still expect the performance overhead to be relatively close to that of 100 text objects without the hyperlinks. I haven't benchmarked that or looked through that part of the code, though; that's just my intuition based on the general principles by which our text objects tend to operate.

I'm not the one who implemented the hyperlinking features, but I'd be surprised if they caused a measurable performance difference while working with the plan, especially if you're not adding hundreds or thousands of them.

The default behavior is to reference the PDF as an external file rather than embedding it in the plan file. This has relatively little effect on how quickly the PDF draws in a plan view, but it does affect the plan file's size and the speed of some other operations (e.g. undo/redo). For those operations, referring to an external file should generally be faster.

Out of curiosity, when was the last time you tested this? We made some significant improvements to PDF rendering performance in X13. There are still cases where performance can suffer — printing being one of them — but when just importing a PDF as a drawing reference, the software should be much more responsive than in prior versions.

If you are in Pixels mode and increase the DPI value without also increasing the number of pixels, all that does is change the metadata in the generated image. This may affect the physical size at which some programs import the image (with higher densities meaning the image will appear smaller), but it won't change its sharpness.

I'm not seeing any obvious leads in there, unfortunately, except for the possibility of generic network errors. Sorting it out would probably a very deep dive into Firefox's internals — to the point of making a custom build of Firefox and attaching a debugger, which I'm not set up to do. Given that you're able to load the videos in other browsers, it's probably not an issue with your Internet connection. My troubleshooting toolbox is pretty empty at this point, but I'll keep an eye out in case I stumble across anything that would shed further light on the situation.

Very strange. Debugging this one further would probably get farther into Firefox's internals than I'm set up for. Something's obviously different with how it's trying to read and play the video, but it's difficult to say what the difference is without actually reading Firefox's source code. As a last-ditch effort, you might try the following: Open the Browser Console (Ctrl+Shift+J). This contains log messages generated by the browser itself rather than the current Web page. Switch the Browser Console to Multiprocess mode. Clear the console so you've got a clean start to the message history. Open the direct link to the video. See if there's anything obvious in the console window.

If Firefox is unable to play the video from the direct link, that seems to suggest some kind of video codec issue. Do you have any video codec plugins installed? Here's what Firefox has installed by default on my machine:

It looks like your browser is trying to load a lower-resolution version of the video than most browsers will use, which is definitely odd. Does the video play if you open it directly from this link?

I should note that PDF rendering performance has improved significantly starting in X13, and it should be much rarer for an embedded PDF to cause slowdowns, especially ones that entirely block interaction with the plan. If you've observed slowdowns with PDFs in current versions of the software, I'd encourage you to submit a bug report, as that's very much unexpected behavior.

Hmm. Those all look unrelated to the video issue. I think that the last one in particular is extension-related, and the first one shows up on my browser as well (which does play the video). I'd be curious if the video is actually loading. In the Network tab of the Inspector, there should be at least a couple of requests to load the video. On my browser, there's one aborted request followed by an incomplete one. The incomplete state makes sense since the browser is trying to stream the video and hasn't reached the end yet. Do you see the same thing in yours?

I'm unable to reproduce the issue on my computer (Windows 11, Firefox 128.0.3). Does anything show up in the browser console when you try to play the video? (Press Ctrl+Shift+I, then switch to the "Console" tab of the pane that opens.)

As noted in the linked knowledge base article (the link to which got mangled in my original post; sorry about that), archives are kept in C:\Users\[YOUR USERNAME]\Documents\[NAME OF YOUR PRODUCT]\Archives on Windows machines. The path may vary slightly, e.g. if you've moved your Documents folder to another drive, but the path noted in the article is by far the most common. Underneath that, the archives are organized into folders which contain normal plan and layout files. Are you referring to the Previous Versions tab of the Windows File Properties dialog? In my experience, I've seen relatively few programs actually integrate with the Windows File History functionality, which I imagine is for several reasons: The File History feature is only an incomplete backup solution; it does very little to protect against hard drive failures. The interface to access it is fairly well buried in menus unless you know what you're looking for. It only works on Windows, meaning that, for cross-platform software, another solution is necessary anyway. This limitation is reason that we implemented the archive system, which, as noted above, does keep daily revisions of the plan file in a way that works on all our supported operating systems.

No; that's really not what's going on at all. Current versions of Chief Architect software store the entire plan in a single file; there aren't logically separate "files" inside. What the software does include in the header record is a short fixed data sequence labeling the file as a Chief Architect plan file. This is written at the very beginning of every plan file using simple, extremely well-tested code. There's nothing to get "out of sync" because we always write exactly the same sequence. If a file has a different sequence when read into the program, that means that it has become corrupted, almost certainly due to something outside of Chief Architect, such as a failing hard drive or a bug in a third-party cloud synchronization service. In nearly every case, the corruption actually extends well beyond the header record, rendering the file unrecoverable. This header verification technique is a common software engineering practice used in a wide variety of formats, including the widespread PDF format. Corruption of a plan file is a deeply unfortunate situation, but there's no programming technique that can totally eliminate the risk of data loss, especially when it's due to something outside the software's control. To help reduce these kinds of issues, we recommend keeping regular backups of your files as outlined in this Knowledge Base article. The good news is that you may not have to start entirely from scratch. Chief Architect periodically writes archival copies of the plan file as it's being worked on. You may be able to access and restore one of those archive files.

The LOAD_PATH variable is used with Ruby's "require" function, which loads an external script file into the current Ruby process. Those script files can contain basically any valid Ruby code, which makes for a convenient place to put helper classes and so forth.

If you're using Google Chrome, it has some specific restrictions on cookies that don't play nicely with our authentication flow when the page is embedded in an <iframe>. You might try adding the following attribute: sandbox="allow-same-origin allow-scripts".

What format are you exporting to from Chief? Blender seems to bring the textures in for me when using COLLADA (aside from the texture that's missing from the uploaded plan file), and it embeds them on export to glTF. Since the textures aren't embedded in the COLLADA file, though, just exported to a directory alongside it, an online converter would fail to load them unless they were provided separately. Also note that Blender won't show the textures unless you set the viewport shading mode to Material Preview or Rendered. See the button outlined in red here:

This behavior dates back to X12 Beta 2. By my calculations, 1/300 in. comes out to 0.085 mm, so between 8 and 9. With the rounding involved, slightly larger line weights than that may round down to match a line weight of 1. As an additional restriction, the line will never be thinner than one "dot" at your given DPI setting, e.g. 1/150 in. at 150 DPI.

There's a hard-coded minimum line width of about 1/300 in. for PDFs (when using "Chief Architect Save As PDF") in order to mitigate issues where zero-width lines would come through as extremely faint in many PDF viewers.

Technically speaking, MacOS is a UNIX derivative, but not really Linux; it uses the XNU kernel instead of the Linux kernel, and many of its userspace utilities are either BSD-derived (rather than the GNU utilities that most Linux distributions use) or proprietary. It's more similar to Linux than Windows is, but the parts that are most relevant to Chief Architect (especially the GUI components) are still radically different from MacOS. I'm an avid Linux user myself, but despite recent improvements and slowly growing market share, it's not really the "year of the Linux desktop" yet. I wouldn't call a Linux port impossible, but it'll likely be a significant amount of time before such a project begins to make sense from a practical perspective.

That's likely due to the computational cost of encoding the final video file.

It's possible to override this behavior if you open the library object for specification and change the type on the Options panel.