Preamble: up until now, my plugin has been distributed as compiled dlls. However, Epic specifically wants everything that contains a call to the engine to be released in source code for the marketplace. Some of the code contains some proprietary stuff that isn’t mine that I cannot release, so I’m going to have to split that part off into a static .lib (or dll, I guess) that can be linked in at compile time on other systems.
The problem is that basically all the code was ported to use UE base types (FVector, TArray, etc) everywhere and was deeply integrated. It would suck having to switch everything back to use other types and do on the fly conversions from pretty much equal types (there’s only so many ways you can store a 3D vector, for example) when passing data to the UE engine-using code, so my question is: how easy/impossible would it be to keep using the UE Core structs and classes in a static .lib?
Note: I am not asking how to include a static library, I’m asking if I can specifically keep the code mostly as is while having it in a .lib, somehow, and how… or if I’m going to have to spend forever re-working it all back.
Yeah, it was a pretty nasty surprise for me too. I don’t mind so much for the interface code and most of my incidental functionality, but my core functionality has some code that isn’t mine and the owner doesn’t want distributed openly, so…
Basically, the final word seems to be that all users need to be able to use it, and people that built their own engine from GitHub can’t use DLLs built for the Launcher binary versions, so they need something that’ll compile.
Some stuff can be in a static library (or dll, but this wouldn’t really solve my problem since C++ DLLs are super-picky with the UE4 DLLs they’d try to access for the datatypes, which is the reason the ones built for the binary versions don’t work with the GitHub versions in the first place), which is why I’m currently scratching my head and praying that I can just do a .lib build against core without having to rewrite basically all my core functionality not to use UE base types.
" However, Epic specifically wants everything that contains a call to the engine to be released in source code for the marketplace. "
As I have no desire to release the source code for my C++ plugin. I also wonder, if Epic, realizes how at least I would like to have my product distributed, which is nothing more than just exactly like a Textures/Materials product. I.e. put it in the value, then added to the project, copied over, no fuss no muss, the *.plugin can be preset to be enabled, etc. I really don’t want my plugin (the blueprints with the product are a totally different animal) to be in the engine tree at all.
I suppose one, could isolate all the calls, into the engine, into it’s own *.cpp and *.h, to where that’s the only thing that existed in that source,and distribute it. I would personally hate to do that, as it just injects overhead for no reason.
I don’t wish to have my code in the Engine subtree in any fashion, whether it’s object or source. I like very clean deliniations between mine and theirs.
There is no way to determine if the code is being stolen, once the source is released. My blueprints, I have no issue with being as they are, they are just logic, but the “heavy lifting” occurs in the plugin. And that I do wish to protect.
I just have a feeling that Epic, is overthinking, and over doing this for plugins. I mean let’s just treat, the plugin, as nothing more than a material library and be done with it.
As far as something that will compile, I already have a “extensions” cpp and h, to provide something that will compile, heck just provide the rest as object, so it can be linked.
I have really wanted to be able to be listed in the marketplace, now I have no clue as to what is going on.
You can have static libs as part of your plugin. However, you need to provide the lib for every build configuration for every platform you support because a user can build any of those.
The problem is that basically all the code was ported to use UE base types (FVector, TArray, etc) everywhere and was deeply integrated.
This is problematic due to licensees/users of the engine can make changes to the those types and then you will not be compatible with those changes unless you provide source that they can build against. I am not saying you are required to provide all source, as that is definitely not the goal. The goal is to make sure the user of the engine that is using your plugin can do so without having to get custom support from you if they need to build their project after making engine changes.