Bad Plugin Editor Module Dependency?

[skyphyr]

Hi all,

So I have an issue where I’ve written a plugin which has a runtime and an editor module. My uproject then depends upon this (just the runtime module, ideally).

Trouble is, the ModuleManager still thinks it should be getting a fresh editor module during the hot reload process, but whatever tracks the dependencies doesn’t think this is a dependency, so I’ll get an out of date for that module when I try cooking after a hot reload.

Only way I found to prevent this was to make either my uproject’s Build.cs depend upon the plugin editor module as well, or make the plugin’s runtime one do so. After that’s done, I can’t package for android because it now wants to jam the editor module in. So that was hosed as a work around.

Is this a bug in the module management? Was there something else I should have been declaring about my plugin modules? Or something entirely different that I need to do? (I realize I could just disable hot reload, but I’d rather fix the underlying issue properly than just throw out a feature).

Cheers,

Alan.

[skyphyr]

I’ve tried a bunch of different approaches to this (such as adding an editor module to the uproject and having that depend upon the plugin’s editor module, but all that does is add another editor module which is expected in the cooking’s dll dependency walker, but isn’t actually having a dll created on hot reload updates).

So far, it appears, if you have editor modules, then you cannot cook after any form of hot reload until you exit, compile again, then launch and cook prior to anything that triggers a hot reload. Maybe this isn’t true, but I’ve asked around a bunch and can’t find anyone who knows the answer.