Plugins now accepted - What do you need?

[FlyofAvalon]

Full ODBC + SQL support. Ability to query a DB from blueprints.

[Jon Jones]

What does it mean by integration source? Full plugin source code?

No, only the source required for integrating with the engine, so we can work with it ourselves and test it properly. Everything else can remain closed source. We have full respect for code plugin developers wanting to keep their secret sauce secret. We're working on clearer guidelines describing how to structure a project to help make that easier. More on that soon.

I can imagine a provider wants to stop development/updating the plugin if sales are not what they expected. This can happen! Is it an idea to demand a minimum of updates for X engine updates? Say 5 minor version updates(from 4.8 to 4.12 for example). This way the provider knows what he/she is getting in to, and what the exit strategy is. And the buyer knows the at least amount of updates/support it can expect.

And besides the minimum amount of updates or not: how is Epic going to enforce this? What happends if a provider after 6 months decides to stop?

Love the plugins btw, no more manual installing Substance Designer plugin

We don't have firm guidelines on this yet, but this is what our internal thinking has been:

1) Most content works fine with new versions without needing to be updated, but Blueprints and code plugins can be tricky, and should be kept up-to-date if possible.

2) Requiring full backwards compatibility for all versions is a lot to ask for. The vast majority of our users upgrade to the latest engine version, so keeping more than three previous versions up-to-date isn't really necessary. Likewise, you don't need to update your content unless it's actually broken.

3) If we can't verify your content works in the latest version, we specify that in the launcher and don't update the compatibility info until you update the content.

4) Here's the big one: If Marketplace content is simply broken, people that paid for it aren't being helped, and it stays broken for more than 60 days without any updates or progress, we'll remove that content from the Marketplace until it's fixed. We'll exhaust every option we have to contact the seller and work on getting the content fixed, but if it's just not happening, then that content doesn't belong on the Marketplace. People that paid for it get to keep it, but sales are suspended and it's no longer listed on the Marketplace for purchase.

I should note that we have *never* had to do this. If things ever get serious enough to require a response like this, it will be handled privately, professionally, and with a great deal of advance notice and warning to the content creator. The closest we've come to this is when I sent a stern email to an unresponsive seller which was quickly resolved. So far, people have been cool, and I only rarely put on the "Jon Jones has had enough of your shenanigans" hat. But you're smart to wonder about what happens, and I hope this helps explain our thinking. Questions and comments welcome!

[SaviorNT]

Things we need the community to implement, in my experience / needs:

- Voice Attack functionality (I know this is in progress, as I have been in communication with someone looking into it). Basically a "voice to command" infrastructure for the engine. Example: On keyboard, if I press 1, the character will jump. With this, I could say, "Jump", and the character will jump. Voice as an input control.

- Omni-Database: A plugin that will enable the engine to provide a connector to various, well used database engines. SQL, NoSQL, Oracle, to name a few. MySQL is already implemented into the engine. DB transactions should also be able to be encrypted for security reasons.

- Direct Input plugin to allow for DirectInput devices to be used with the engine, for example, a HOTAS. This should also enumerate the devices so that you can use more than 1 device at a time, for example, Pedals, Flight Stick, Throttle

- Another important engine plugin would be a plugin that "re-wrote" how the engine compiles a project... it automatically copies other plugins to the project folder before it is compiled. Why the engine doesn't natively do this, well, I have no idea. An example would be substance. You need to have the substance plugin in both the Engine folder as well as the Project folder. If it's not in the project folder, it will not work when the game is compiled.

Not relating to Epic or the general community at large, but I would like to see Nvidia release their Gameworks stuff as plugins, so rather than having to download the source from github and compile, I can just use a plugin for the feature.

**** Really guys? Why is Comp-ILE filtered? Did I mistype it? Compile compile I guess I did. Oops. My bad.

[TheJamsh]

Question I have is, do Plugins fall under the normal rules for Asset submission. For example, do I need to submit a minimum of five working things to go along with it? Say in my case I submit a Plugin for a hovering movement component, How much additional stuff do I need to provide? At a minimum I'm guessing an example level and asset?

