DEV Community

taku25
taku25

Posted on

✨ Supercharge Your Unreal Engine Workflow in Neovim: This Week's HUGE Update!

#gamedev #neovim

Hey dev community!

For the past few weeks, I've been on a mission to build the ultimate Unreal Engine development environment right inside Neovim. This week, I've added a bunch of new features that I'm super excited to share with you all! Let's dive in. 🚀

🛠️ New Features That Will Change Your Life

Instantly Understand Your Class Hierarchy with :UEP find_derived & :UEP find_parents

Working with inheritance is a daily task in Unreal. Now, you can navigate your class trees without ever leaving your editor.

:UEP find_derived[!] [ClassName]

Ever wonder which classes will break when you change a virtual function? This command instantly shows you all child classes inheriting from the class under your cursor. It's a lifesaver for refactoring.

Use it with a bang (!) to pull up a picker and select any class in your project as the base.

find_derived

:UEP find_parents[!] [ClassName]

The opposite of find_derived! This command shows you the entire inheritance chain from your current class all the way up to UObject. It's perfect for quickly understanding a class's lineage or finding which parent's virtual method you need to override.

find_parents

Say Goodbye to Manual #includes with :UEP add_include

This is my take on Rider's awesome auto-import feature. We all know the class we need, but who remembers the exact path to the header?

Just place your cursor on a class name and run this command. It will automatically insert the correct #include directive in the perfect spot:

  • In .h files: Right above the .generated.h line.
  • In .cpp files: After the last existing #include.

And yes, you can use it with a bang (!) to search for and include any class you want from a picker!

add include

Make gf Actually Work for Unreal Engine with :UEP open_file

Vim's built-in gf (goto file) is great, but it often fails with Unreal's complex directory structure. :UEP open_file fixes that by using the plugin's project-wide cache to intelligently find and open any included file.

You can make it your default gf with this simple keymap:

// in your init.lua or keymaps.lua
vim.keymap.set('n', 'gf', require('UEP.api').open_file, { noremap = true, silent = true, desc = "UEP: Open include file" })
Enter fullscreen mode Exit fullscreen mode

🎨 UI & Performance Boosts

  • More Rider-Like Project Tree (:UEP tree): The project tree now organizes plugins under their respective Game or Engine folders and includes files from Source/Programs. It looks and feels much more like a traditional IDE.

Image tree

  • Blazing Fast File Search (:UEP files): File searching is now ridiculously fast. It uses an internal cache, so after a one-time initial load, the file picker appears instantly. (Just remember to run :UEP files! if you add or delete files to refresh the cache!)
  • Smarter Class Creation (UCM new): When creating a new class, you can now see a preview of the parent class's header file before you select it. No more guessing!
  • New UI Picker Support (UNL.nvim): Added support for the awesome snacks.nvim. Now you can get a great UI experience even without Telescope or fzf-lua.

🔧 Config & Behavior Tweaks

  • Better Cross-Platform Support (macOS? 👀): You can now manually set your engine_path in your config for UEP.nvim and USH.nvim. This should help anyone whose engine path isn't automatically detected. This might even get things working on macOS!
  • Safer Cache Management (:UEP cleanup & :UEP purge): Clarified the behavior of cache-clearing commands. cleanup nukes all caches for a project, while purge only removes the file cache for a specific component.
  • More Accurate Project Parsing (:UEP refresh): The core project analysis logic got a tune-up for better accuracy.

🐛 Bug Squashing

  • :UEP cd / :UEP delete: Fixed a bug that caused preview errors when using Telescope as the UI.

💬 Let's Talk: One Plugin to Rule Them All?

That's it for this week! I'm getting to a point where I can comfortably stay in Neovim for almost all my Unreal development, which feels amazing.

But something's been on my mind: with all these specialized plugins, is the initial setup getting too complicated?

I'm starting to wonder if I should merge everything into a single, massive UnrealDev.nvim plugin.

  • Pro: Super simple, one-line installation.
  • Con: Less modularity for users who only want one or two features.

What do you all think? Should I keep them separate or go for the monolith? I'd love to hear your thoughts in the comments!

And of course, if you find these tools useful, a star on GitHub is always appreciated! It really keeps me motivated. ⭐

Thanks for reading!

Top comments (0)