It tried a shipping built in the 4.11.2 Engine. It fails with the simplest repro steps:
This is the most amateur like work ethic. Thanks for the sequencer! Let’s go on to 4.12 then …
I might have same on my laptop, my one related to machine having 2 core processor, it should be fixed in 4.12 since person who find this out made pull request.
The substance plug-in needs to be disabled.
No ranting really, but the 4.11 version apparently did not see enough testing. Something as basic as shipping, if that does not work, then you have to assume that it is only the tip of the iceberg. If you do not find the plug-in problem, then you turn your project upside down, potentially making things worse in order to find the problem. How can a team put trust in UE4 to be the engine for their 1-2 year project, if you constantly have to assume that you are walking through a minefield that could kill your project at any stage? This is what Epic has to realize. This is why people walk away.
You sacrifice reliability for features, no one is going to buy the features. It is just to risky to make the decision for a project that involves serious time. Especially these days with 4 Engines at your disposal and soon, with Source 2, even 5 engines.
You need to have the correct version of the Substance plugin installed for your version of the editor.
If the substance plugin (created by Allegorithmic, and dependent on you to update it) is causing your project to fail on a shipping build, how is that Epic’s fault?
That’s wrong.
As far as I know, every binary engine download through the launcher sets up its independent engine version, including all plug-ins in the engine version’s folders.
This means the plug-in comes packaged with the engine download through the launcher for each version you download and in 4.11.2 it is faulty.
Here is a thread observing the same:
We already made peace with the fact, that you should only jump on board of the latest version iterations for anything bulky and serious, like not 4.11.0 or 4.11.1, basically you can forget those, but only the very latest. In this case 4.11.2. Now even this practice is not bullet proof anymore. 
(there is no ‘desperation’ emoticon)
Well, enough almost-ranting. Small company with lots to do, quality suffers, such is life… You can go away if you do not like it. (or stay like we do and keep nagging and nagging, for the best of Epic btw)
If you had paid thousands of dollars in licensing for the engine, I could see how you’d have expected releases to be bug free.
How much are you paying for the Unreal Engine while developing your game?
Building a large software system is extremely complex. There are always bugs. At least with Unreal Engine, you get the source, so you can debug it!
You do have a choice, of course. You can build your own engine. You can use a pay-for engine like Unity. You can use an open source engine.
But, honestly – it’s not any better in the other places. This is a fact of life; your job is to do the best you can with what you have.
That being said – yeah, it’s frustrating when a tool you depend on gets something wrong. I know the feeling, and sympathize.
It is not about money, but time that you invest. You work every day for over a year or two on a project, you invest some serious time, sit in front of the screen for hours and hours, thinking you have been handed something that puts you on save ground and is working, and then in the end it disintegrates because there are quality bugs that hit you. Say that happens, would it be alright after all advertisement was raising the product into the sky?
Now with Epic you get a good base to work on with the majority of things working reliably. But let’s make sure they stay that way by nagging and complaining as soon as things go downhill. And to be honest, 4.11.2 is not looking uphill.
(btw, I think source code is only useful for large teams with resources to look into it and tweak it reliably. It is pretty useless for small indie teams)
First: Advertising always lies. Doesn’t matter who makes it. Never trust it, always verify it yourself.
Second: Every product I’ve ever used has had failing bugs. Doesn’t matter if it’s pay-for tools like Microsoft Visual Studio, Autodesk 3ds Max, Microsoft Windows, and Adobe Photoshop, or free tools like Linux, Apache, MySQL and GCC.
All these products are complex, and thus have bugs. Living with those bugs, and debugging and working around those bugs, are a necessary price to pay when using those tools.
The good news is that, even if it takes you two days to debug and work around the packaging bug, you’re still ahead compared to if you had to build your own game engine!
I see one situation where this can be extra bad, though: If you don’t have access to the skills needed to debug the engine/tools themselves. That is, if you’re generally a “user” who don’t actually have the ability to dive in and troubleshoot, then each bug becomes a potential product killer. If you’re in that situation, I highly recommend making some friends who have those skills, so you can own your own destiny.
Anyway, if you want someone on the forum to help with the packaging, diving into the build logs and copy/pasting the bits of the log that shows what it is that’s failing, will likely help you get an answer faster.
Good luck on the project!
Thanks for the invaluable advice and life lesson, how could I have been ever so blind in the past 
But look, regarding the topic, there is a line between workaroundable and contained bugs and then core bugs. No problem with workarounds, they are done 100 times each day, to put it a bit exaggarated, that’s fine.
Core bugs however, especially when they hit you after your project got bulky after a year or so (or after beta testing in worst case), require a full retesting and are not to be taken lightly. What if you built on the substance plug-in and say 200 assets use it after 1 year? And that’s even assuming you found the Substane error and are past the stage where you turned your project upside down and potentially induced new bugs yourself.
Core functionality just has to work and has to be properly tested. There is no ‘but’. And a shippping fail straight out of the box is a bad sign.
I mean we just used 4.11.2 on Sunday for a little Katamari clone, so no problem, we are not affected by the bad 4.11.2, but other people will be.
Epic is a nice little company, but it seems, in the business, they are a bit like the flower kids dancing on green meadows getting sloppy everytime they reach a small height. There are the new CryEngine, Lumberyard (and not released Source 2) picking up speed right now. Epic should make sure to not get steam rolled again like when Unity was released. The main argument for Unity is/was easy to use and good to get games done. Main focus is on getting them done, which inherently includes reliability. Getting it done, getting a large project done and released, that’s the core argument for any serious project. With minefield versions like 4.11, Epic has nothing to offer in respect to that. It is essentially a toxic version that can not touched if you set out for a large project.
Always update in a branch first and check for issues. Only merge it back into your main branch if there aren’t any, or if things are an easy fix.
Also, post the here or it likely won’t get fixed: https://answers.unrealengine.com/
@BlueBudgie
As pointed out you may want to post on AnswerHub in the Packaging and Deployment section for community support, or try posting in the forums as well. The Support staff help out in this section when possible as well, but we cannot guarantee support.
4.11.2 for me packages out of the box without when testing with a blank project and scene with a few objects placed and set to Shipping. There would certainly be more outcry from the community if this functionality did not work and we’ve simply not seen any reaction like that.
When packaging fails there could be a multitude of reasons and it’s up to you to use the tools provided in the engine to debug and troubleshoot those issues. If you have any trouble this is where the community can be helpful in pointing you in the right direction, but this requires you to post the full logs from the project, if the logs point to the a UAT or UBT log you’ll need to post that as well, along with any additional information that may be needed. Understandably it can be frustrating and confusing if you’ve not done it before, but really it just takes time, patience, and the knowledge to know what you’re looking for to resolve the.
Some common packaging issues can be caused by the following:
Also try having a look at our Packaging and Deployment Wiki that was created by one of our Support Staff to help. It’s there as a starting point and guide, but is not all inclusive of every error you could see though.
As a good practice once you get a build to work, it’s best to work it into your schedule to do a packaged build every couple of days of work. This way if something does come up you can narrow it down much more quickly than waiting towards the end of a project where you could have multiple issues you need to sift through to resolve the packaging issues.
I hope this helps in some way.
Thanks for the tips, but we are good with all that. We have packaged at least a thousand times for our major game in 4.8.3, can pretty much do it blind folded
As mentioned above, we only stumbled across the when we did a tiny Katamari clone in 4.11.2 on Sunday for fun. That’s not important, and it packages after all with Substance disabled.
Maybe I try later to just delete everything 4.11.2 Engine related and do a re-install through the launcher and see what happens.
Try this, this works for me.
Go to the Engine folder.
Make a folder called Projects and move your project to that folder and try to package your project with Substance plugin enabled , it needs to look like this. 