So many ideas... time to work out how to create plugins.

[Jon Jones]

Question I have is, do Plugins fall under the normal rules for Asset submission. For example, do I need to submit a minimum of five working things to go along with it? Say in my case I submit a Plugin for a hovering movement component, How much additional stuff do I need to provide? At a minimum I'm guessing an example level and asset?

So many ideas... time to work out how to create plugins.

That's what's fun -- right now it's a blank slate, and we're figuring it out as we go. Community discussion and feedback for this is going to be everything.

[Moss]

How to you would distribute the source code for a plugin? Via a private GitHub repo or is it up to the developer to handle access to the code base for users that are entitled to the plugin?

[SaviorNT]

As a designer and not a coder, I don't care about the source code. All I want a plugin to do is:

1) Install into the engine or project, depending on the type of plugin. Or install it into the engine, with a checkbox to enable or disable it in the project.

2) Compile the plugin with the project w/o the need to copy folders around.

3) If I need to interact with what the plugin is doing or its feature set, I should be able to do so in Blueprints.

The source code is all good to provide to Epic so that they can analyze it to make sure we're not downloading "weird" stuff that will break machines (ie: No malicious code).

[KoldKam]

I cannot wait to create and submit some plugins.

[amigo]

Personally, I would/will not buy a plugin if it does not come with a source code, this is 2015 not 1995 after all.

And, I don't care how great the plugin might be, even if it had a "Make Art" button...

Having the source code ensures:

- use on all platforms;

- enhance/change the plugin as needed;

- not having to rely on the developer to fix things in a timely fashion;

- in case of a developer going awol, the code is there for future engine versions.

[Syed]

No, only the source required for integrating with the engine, so we can work with it ourselves and test it properly. Everything else can remain closed source. We have full respect for code plugin developers wanting to keep their secret sauce secret. We're working on clearer guidelines describing how to structure a project to help make that easier. More on that soon.

To be honest, source code is very useful to user if author decides not to continue development, while the plugin itself has become too important to discard. Probably Epic can act as sort of 'source code eschrow' whereas had the plugin been discontinued, user can download the plugin from Epic and compile it themselves. Or probably even better, plugin architecture is such that it is always compatible across major version ie 4.7 plugin remain usable under UE 4.9.

I have been bitten with similar cases where buying plugin certainly does the job for the current version. But then later on (months later), when some changes are required and the SDK version has changed, plugins no longer work.. and for many cases, there are no source code for them.

[FrankieV]

Well I don't know whats up with future plans but I would love a plug-in that will integrate Nvidia's GameWorks.

Reasoning is simple. I'm not only interested in making a game that is cross platform compatible but I'm also interested in using Unreal 4 to make and render animated shorts or even down the road a full length feature film.

Also if one could plug-in Substance Painter so one can paint directly inside of UE4 that would be cool as well.

The only thing that would be annoying is if plug-ins are made available at a cost when it should be a core feature.

[ÅsmundSchei]

Well I don't know whats up with future plans but I would love a plug-in that will integrate Nvidia's GameWorks.

I also want a easy installation with no coding or GitHub fuss for NVIDIA`s GameWorks

[Mikand79]

The only thing that would be annoying is if plug-ins are made available at a cost when it should be a core feature.

At least Epic said in one of the twitch streams they will not go that path for their stuff.

[Xces]

A distance based voice chat would be cool

[Martin Bean]

Personally, I would/will not buy a plugin if it does not come with a source code, this is 2015 not 1995 after all.

I agree...... a bit. It has to be a choice for the creator of the plugin. If plugins are required to come with the source code, companies like Allegorithmic will not publish their plugin anymore. I think as a buyer you need to think it over. Is it a plugin created by a hobbiest(which could loose interest over time, get married(that takes a way all your time I can tell!!), etc) or is it created by a company which has commercial interest in keeping the plugin alive?

The source code of the plugin is very nice to have, but going through 10000's line of code to get it working again with UE5/6/7 might not be ideal too.