Looking for tips on best practices for merging Marketplace Packages that require
&stc=1
into my Team’s existing project. My concerns are Configuration File merging and Package Upgrading. I ran into all sorts of issues in the past with this and want to devise a workflow that doesn’t break the project when adding these types Assets and upgrading them. My goal is to maintain a modular design without directly modifying the packages by creating child assets from those that support inheritance, and cloning assets that don’t support inheritance (ie: UMG Widgets :mad:).
My current Project File Structure looks something like this:
GameLayer is where all the Game Core files and Glue code.
AdoptionLayer is were I store my modified versions of a Subproject Child BP and Clones, essentially matches the original Subproject with the prefix ADOPT.
StagingLayer is work space to add/migrate project assets to the content, then move them into the appropriate directories.
SubprojectA,*B,*C,etc is the Subprojects migrated into the Content Directory.
So the current workflow of getting a Marketplace Project (subproject) into the main project is to
Create Project
Create Folder in Main project Content Directory
Migrate Project to Main project Content Directory
I’m open to any ideas to improve the efficiency and ease of use for this process.
Unfortunately there’s not really a universal ‘do things this way’ for this process, as it largely depends on each individual pack. A lot of packs with the “Create Project” rather than “Add to Project” are only set that way because as soon as you use any input bindings, Epic put it as a Create Project. This means that, by and large, a lot of them can simply be copy/pasted into your new project and set up as additions onto your current set up. Obviously sometimes this requires integration into your controller or character, sometimes it doesn’t.
I try pretty hard to include tutorials for people on how to integrate my products into their projects, and even have gone way out the other side for the Multiplayer Survival Game Template, doing several tutorials on integrating OTHER products into my template… but there are a lot of marketplace products that don’t really do anything to cover the integration process, which is a little frustrating. Sadly, the best you can do is take a look at each product, work out what they need and try and go from there.
Bright side - I think that most new products now cover the integration process as blueprint tutorials and such are part of the submission standards. It’s still far from universally applied though. Where possible, the use of child blueprints and such is definitely a good move, but sometimes, the way packages might be configured, you actually have to edit the base files. In some cases you will also need to hardcode merges yourself, rewriting some bits and pieces to join them all together.
Thank you for your insight. MSGT support is ultra High Quality. I commend you for including the Integration Videos for other’s products. I’m hoping other content providers take heed. The integration you offer is way beyond the scope of what I’m aiming for. I’m thinking the Project migration could be automated, handled in the Launcher with the options: Create Project | Add To Project (as a Subproject).
The key would be in merging the configuration files to existing project. In addition to input mapping (which can be a crapfest of input mapping conflicts between different bp modules) I’ve also found network settings, custom collision channels, and other attributes significantly modified in the configuration files. I proposed a configuration merge in the past, but another option is to use the config file inheritance that existed in UDK. If its still present in UE4, Most likely requires fiddling with C++. I’m actively seeking ways to automate the migration.
Updating Market Packages can be a major pain in the wazoo, especially if you make major changes without inheritance. So I wander how others are approaching this situation.
Definitely. And I wasn’t trying to suggest that it is only ever the input mappings, just that it is most often due to that. However, as you mentioned, anything that has custom collision channels, physical surfaces, etc. will also have stuff in there.
I guess the best method I could suggest of dealing with these situations would be to utilise a diff tool that can highlight to you what differences exist in the files. As the ini are plaintext, for the most part, this should be a very simple diff to check out, so you’d be able to diff against the two files and then, using a little common sense and UE4 knowledge, work out what you should/shouldn’t be incorporating from each pack.
An automated solution would, indeed, be awesome… but I feel the chances of that happening any time soon are pretty low given the speed at which developments surrounding the marketplace are implemented. The priority placed on the marketplace by Epic doesn’t really facilitate the amount of work that would be required to make a system that could reliably update/merge files like that at this point I don’t think… That said… if someone external to Epic was to make it, some pretty easy community recognition up for grabs there haha.
To be honest… even if Epic were to implement a base level “standard configuration” that people were encouraged to use (I say encouraged because I don’t necessarily think fully enforcing something like that would be conducive to the health of the marketplace) it could make a lot of this easier. If people were encouraged to all start on the same slate, then we would likely see a much easier integration process shrugs
One thing is for certain, if the pack creator doesn’t think about extension and integration when they design it, or fails to understand how people will want to use and integrate it into their projects, then no matter what systems Epic put in place, it will always be a pain. From what I’ve seen, a lot of marketplace blueprint and even C++ content isn’t designed with extensibility in mind; users need to actually modify the included content, which makes incorporating updates a nightmare.
I do have one suggestion though for how this situation might be improved, I’ll tag @Smarkoff here in case she’s able to tell us if this might be feasible.
I noticed recently that (according to the editor’s plugin wizard at least), the engine now supports content-only plugins. It seems to me this would allow marketplace packs (at least C++ and Blueprint, though in theory all asset packs too) to be standardized as being submitted in plugin format. All packs would put their core content and/or code into a plugin, and could optionally have an associated project (either for examples, or in the case that the pack really is meant to be used as a project starting point). I see a few benefits to this approach:
There is a clear distinction between core elements of the pack (those in the plugin, meant to be reused or extended), and supporting/example elements (in the associated project).
The equivalent of ‘Add to project’ is automatically covered for the core content of all packs, by simply installing the plugin into a user’s project.
Submissions are more standardized which should make things simpler for the submission/update processes on the marketplace side.
When config file support is implemented for plugins (it has been mentioned a number of times by engine devs), things like input bindings and collision channels, which for now would need to remain within the associated project, could be easily moved over to the core plugin by simply moving over the ini files. That way there should be no need for a dedicated merging tool.
On the surface, the only real obstacle I see to implementing this is to provide support for installing marketplace plugins at the project level as well as/instead of engine level, since if installed to the engine, it wouldn’t be possible to make per-project modifications to assets without affecting other projects.
I was totally unaware of this… and you are right, this could potentially be a big improvement for things overall. However, the one big issue I have with this approach is that a lot of marketplace customers seem quite reluctant to utilize plugins due to the fact that a lot of people simply don’t like working with C++. Obviously, you are saying that we could make plugins that didn’t require code at all, but I would want to see a big push on Epic’s behalf to ensure that the entire user-base is aware that plugins can be content only, as it could potentially be very harmful to non-code plugins if people were unaware. That aside, I don’t see too many other issues either. Will be interesting to see what Stephanie has to say on this…
Yeah I think it’s a good point. I actually hoped there would be a push back when MP plugins were first accepted, to explain to people that code plugins don’t require C++ knowledge, or even a visual studio installation, to use. I feel like a lot of people still aren’t aware that MP code plugins are no less compatible with Blueprint projects than the built in engine plugins.
But yeah, aside from that there are still legitimate concerns people have about having a dependency on third party C++ code, so it would make sense to clarify things as you suggest.
I often get bug reports when it’s just the user doing something wrong;
This reflects the fact people are still not that much comfortable about using plugins.
Also plugins are installed for the whole engine so I don’t think that would work, using the migration button seems good enough.
Thanks for sharing your insight. I agree with you that some content creators don’t think about the modular extension of their packs by Developers or themselves with Supplemental packs and add-ons. This may be in part to the Terms Of Service that doesn’t allow dependencies. It may also be due to level of knowledge in sales and marketing. I’m hoping to change this paradigm.
In regards to Code Plugins, the challenge I’m experiencing with them is distribution in a team environment. With Audio/Visual/Blueprint Marketplace assets the content is added to the Project’s Content Directory which is easily managed under source control (Perforce). However, for Code Plugins from the Launcher, we get only the option to* Install to Engine*. This option is not available to all team members who did not install directly from the marketplace. This is a issue with paid code plugins.
My current plan is to use only Free code plugins and issue email notifications with product links for Team members to retrieve them from Marketplace themselves and install. I can forsee this is going to be pain to manage and its not under source control. If someone can share how they are dealing both Free/Paid Code Plugins in a Team Environment + Source Control.
You are definitely correct that this is in part an issue of limitations in the marketplace system - from what I understand, current restrictions on dependencies are more down to Epic not having processes in place to support it, rather than them wanting to prevent it.
When I mentioned extensibility though, I was actually referring more to extension just in the sense of users being able to easily add or customize functionality provided by the pack. Essentially this comes down to the creator knowing how best to structure class hierarchies, and to expose events, overridable functions and blueprintable base classes. If designed well, the user should be able to integrate the pack into their project and customize to their needs, without having to touch a single piece of code or blueprint in the pack itself. That way, incorporating updates to the pack is far less of a pain, as there is nothing to merge and at most the user should just need to fix up a few of their own blueprints that were affected by changes.
I agree being restricted to installing plugins at engine level is a pain, and as I said would need to be relaxed for my above suggestion to work. It is possible though to just copy the installed plugin from Engine/Plugins/Marketplace into Project/Plugins, so you can keep it under source control. As far as the licensing goes, my understanding is that the marketplace license allow the pack to be shared within a team (see here). However, there is still some confusion about this when it comes to code plugins, so please don’t take my word for it.
I just had to add my “Two Cents” to this discussion. I’ve been Playing around with UE4 for a little while. So, I believe I’m above beginner and somewhere around intermediate. I have made a few basic games and am building on them. Learning as I go. Sometimes I’ll go through the marketplace and find an asset that looks like something I would like to implement. In the description the author will say “easy to use” or 'just add to your game" or “Tutorials provided”. I have purchased these and then later found they were almost impossible to use in my situation without starting over. Sometimes the blueprints are too confusing for someone at my level. I’ll go back to them when I have free time and try to figure them out (a good way to learn).
I may be wrong, but, it looks to me like a lot of the people buying from the marketplace are: Beginners needing a starting place, People who don’t have the resources to create all of their assets, or Someone seeing something cool they would like to have.
Some authors need to realize that not all of us are professionals. What seems to be obvious or easy to them might not be for us. I took programming many… many years ago in college and one thing I do remember is “documentation”. Without it sometimes even the author might not remember why he did something. I can’t count the number of times I’ve read threads in the forum where people were having problems only to discover a few pages later there was “by the way did you check off this obscure option somewhere”.
Maybe there should be in the description something like Beginner, intermediate, Advanced or something like that.
This is all a pretty valid point, however the issue with things like the beginner/intermediate/advanced - that really comes down to relative skill of the person labelling it sadly. Likewise, the ‘easy to use/integrate’ claim does also. What I would like to see more of is developers doing tutorials on how to integrate their content into a project, ideally something a little more complicated than one of the base projects shipped with Unreal. I do this myself, and it’s not a lot of work, particularly if the package -is- easy to integrate as claimed. Unfortunately there are always going to be issues though, as some programming methodologies are going to clash and someone who has made a project in a certain way is going to always have to do a lot of work to accommodate a product made in another certain way, if that makes sense.
Out of curiosity, did you contact the authors of these packages when you had issues with adding these packs to your project? And if you did, what sort of responses did you get.
&stc=1