Dear Friends at Epic,
So I am correct in thinking that we cannot submit code plugins right now, right?
Are you waiting to determine the best way to handle what happens when someone with a Content-only project buys a plugin, and can’t compile the source when packaging?
I am ready to post my free plugins any time and am simply waiting to hear from you.
Feel free to use my plugins in any tests you want to do, and let me know if you want to communicate privately on this matter
Victory to You!
Rama
Hi Rama, I am also waiting for this!
But you know, there are presently to many unsolved problems with code plug-ins that need to be solved:
Cheers!
Hi SRombauts!
Great to hear from you as always!
Rama
Code plug-ins will be coming to Marketplace eventually, but we have some details to sort out first.
First of all, we have three high-level goals with plug-ins: To make them widely useful to everyone in the community, both developers who actively work in C++, and developers who solely use pre-compiled binary versions of UE4; to make plug-ins a reliable source of functionality for users who upgrade to new versions as soon as they’re released; and to ensure the full C++ programming workflow is a seamless, first-class option for everyone.
And, there’s a complication: C++ provides fairly weak binary-compatibility rules for DLLs. In particular, if a source code user adds one variable or virtual function to the AActor class, that change breaks all DLL’s using AActor or its subclasses (including plug-ins), requiring users to have C++ source code to all parts of those plug-ins which link to UE4 and to recompile it.
This leads to the following technical questions:
What level of source code needs to be distributed with plug-ins? See Distributing source code with user-created plugins? - Engine Source & GitHub - Unreal Engine Forums for an extensive discussion of the topic. Our general inclination is to require all plug-ins developers to include all C++ source files which link to UE4, but leave plug-in developers free to decide whether or not to distribute source which is independent of UE4.
How do we manage our version release process to ensure plug-in developers can maintain compatibility as new engine versions are released? It would be a bad user experience if one had to wait separately for a new version of every plug-in before developing. This suggest we’d need a more methodical approach to preview build stabilization to enable plug-in developers time to upgrade and ensure compatibility before an official release, but that may slow releases down somewhat.
What platforms are plug-ins required to support? There needs to be some degree of standardization, as it would be troublesome if users built a large base of content around a plug-in, and only later found it to be an insurmountable obstacle to porting.
The goal is to create a great plug-in experience for users, marked by a lack of barriers to upgrading, porting, and using the C++ source code workflow. We welcome any feedback on this topic!
Dear Tim,
Thank you for the very detailed reply!
I wish you luck in sorting through these various issues, let me know how I can help out any time!
Rama
I like that approach - I think it’s the way to go.
Perhaps some sort of build server for plugin developers to use, so that they just submit their plugin code to the build server, which rebuilds it against all current versions each time a new one comes out.
Probably way too hard to set up and manage that, though.
Whatever platforms, they should be easy to figure out which are actually supported, at the least.
Thanks Tim, you guys are doing an amazing job with a tricky situation.
Something you need to take into account is many of the plugin developers are small shops, solo developers or even enthusiasts, to borrow the term from your post on the other thread. Trying to maintain compatibility across multiple platforms and multiple releases quickly becomes cost-prohibitive for many small developers (myself included), especially if you throw mobile and console into the mix.
n00854180t suggestion of Epic supported standard build/test environments could be an answer. I would pay for a rent by the hour or longer period for such a solution so I didn’t have to build and maintain my own test lab.
Yes currently the thinking on an ideal pipeline is that we can automate compilation and some reasonable degree of smoke testing of plugins as part the engine preview release process. Developers would be notified of the results and then would be able to perform final testing, marking the plugin as available with the new version of the engine assuming everything is functional. If issues are reported from the community we’d update the compatibility status of the plugin and notify the developer so that they can address/resubmit/etc. This is still under heavy discussion of course, but this is the direction we’re currently leaning towards.
@Ray - awesome! That sounds like a really good solution.
Seeing as the main thing I can do is provide code plugins, I’m really interested to see how this goes and get something ready for when it’s live.
I personally want code plugins on the marketplace as soon as possible. Obviously we have code plugins that work already, but we have a bit of anxiety about starting out of the gate with code plugin support on the marketplace. One of the reasons is exactly what Ray and jCoder are talking about above. At Epic we try to move really quickly and we get a lot of releases out, so we’re brainstorming how we can help plugin developers keep their products always working on our very latest versions.
Our plugin “API” is the same public interface that any game or even our own editor features use. That’s a really cool thing I think – we build our own features as compartmentalized modules that are basically plugins in themselves, and we consume the same API that everyone else uses. It gives us immense flexibility – we want the engine and tools to be as “lean” as you would like it to be, and keeping everything super-modular are strides toward that.
But that API layer is still a fast moving target, so we’re likely to break code plugins with each release. In the short term, an easier plan may be that we roll along with editor-only code plugins soon, as they are comparatively less burden for developers to keep fresh as their are fewer total platforms to support. This is still a hot topic in the office, and I’d love to see more discussion about this online too. Also check out a related thread I started over a month ago about this.
–Mike
To be perfectly honest I’ve never had a big problem updating a plugin, except my vertex snap editor plugin!
I have more than 10 plugins I have to update each and every build for clients who have requested me to make those plugins for them, and so I already am practicing what it will be like on the marketplace,
and it’s really not a big deal!
Most of the time they compile just fine.
I have plugins ranging from several AI plugins, to RPG dialogue system, to Sockets for communicating between other programs and UE4, a random cloud generator, to vertex snap, to all purpose Victory BP Library,
and I’ve never had hard time getting from one release to the next!
Again the only major trouble I’ve ever had was for my vertex snap plugin 
But even that was only about 2 hours.
So personally I think it should go quite well!
Not sure if other plugin devs have had same experience as me, but thought I’d share
Rama
Admittedly, I am likely to be a mere user of code plugins rather than a developer (but who knows, right?) - but I certainly agree I as a potential buyer/user would also like to see code plugins as soon as it is reasonable.
If you wouldn’t mind correcting any misunderstandings I have, coming from Unity - editor-only code plugins would give us support for tools like ProBuilder, in the marketplace, correct? The poll there is currently showing a strong interest - and is for sure the area of the marketplace I am most interested in.
Are code plugins also responsible for, say, the ability to drop-in support for the Oculus Rift or Razor Hydra/Sixsense Stem? I know Rift support is currently ‘baked in’, but Oculus distributes their Unity plugin directly - and so it’s been in lock step with the SDK so far while I’m still really hoping for UE 4.4.1 with SDK 0.4.1 any day now. (Not a complaint - I know everyone’s doing what they can.)
I’d imagine, though I may be incorrect, full code plugin support would allow Oculus and others (controllers, etc) to provide their own drop-in engine support. That, to me, is worth supporting as soon as possible, though I’d imagine falls outside of “editor-only”.
I guess I’m curious what falls outside of “editor-only code plugins”.
I have to agree with Rama - I think getting support out earlier is better than waiting in order to make things better for plugin devs. I don’t mind having to update code if something significant changed in the engine. I also think that plugin users will probably end up helping plugin authors in those cases, if need be.
Personally I’m not a big tools guy, so for me limiting it to editor-only would limit what I’d be publishing quite a bit. So my personal vote is in favor of getting support for code plugins (not just editor) sooner rather than later, even if the experience isn’t super polished for authors at the moment.
You could even disclaimer it, do it as an experimental thing where devs who are interested opt-in with the understanding that they’re going to have a rougher time of it than if they wait until code plugins are fully supported including whatever build/version management solution is decided on.
As an aside, will all code plugins be required to support all platforms, or are plugins that can’t support certain platforms still okay? I personally would like to mostly target desktop platforms, as that’s where I’m most comfortable working. I’d be willing to try and get support for other platforms too (in all my projects) but I don’t have, e.g., an iPhone or iOS device to test, nor will some of what I want to do jive with HTML5’s security or whatnot (but is perfectly fine on PC).
Hey just posted reply in related thread - Distributing source code with user-created plugins? - C++ - Epic Developer Community Forums
Basically go for lots of plug-in source / licensing / pricing options and Epic can support them as it has time, resources and desire to do so.
Sorry for necro but any news on this? I just saw that the launcher links to the marketplace whenever I click on installed plugins on my 4.8.3 engine version.
Could future compatibility of a compiled plugin be assured if the Unreal classes it uses can be reasonably expected to remain unchanged in future versions of Unreal? For example, if I made a compiled plugin that extended AActor. And AActor did not change between 4.9 and 5.0 would this compiled plugin still work in 5.0?
If so, then I have a proposition that may address the future compatibility of compiled Unreal Engine plugins:
Adapt your development model such that classes available to users through the Unreal Engine Editor, are extensions of change specific implementations. For example In version 4.9 AActor would extend AActor4_9, while if AActor must be changes for 5.0, AActor would extend a new implementation AActor5_0 (probably extending AActor4_9). In this way a Plugin could be future proof if it used AActor4_9 as it’s base class for it’s AActor modifications, presuming all 4.9 functionality is maintained, it should operate in 5.0 just as it did in 4.9.
The alternative is probably having plugins being implemented and run on a virtual machine in the Unreal Engine Editor, which would be a lofty goal.
I mean so long as there is some underlying hook that doesn’t change between versions (if such a thing could exist) you should be able to make future proof DLLs but if there is no such thing, and there is no potential of a virtual machine being implemented for plugins then compiled plugins will always be version restricted and never quite be viable for the market place. Am I right?