Update export to Unreal using RemoteControl API instead of udp for better stability

[wywarren]

• Added new class UnrealRemoteAPIRequest for bundling the json format payload for RemoteControlAPI
• Removed UDP for ExportAsync main flow function to Unreal
• Have not refactored the other two ExportAsync overloaded functions but they don't seem to be used currently in Unreal. Can refactor if anyone flags the userflow.
• Calls Unreal using latest PR on FortnitePortingUnrealServer which has an python script that handles receiving the message and calling the internal C++ import function.
• Dependent on currently open PR https://github.com/halfuwu/FortnitePortingServerUnreal/tree/382be964bc962595833a9a4de1d05cb41195b91b which supports importing to UE5.x and auto blueprint creation and assembly under folder /Game/FortniteGame/

[hartmannr76]

Dope, I was literally just looking into setting something like this up :)

I have some general design questions

1) Why not factor out an interface to separate classes for the workflows instead of the if/else logic? Seems like it'd be easier to add new flows and keep existing ones that way 2) Is the new UE extension necessary? I was peeking at the BlenderTools repo and it seems like they just use python API and asks users to simply enable the remote execution plugin which already exists. Seems like this could just send python calls directly to UE with no additional addons. I'd be happy to look into that if that seems cleaner

[wywarren]

Dope, I was literally just looking into setting something like this up :)

I have some general design questions

1. Why not factor out an interface to separate classes for the workflows instead of the if/else logic? Seems like it'd be easier to add new flows and keep existing ones that way
2. Is the new UE extension necessary? I was peeking at the BlenderTools repo and it seems like they just use python API and asks users to simply enable the remote execution plugin which already exists. Seems like this could just send python calls directly to UE with no additional addons. I'd be happy to look into that if that seems cleaner

The additional addons I've added are partially the existing stuff they're currently using in the plugin that were missing from the .uplugin (if that's what you're referring to). Without them, you get a bunch of warnings when compiling and it becomes the responsibility of the installer to activate the missing plugins/modules. Adding them in will check for missing stuff and try to activate them on your behalf. The python API also helps to open up the C++ functions to blueprints for any one that wants to do custom stuff via script.

Regarding the if/else logic, I'm not sure what half's intention going forward with this plugin whether to change main branch to be directly corresponding with v2 and sunset v1 or somehow keep it compatible with both, but until I have something more definitive, I didn't want to yank out any of the legacy code if possible.

[h4lfheart]

I have started on remaking the export process for v3 and have decided on using a localhost api for all data sending so this pattern can definitely be used when adding unreal support to v3. Since this is for v2 I will close it since it will be obselete later this year but will absolutely reimplent it.