Right, time to make some more UE tooling, this time so we can define hand-authored but also somewhat randomised "chambers" for our procgen.

Back to the Slate mines! It's been just long enough since I last did this that it's confusing af again. I have shaved enough yak to at least get a custom asset editor window working, but there's a fair way to go. I need a custom world instance for this one too which I've never done before. Wish me luck, I'm going in 🫡

Yaks shaved: 0️⃣0️⃣6️⃣
After a tedious amount of boilerplate extraction from the UE source code I have a viewport in my custom asset editor. It doesn’t *work*, but it IS there and at least pretends to have all the viewporty things. Tomorrow will be figuring out which yaks still have hair on them that’s stopping it working
Well, it turns out my viewport was working after all, it was just a variant on the black triangle rendering black on a black background kind of problem. Once I got the settings right it started to work 🤷🏻‍♂️

I was a bit worried that all the asset editors in UE just seem to attach scene components directly to the preview scene, and don't use any actors. Unfortunately for this asset I really need to have actors in the preview scene because that's how my map generation works.

However, by pulling the UWorld out of the preview scene, it seems perfectly possible to create actors there and they seem to behave as expected. This UWorld is created separately by the looks and I can even tick it if I want?

Yaaaas 👌

It's not much to look at, but the fact that I've got a modifiable map working inside a custom asset editor, being updated and all the subsystems working has been a bit of a mission.

The idea is that there will be a stack of operations you set up to carve out a chamber which becomes a component for the procgen. Obvs there will be plenty of parameterisation / randomness within that so it's not identical all the time. Lots still to do but we're on our way.

Onwards!

I was lucky that I'd already refactored a bunch of my code subsystems from being game / global state to being world state - which comes with a few more initialisation wrinkles BUT it means it's much easier to do this kind of isolated editor world thing. There were still some issues specific to doing asset editors, such as world subsystems needing to say they're OK with `EWorldType::EditorPreview` (which is not the default), but I didn't have to do any major surgery. 👍

Oh god I've just realised I've got to do a tree control for this one, so that you can group operations, both for organisation and for doing logical operations on sets of changes (E.g. randomly do this group of operations or not, or select one group from a series etc)

I've used tree controls in Win32, WPF, Qt, Cocoa and more and they're *always* a PITA. I'm not starting that on a Friday! 😄 I'm out, have a good weekend everyone! 🫳🎤

@sinbad Once you get past the gag reaction, I think the one in Slate is not that bad :)

After many iterations, I found out that it was easiest to have a middle-man layer (call it controller, or model-view or what not), that held a cached version of the data for your tree view and also the selection.

It helps with some corner cases of updates (i.e related to UObjs and undo) and gives central place to dispatch selection related things (i.e. updating details to the selected item).

@MikkoMononen Thanks! Are there any samples or bits in the engine you think are good examples?

@sinbad Probably any of the never systems should have pretty good patterns to pick, but they are likely all so complicated by now that it might be hard to find the gist of it.

The SO editor has the pattern I mentioned before, but I cant remember anymore at which state it is in.

I learned a bunch from dissecting deformer graph and anim rig editors.

@sinbad Oh, I bet that’s been a long quest.