It was weird that a bunch of #if sections were being grayed out in VS for me, when they shouldn’t have been, so I investigated and found out that the preview Preprocessor Defines set in Project Settings->NMake->Intellisense Preprocessor Definitions are pretty much just all wrong.
For example, WITH_EDITORONLY_DATA is 1 in Development Editor, but 0 in Debug Editor, even though they should both include it, AND, it’s different in the MyGame vs UE4 project ! This also happens to other things like IS_MONOLITHIC being 1 for the Development configurations (surely it’s not, as there’s DLLs everywhere), WITH_SERVER_CODE being 0 most of the time (even though I’m not in the Client configurations, etc)
The promise of UBT was that generated Visual Studio projects are disposable, and that you can regenerate them at any time, which is NOT TRUE, if i have to go in there and manually adjust the Intellisense Preprocessor Definitions after every time i regenerate the projects, just so that the #if blocks appear properly ! It also makes me manually add files because its less effort than regenerating the project, when it should be the other way around.
Please fix this, it’s been like that since 4.0, and we’re at 4.4 now and still no change. Surely it can’t be that hard to match the preprocessor defines set in the project with the ones actually passed in to /D during build.
Wow, thanks for letting us know. It’s actually the first time that we’ve heard of this issue. I’ll definitely make sure we look into it. Btw, IS_MONOLITHIC=1 is correct for “Development” configuration, as that build is actually compiled into a single executable, such as “MyGame.exe” (it does not load DLLs.) However, WITH_EDITORONLY_DATA=1 should be set for “Debug Editor”. I’ll enter a bug into our database for that now, and we’ll get it investigated and fixed for an upcoming release. Thank you.
The bug was backlogged and we weren’t able to get to it yet, and I don’t have an ETA for you though I hope we can fix it soon. This is tracked on our side as UE-4465 for future reference!
Still the same in 4.6 preview atm. I really hope this gets fixed because it’s super annoying (and also the UE4/XGame projects have opposite defines for WITH_EDITORONLY_DATA, like UE4 has Debug_Editor =1 but Development_Editor =0 while XGame has Debug_Editor =0 but Development_Editor =1 which makes no sense). It’s annoying because VS2013 is completely unresponsive for like a couple of minutes after changing them to the correct values as VAX/Intellisense has to rebuild its entire definition cache thing.
The ticket for this fix is still active in our database, and is currently assigned to a developer to be investigated and corrected. When we get this fixed, it will be noted in our patch notes for the Engine.
I stumbled across this post because I had similar issues and found it pretty confusing - as far as VS was concerned, UE_BUILD_SHIPPING was 0 in a shipping build? Took a while to realize what was going on.
Has there been any progress on making the VS project #defines actually match UBT’s? Seems crazy to me.
I checked the status of the ticket we have to track this issue, and it appears that it is still waiting to be investigated. Now that we are starting to wind down from development of version 4.8, I am hoping this will be looked into soon. I can’t make any promises, though. However, I did update the ticket to reflect your interest in this issue.
Hey guess what, WITH_EDITORONLY_DATA is still not in my preprocessor defines in the vcxproj for Debug Editor or Development Editor, either on my game project or the UE4 project. 4.15
I double-checked this in 4.15.1 and our latest internal version of the Engine, and this definition does not seem to be included in the list of definitions for a project. I went ahead and put in a new report about this issue (UE-43424).
I just heard back from one of our engineers about the report I submitted about this. He said that the WITH_EDITORONLY_DATA definition is not supposed to be included with the preprocessor definitions for a project, so this does not appear to actually be a bug.
