Please note that file comments had no purpose in nearly all cases and just added visual clutter. The two files that had meaningful file comments had their comments moved into the corresponding classes. There are still hundreds of file comments left in other files that will be removed over time.
Also cleaned up some random stuff along the way:
- relative paths to public headers within the same module are no longer necessary (automatically discovered by UBT now)
- header guards are deprecated, use #pragma once instead (all compilers support it now)
- space between multiple template brackets is no longer required (all compilers support >> now)
- NULL to nullptr, OVERRIDE to override
- spelling errors, whitespace, line breaks
[CL 2104067 by Max Preussner in Main branch]
- also fixed auto complete settings not actually editable
- should also fix console history currently not working
#CodeReview: peter.knepley
[CL 2101944 by Max Preussner in Main branch]
Changed anything using "target" to use "support" instead. Made some description text less verbose.
#codereview Max.Preussner
[CL 2088509 by Jamie Dale in Main branch]
TTP# 332489 - TOOLS FEATURE: Editor: Allow user to designate which platforms a project is designed for; warn user when deploying to platforms that will result in a bad time
There is now a "Target Platforms" tab in the project settings which allows you to choose which platforms your project will target. This information is stored inside the .uproject file.
If you try and launch, cook, or package for a project that isn't on the supported list, then you'll see a suppressible warning notifying you that the project may not run as expected. This is also conveyed to you via a warning icon next to platforms which aren't set as a target.
Additionally the target platform icons are shown in the tooltip on the "Open Project" dialog, as well as in the tab area of the level editor.
ReviewedBy Thomas.Sarkanen, Max.Preussner
[CL 2088161 by Jamie Dale in Main branch]
Up until this change, project settings caused a lot of confusion amongst users, because they were changed to the user's local INI files. The local INI files, however, would be ignored when packaging a project, which means that local setting changes would not be applied to a packaged project and cause unexpected behavior. With this change the project settings will always save to the default INI file and will therefore be included in packaged projects. We will see how this works out for everyone, and we may change this behavior to something else if we can come up with a better, more intuitive workflow for project settings.
Upgrade Notes:
- If you have changes for Project Settings in your local INI files, you may want to 'Set as Default' in the Editor and then delete the local INI
- The default INI files (i.e. DefaultEngine.ini) of your project need to be writable. If you use source control, make sure you check out the corresponding files before changing project settings
[CL 2066019 by Max Preussner in Main branch]
