Smn842

Windows has actually supported very long (approx 32K) path lengths for a very long time as NTFS supports it. However to use such long paths instead of the usual MAX_PATH 260 character limit applications have had to use the applicable API version and specific prefix option and this is often not done hence the failures on long paths. Even though Windows APIs have allowed 32K paths for a long time its taken a while for more of its own applications and utilities to catch up and use these features. The same goes for commercial applications where software developers are wary of allowing paths of a length that may then be hard for users to manipulate with file managers, archive tools etc if they don't support longer paths. What changed from Windows 10 is that the need to use special options within applications can be avoided using the registry flag AND if an application has a manifest that indicates it supports this. The reason for this application opt in is that applications could crash with longer paths depending on how they're written if they were forced upon them.

There seems to be a few more stability issues with high end stuff these days as the manufacturers are pushing the limits on every part. I have just built a 14900K and its Performance Active-Core Ratio is 57 and all works fine in Chief with a 3090. Many motherboards also increase the default CPU power limits by default which can be an issue for cooling as well as stability. RAM issues which manifest in all sorts of ways also seems to be a more common issue with the 14900K and certain motherboards (mostly lower layer count ones which affects track length variation) when using higher clocked RAM. I am lucky the DDR5 6400 in that new build is fine with the motherboard and CPU to date and passes full memory diagnostics (MemTest86 as its more thorough than Windows built in check). I didn't risk any faster RAM due to this and diminishing performance gains so I went for a good balance of latency and speed. It's always worth doing a memory check on a new build and I am now doing them every 6 months or so on key PCs after having 20 bits fail out of 128GB in another PC after some time which first showed up due to failed Macrium Reflect image backups as they cause windows to use most of the RAM for file caching.

@Custom_CraftIf not done already please raise this in either Suggestions or email to CA. I've been suggesting door inset control for 5 years but the more people that ask for it the better. Windows do already have inset control and that works for my cases at least, but we do need it for doors as none of the workarounds are 100%

I'm not a Mac user but have you done a hardware test on your RAM? I believe there is a built in test on some Macs at least during boot. Your type of issue is often driver or other software related but I've just replaced some RAM on one of my home servers (not EEC as desktop hardware) as it was starting to have infrequent file corruption issues on very large file transfers. It turned out to be just over 20 bits (not bytes) out of the 128GB was faulty and further testing found just one of the four sticks was the cause. It was only when the OS disk caching used so much memory to cache the error appeared. It's rare to have faulty memory but its worth ruling it out at least as it does happen.

I've had the GPU issue with layouts and several PBRs and first reported that to support almost 18 months ago. For layouts with many PBRs it can exhaust VRAM and freeze the PC until Chief eventually crashes. For fewer PBRs there can be delays and high VRAM use. I didn't get very far with support as once they knew I have two GPUs they said that wasn't a supported configuration. However the problem still occurs even with one GPU so that's not the cause. It appears Chief is holding onto video resources when updating multiple PBRs for layout rendering and it gets even worse if printing it to PDF. I now just avoid a layouts with too many PBRs.

Not if the SSA is on an existing legacy perpetual license as any new upgrade versions are also perpetual licenses according to this post:

Are they on a locked layer? Posting the plan would be the best way to get a quick answer.

A clearer example from a random UK supplier site showing the moisture run off and weep joints:

One of my machines is i9-13900K and its on air and although it certainly runs hotter than some other CPUs its not thermally limited by any significant degree. I would check the liquid cooling system for correct radiator/inlet/outlet orientation/air presence, CPU thermal compound and overall case air flow management. The last seems unimportant to many but gaps where potential inlet fans could be mounted can ruin overall air flow on what should be a positive air pressure arrangement. Also bear in mind that the i9-13900K can run over 80 degrees without issue and that its a mix of 8 performance cores and 16 efficient cores with 32 total hyper threaded cores and the 6900K was 8 performance cores yielding 16 hyperthreaded cores so not all cores are equal in purpose. The i9-13900K should still way outpace your older system but temps may be higher and any issue with cooling will seriously affect it.

In your video you've not clicked the 'Search subfolders' button:

Since the Studio and GRD drivers have existed I've done a binary compare on the files a few times to save time with un-needed driver installs. Other than a few bytes that often change when packaging exe files and what could be a flag so the build knows which type it is, they have otherwise been the same. So Studio at present is just a subset of the more frequent GRD builds.

I think CA are in a bit of a rock and hard place with UI. I've worked in development on two large applications that grew hugely over time with developers mostly deciding the UI and then at some point the company employs a dedicated User Experience (UX) person and they analyse usage for typical tasks (and telemetry if available) and design a better UI which is much more efficient for most users and most work. The problem is do you change it all at once and risk alienating long term users or just make tweaks items here and there and better design new features although that is always a compromise at new features need to have consistency with the older ones. I think Chief needs a complete UI makeover with less modal dialog boxes where feasible, but I feel the pain of development teams and users alike with this problem! The only thing I've done in the past with smaller changes like Chief make between releases is to add a User Interface Changes section to release notes so that users are aware of changes and ideally the reason. Normally a dev task record will have a 'Documentation Changes' and 'UI Changes' type detail so this isn't hard to track for release notes.

I had one XL and it was so useful I thought I must buy a backup one in case of failure. Then I thought well why not use it as it's only collecting dust! I arrange mine around my standard 3Dconnexion mouse and two of the same design have worked fine for a few years since Elgato updated the software for multiple devices on one system. Now I am pondering a third as backup but as I have run out of finger/hand reach it would really have to be just a spare

Glad it worked. In addition to that original workaround post I made in 2020 I did also submit this issue to support and have just bumped that case again. However if anyone affected could also submit this issue then we may get a better chance of it being fixed. My day job is software so I can say with some confidence it's not a hard issue to fix but CA may not be aware how many people use the various 3Dconnexion models.

I've just found and downloaded that configuration. From a quick check it's set to work with the X15 executable name so that is why it only applies to X15. I don't have the enterprise 3D mouse as I use 2 Stream Deck XLs for extra key type functionality so cannot test, but if you add the X14 executable name in that file as per my workaround for general 3D mouse custom settings that may fix it.