Search in

Sort by:

Everything Legal & Licensing

Current Space

Question Status:

All Questions With Answer With Accepted Answer

Quick results

Search help

Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both.
Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.

You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with
each other. Examples

Ensure that your product - Doesn’t contain the Unreal Engine editor or tools or an editor or tools based on the Unreal Engine editor or tools if shipped to the general public (rather than just other engine licensees).

So it's okay to ship dev build which contain a console? Can a console be considered as a "engine tool"?

PPPS: As for why we want this:

Console. We want to use it, and we don't mind if experienced user will use it(if enabled in our options, like in valve games for example)

Blueprint node "Execute console commands" which is hugely useful.

We have more fps in dev build for now, and we didn't figure out why as of yet.

You can release a "Development" build of your game if you'd like. You just can't release a "Development Editor" build (or any "Editor" build, for that matter.)

Shipping a "Development" build isn't something that we would ever do at Epic, mainly for performance and security reasons. If your game is multiplayer, a Development build makes it much more easy for players to cheat than a Shipping build.

If you just need access to the Debug Console in your game, you could release a "Test" configuration build instead. That supports a Debug Console but most console variables will be disabled. You can selectively compile them back in though.

You can release a "Development" build of your game if you'd like. You just can't release a "Development Editor" build (or any "Editor" build, for that matter.)

We are packaging the game, so no editor should be included.(at least it isn't in final packaged folder, it's even called WindowsNoEditor)

Shipping a "Development" build isn't something that we would ever do at Epic, mainly for performance and security reasons. If your game is multiplayer, a Development build makes it much more easy for players to cheat than a Shipping build.

Understandable, we're making single player game, so cheating is not a problem, as for performance, we didn't spot any difference in our game, our project is probably too small for that to be real issue. But I have read about it somewhere in docs...

If you just need access to the Debug Console in your game, you could release a "Test" configuration build instead. That supports a Debug Console but most console variables will be disabled. You can selectively compile them back in though.

If you search the code base for "UE_BUILD_TEST", you can see there are various locations that wrap console variable registration or 'exec commands' with #ifdefs to cause them to be compiled out. So if you wanted to use a Test configuration (with Debug Console), but also include additional console variables or commands, you could find the commands you need in code and make sure they aren't compiled out of UE_BUILD_TEST configurations.

For example, you may want to look at certain source files like ConsoleManager.cpp. There is some code in there that explicitly disables registration of console variables marked with "ECVF_Cheat", but you might want to keep those variables exposed in your game.

I had some doubts about releasing Development builds though because they contain some modules from the Development folder and AFAIK technically we are not allowed to release them. Could you please clarify this for me? Thank you!

When compiling the runtime game in Development, we pull in some extra Development modules like SourceControl, TaskGraph and SlateReflector.

These aren't really needed in your game, but we don't have a quick way for you to exclude these in Development configuration with a single switch.

So to comply with the EULA, currently you'll need to edit some Build.cs files and remove dependencies on these modules before you compile. There may be a few C++ source files that also need to be modified to get things compiling.

To figure out which modules need to be factored out, you can edit UEBuildTarget.cs and change CheckForEULAViolation() to also run in "Development" builds, not just Shipping. It will print out all of the Developer module references next time you rebuild.

Obviously if you are able to ship a "Test" configuration build (instead of "Development") there are fewer modules to factor out.

If there was reasonably high demand for customers being able to ship Development builds, we could add new switches to exclude these modules conditionally, out of the box.