Plugin Versions and Plugin Dependencies

These are two related concepts in regards to code plugins that would make the Fab simpler and much more powerful to code plugin authors like myself.

Plugin Versions:

The first, and simpler one, is we should be able to have multiple tiers to a plugin. If I want to provide a small handful of versions, say lite and pro, it’d be nice to be able to do that as a single product rather than having multiple listings on the Fab with separate ratings and such. This would be a straightforward thing to support something akin to this hypothetical setup:

  • Lite Version: 9.99 (You could still support the “Pro Price” version of it)
  • Advanced Version: 49.99 (Again still could support the “Pro Price” version of it)
  • Ultimate Version: 99.99 (Again you could still keep the “Pro Price” version of it)

Then if someone say byes the Lite version and wants to upgrade, they’d only pay the price difference. This helps simply listings on the Fab with regards to multiple versions of a single plugin, so search results get decluttered from duplicates of the same thing, and it also is better for the consumer as they have the option to buy in cheaper to start and not waste that money if they then want the higher tier later. This would also allow solving the issue of people installing both Lite and Ultimate at the same time as the system can just install/update to the highest owned version.

Plugin Dependencies:

The second part of this, is we should be able to support modular plugins, even if it’s only within plugins we own. I know the Fab, and the marketplace before that, hasn’t allowed plugin dependencies and I understand the fun involved in compiling a plugin that has multiple others dependent on it. With that said though, if I want to say allow another plugin to depend on the RMC, I shouldn’t need to embed the RMC which then just makes it more confusing for me and the buyer if they want to use the RMC as well, but it’s embedded in this plugin.

Even if we cannot depend on other author’s plugins, we should at least be able to depend on our own. Then when we submit an update, it’s on us to submit compatible versions for all the plugins, or if no changes are required I would think automating recompiling to validate the changed plugins is easy enough to automate.

The buying process would simple enough as you’d just have to force the user to by the required plugins together or already own them before allowing the purchase, and the same goes with installation/updates.

Conclusion

These two improvements to code plugins would open up a lot of potential for making modular ecosystems of plugins while not overcomplicating the user experience or the developer experience. It also really shouldn’t add more work to Epic as the first is basically the same work to compile the plugins, just all listed under one product. The second is easy enough to automate the whole compilation process that it really shouldn’t add work either.

I’m aware parts of this have been asked before, some by myself dating back years on the original marketplace. Hopefully something can be done, as this is one of the biggest limitations for code plugins.

https://forums.unrealengine.com/t/feedback-on-plugin-dependency-rule-in-fab-marketplace/2173191

https://forums.unrealengine.com/t/request-plugin-dependencies/2170058

The separate files for tiers would make a lot of sense, it should work with other asset types as well. That would actually make the pro license make more sense.