I’ve been using Ue for a couple years now in my limited time and rely on marketplace assets for functionality that is too time consuming to set up myself. For example, I bought a flying bp which works fine on its own. I also bought a 3d navigation system in hopes of pairing with it (for the ai).
So far I have a really hard time integrating these assets using blueprint interfaces, for example.
Im wondering if I’m actually making more work for myself since I’m following basic tutorials on Bp interfaces and they don’t seem to work right with the pre existing blueprints.
I can’t help but feel I’m shooting myself in the foot by trying to put a square peg through a round hole so to speak.
Anyone have similar experiences?
1 Like
You can definitely save a lot of time using assets, but there’s absolutely no guarantee they will talk to each other, in fact in my experience, usually the opposite 
It doesn’t matter if you use direct references or interfaces, if two systems are incompatible, that’s it.
1 Like
In general plugins are very useful. Quality and support may vary, so most companies tend to keep them to a minimum.
Regarding the interoperation of two plugins:
In the end it’s all just data and ways to transform data. While two plugins might be made very differently and seem mismatched, if you have a clear idea of what you need it should be possible to modify ( preferably only one or the other ) a plugin to process the data from the other plugin in a way that makes sense for it.
Optimally you have a one-way need, that should be fairly straightforward and keep things sane. If both plugins have to be modified, you might start thinking about forking them both propely and maintaining your own repo with them combined into one project…
1 Like
The key word here is “time”.
If you know exactly how a BP or Plugin works, it will save you LOADS, like @ClockworkOcean said. The issue is that everyone has a different workflow, and there are dozens of ways to do the same task. The problem with that is if you know how to do a task in method “A”, “B”, and “F”, but that Content Creator does it in “C” and “D”, well, you have a lot of learning to do if you want to integrate it with the rest of your project.
Personally (until I release my first game, and can afford a team), I KEEP IT SIMPLE (@Karmington alluded to this; sanity is good).
I only use animations, characters, environments, visual effects and meshes.
THAT’S IT.
NO SYSTEMS.
Any system that I want/need that is NOT the DEFAULT, I create on my own.
Reverse engineering code takes longer than creating it.
2 Likes
I always make my own stuff in c++ when the asset type allows it. To me a plugin offering only BP code is a red flag. It’s either not professional or doesn’t scale up since BP isn’t meant to scale or be maintainable. Even if it’s c++ you always risk the person who made it didn’t spend 10.000 hours yet programming and it will still be bad.
It will always feel like this when you combine systems into a bigger system where they are no longer independent. One system does never fit all projects. It’s either overcomplicated or lacking in features and integration when you try to make a “whole”. Blueprint makes it more difficult to combine as well.
Meh…
I find plugins, unless editor mode, are best avoided totally.
If you make a game that relies on a lot of plugins, put it on Steam, and then discover six months down the line, the plugin doesn’t work with the latest engine, that’s a major pain in the butt 
1 Like
Yes it is, because both the plugin will need an update and usually EPIC breaks something again. But this is more of an issue on EPICs side:
When you are halfway a project you want to put on Steam you don’t want to replace the entire engine under it anymore. If there was an LTS version you would stick with the LTS version. LTS is meant to receive fixes not features / breaking changes. The odd thing is, this engine has no LTS.
1 Like