Hi curtrock,
could you probably write your question into the “normal” writing window and not into the titel? 
The titel is a little bit distracting when you look through answerhub.
Edit: Thank’s for editing your post 
why does the editor run in 64 bit, but when i “launch” it only gives the option of WindowsNoEditor (32bit)? Would i get better performance if i could launch in 64bit?
Actually, I would like to know this as well… why isn’t there a “shipping” in 64bit? And yes, the title could be better.
The editor requires a lot more memory than standalone games do, but not everyone has a 64-bit version of Windows.We make the assumption that you’ll want to target as many people has possible with your finished game, and that most games can run in 2gb of memory. So by default we use 32-bit executables.
You can absolutely build a 64-bit-only game if you need to; grab the source from GitHub and use it to build your game for the Win64 platform. It’s likely that the 32-bit version will still be faster if you can fit in memory though: most general purpose code won’t be any faster using 64-bit registers, and the larger pointer sizes will just result in more cache misses.
Yup that is what I did, built 64 bit version from the source at Github that is I am mostly after the extra memory. Thanks for the answer though
Thank you Ben. Appreciate the answer.
I like the answer as it confronts the fact that larger pointer sizes won’t help the program in any way. So for that reason alone, I’m content in using 32-bit version for the moment.
But still … I’ve been using a compiled version from GitHub since version 4.0 and I still can’t get the editor to do a shipping version in Win64. I’m running the “Developement Editor” in Win64 which creates new C++ projects as “Developement Editor” in Win64 in VS Express 2013. “Select Unreal Engine Version” is always pointing to my current UnrealEngine code. But my logs show that CommandUtils is always invoked as “(MyPath)\Engine\Binaries\DotNET\UnrealBuildTool.exe MyProject Win32 Shipping …” What command sends those parameters to CommandUtils and how can I override them ?
Are you trying to package from the editor? If you’re running with an editor that you’ve built from GitHub, you should be able to select File > Package Project > Windows > Win64.
And then it goes into directory selection and start the compilation process.
This is the current 4.2.0 branch.
I do have the “official” 4.1.1 installed on my machine. Maybe they share config files and overrides my build somehow. But this is 4.2.0.
I do apologize - I was looking at our master branch. It’s changed!
Unfortunately there’s no way of switching from the editor UI in the 4.2 build. If you want to change it manually,you can go to FMainFrameActionCallbacks::PackageProject() in Engine\Source\Editor\MainFrame\Private\Frame\MainFrameActions.cpp, and change this bit of code:
if (PlatformName == "WindowsNoEditor")
{
if (PackagingSettings->BuildConfiguration == PPBC_Shipping)
{
OptionalParams += TEXT(" -targetplatform=Win32");
}
else
{
OptionalParams += TEXT(" -targetplatform=Win64");
}
}
If you get rid of the check for the shipping configuration, it should work.
No need to apologize. I may be a seasoned C++ programmer but I’m a real dunce when it comes to environments and IDEs - How dare they mess up with my code!!!
May I be so bold as to ask you what would be a good practice for someone who wants the latest build without risking to ask too many silly questions - the master or the upcoming branch (in this case: 4.2) ? I do think that “official” updates are much too far apart and a few fixes (like the public revealing of part of the TextRender API in C++, for instance) should have been available in the 4.1 branch (which is why I went to 4.2 immediately). As important updates get most of the team’s attention, I feel like some simple fixes are only considered as part of a “whole” that is pushed in later, stable branches.
My 2 cents.
Keep up the good work.
It’s a bit tricky with so many builds floating around, I know.
Internally at Epic our artists work in the master branch, and QA do a quick test pass to make sure that a build is stable before pushing it out to the team. We find that’s a good balance between latency and stability, though we’re often firefighting issues that spring up. I periodically tag and upload dependency zips for one of these promoted builds on GitHub.
Personally, I’d stick with one of the release branches unless you’re reliant on some bleeding-edge feature. There are often several hundred fixes that go into those builds while any features are frozen.
I’m using Unreal Engine 4.4 (non-GitHub version). Packaging to 64 Bit is still locked. I mean, we have 2014, computers have 8-16 GB of RAM. WTF?! Display a warning before packaging if you want and let it go.
Including static libraries for the 64-bit build would be a big increase to the download size of the binary release, and would reduce the number of people that you can target with your shipping game.
We can consider doing it though. Are you actually running out of memory with the 32-bit game?