The SDK I'm writing, in an ideal world, would be C++14 compliant rather than require C++17, but there's just so many nice things added in C++17 that are hard to give up - one of which is std::filesystem for handling paths in an agnostic fashion.

So to deal with this, we use ghc::filesystem - a C++14 compliant backport of the std::filesystem namespace. It's really quite nice, we no longer have to worry about a whole bunch of string parsing or dealing with platform-specific path separators or even things like checking if a file exists.

filesystem::path tmpPath("/some/path");
tmpPath /= "somefile.txt";

std::cout << tmpPath.c_str() ; // prints /some/path/somefile.txt
if (filesystem::exists(tmpPath))
{
  //do something to read in the file here
}

Everything's been working so far, until we start wrapping the SDK in an Unreal Engine 4 plugin, for our partners that want to access the SDK via blueprint.

My current contract is for a SDK that uses asio as an asynchronous event loop, and standard practice for asio projects is for callbacks to receive a std::error_code as a status indicator. std::error_code is pretty useful, but requires a fair bit of boilerplate if you want to create your own codes.

To ease that process, I've cooked up a code-generation process that can be driven by CMake to produce a nice header for all the error categories and codes we return to consumers.

I've been doing a lot of work on a project recently that reads in configuration/modding data via command-line flags and tables stored in a text-based file format. The format is terrible, full of idiosyncrasies and inconsistencies depending on the type of table being read in.

The original parser for these was C-based and used a line-by-line system that stored a pointer into a file and advanced that pointer as tokens and rules were consumed. I really didn't like it at all, and for reasons mentioned below it was a real pain to refactor its dependencies. Clearly I was going to have to use an alternative.

Opened up my personal project earlier today and ran into a nasty crash when trying to load an instance of my proxy texture asset class. The crash was occurring here:

void* Data = RHILockTexture2D(DynamicResource->GetTexture2DRHI(), 0, RLM_WriteOnly, Stride, false);

DynamicResource was valid, all looked okay, until I could see further in that the result of GetTexture2DRHI was not valid, even though I'd already called to initialize the resource beforehand. What was going on?

One little gotcha that isn't really well documented with manual keyboard/controller focus in UMG is that if a UI element is not visible when you attempt to set focus to it, that call to SetUserFocus silently fails. What you're going to need to do is either set visibility first (easy enough) or if there's an animated transition that changes Visibility, you're going to want to wait until that transition is complete before doing so. I ended up making the following Blueprint macro to do this, it has a rather unwieldy name but I wanted to distinguish it from other macros I created for subwidget navigation that didn't require animation transitions :

So I finally got around to overhauling this old site. Been meaning to for a long time, but I never really had the opportunity to do so. The old version was all handwritten html, which looked okay, but was a real pain in the behind to update with new work, much less include something like a proper blog.

I'd been looking at static site generators for a while. If you don't know what they are - they basically let you write posts or content in Markdown or some similar 'language' and then process all your posts into static HTML pages your website can serve without needing some kind of special serverside service or database. Hugo and Jekyll are the best known examples I think - Github supports both via github pages.

If you've got an Actor component that needs some kind of in-editor representation, to make it easier to tweak settings like size or falloff, but you aren't deriving from something that would be rendered in editor like a StaticMeshComponent, you might want to use a custom component visualizer.

Let's say you have something like a ProceduralMeshComponent that draws a flat grid of polygons that will be deformed at runtime. You might want to have a representation of the grid like the following image:

In order to do this we can create a FComponentVisualizer subclass.

Creating a custom project settings page is pretty easy, if you don't want to inherit from UDeveloperSettings and use the automatic registration process.