It’s not bad, I had a tinker with it last night to compare it with my own experiments.
The biggest issue you have right now is performance - framerates are way, way lower than they should be and I don’t think this is just a lack of LoDs. It might extend from the fact you seem to be doing an awful lot inside tick, which is generally not adviseable.
There are two major overhauls I would recommend before going any further and implementing new features:
A) Stop doing all your logic inside of a pawn class. Pawns are representations of player objects and are optimised as such - you should really be using a custom actor. Your player controller class is what should be handling input, though for the sake of your demo it’s not too bad to do this in your pawn. You want to split your input handling (i.e where is my cursor), your terrain editing modes (which tool am I using) and your actual terrain into three different classes. This will make the project easier to manage, and allow for variations without having to pick apart an entire class for that purpose. The more you break it down, the more flexible it will be; for example foliage handling could be a discrete class that you can swap in and out to create different biomes.
B) Stop doing things in tick except things like polling the mouse cursor location. If you’re doing a lot of things every tick, you’re slowing your whole game down. Break up your logic into multiple discrete functions and call them on an event-driven basis. This should help you sort out performance problems, and also makes the implementation cleaner, easier to manage and more flexible in future.
Doing this work now will save you enormous hassle later.
Edit: I forgot, but there’s a nitpick that’s an easier fix and will help you clean your spaghetti up a bit:
C) Learn to use structs and enumerators - there’s a few places where you’re using strings or piping lots of single, but related variables through functions. Turning these into structs and enumerators will help clean up your blueprints.