CLOSE

Archive:

2020
2019
2018
2017
2016
Subscribe:Atom Feed

"Sadness of a Broken Build"

Posted: 03 July, 2020

A Crash Jackanory

I don't normally jump on .1 releases, but I made an exception with 4.25 as I wanted to get off the beta of Niagara. That was probably a mistake. 4.25 has been fairly unstable. Hot-Reloading is flakey, and I get a regular crash when exiting the editor. Worse, the Crash Handler has suddenly become incredibly slow to dump. All of these seem to have been reported, but annoyingly, the combination masked a bigger problem, that's taken me a while to recognise.

When loading the editor I normally default to the my games' persistent level, but this hasn't been the case since I made the Dojo, I've been jumping into that to work on bits and pieces. And I started noticing that I was getting intermittent crashes when loading the persistent level... But only during play. If I switched the map in the editor, everything was fine.

The crash was in D3D11 internals, so I shrugged it off as another bit of 4.25.1 instability and merrily got on with things. But, the first rule of game dev is to always have a working build! When it came time to play my waves hands in the air semi-regular packaging of the build, it crashed. Hard. The main menu was fine, but transitioning into the game fell over. The crash was in D3D11 internals.

d3d11crash.JPG

Fuck.

My first thought was that I had something stale left over from the previous version of UE so I deleted all the usual directories from the root of the project, and everything in AppLocal. I entirely nuked UE's cache, and did a full rebuild...

Compiling Shaders

But, it wasn't that. Next step, catch it in the debugger.

At this point I wasn't even sure how to reproduce it in the editor as I'd only seen it a couple of times, but it turned out that I'd just been incredibly lucky. If the persistent level wasn't the first thing the editor loaded then it would crash within 30 seconds of being loaded from somewhere else, be that an interior, or a dungeon. I could see that there was no shader bound once I had it in the debugger (so it was dereferencing null) but that didn't get me far. Time to go Unga Bunga: I started deleting whole classes of things from the level.

First, the houses.. no change. Second, the trees... and the crash disappeared. Bingo!

There're two types of tree in the world, and five materials between them, so I deleted the leaves from both and tried again. That worked in the editor, but didn't work in the packaged build. Then I looked at the choppable trees that I'd made last week. These are two meshes; an opaque static mesh with leaves animated in a 2nd material, and a masked mobile mesh with dithered alpha that can be faded over time. When the tree is chopped, the meshes are swapped over, I begin the dither, and the mobile one is animated down. And that's when it dawned on me...

Both meshes were set to visible all of the time, and both were in exactly the same place. strokes chin Bugger... So yeah, setting the visibility of the "hidden" mesh, correctly, during BeginPlay(), was the fix.

I've not bothered to look at why that breaks something internally, but I'll need to whittle it down to an example case so that I can report the bug.

I've not had a serious issue with the build, well, ever, so that was a bit of a ride. Not sure what the moral of the story is, either, but check those flags in the editor, people! They do serve a purpose :)

Maenhîr

Sticky Mitt

Splash Screen