I have an issue with nDisplay when running a packaged game in Shipping build configuration. The game launches but nDisplay does seems to be enabled : I have no synchronization between nodes and the viewport show the default camera, not my nDisplay configuration.
However this works when using a packaged game done in Development build configuration.
Does anyone know what could make nDisplay not work in Shipping but work in Development build ?
Or how could I debug this further ? Without logs in Shipping build I don’t really know where to look.
From what I have gathered, the startup isn’t loading the packaged uasset data from the project.
I think Switchboard will tell you, if you are using it to launch the project, gives a yellow warning message that it can’t find the .uasset data.
I find this strange because I have used a third party program to view the packaged .pak and .ucas files and I can find my .ndisplay config within the pack.
I have done a TON of very exhaustive searching online, it sounds like the ndisplay config doesn’t even need to exist within the project itself unless you are wanting to have a blueprint that acts directly against it or if you have C++ code that is wanting to modify that specific ndisplay config during runtime.
I would imagine, if you pass the .ndisplay file to load from the command line (with or without Switchboard), Unreal loads a ndisplay config during startup and places that into the level based on the uasset or ndisplay file you told the command line to point to. But, if you do this, it still seems Switchboard complains about missing .uasset loading, which just seems odd.
I am currently playing around with hand editing the assetpath within the .ndisplay file to really determine what this option does. Along this, I am also going to try and search the engine code for ndisplay to see if I can get a handle on what is happening here.
The same as you, I am just not having any luck with ndisplay working for a packaged build. If I load the Unreal Editor up on multiple machines and use the .uproject file, I can seem to get it to run that way, but this is not ideal and can lead our specific use case to be difficult to utilize.
I have, at the moment, just continued working the problem via launching the project via Switchboard and running from the uproject at my two development stations. I will tackle the problem later for why a shipped build just won’t work.
I am currently running into an issue that when I start my project, now, is the UnrealEditor will come up, I see both PCs execute and bring up an instance, I begin to see textures load, then the secondary node will just close.
There is no crash dump produced so this isn’t a crashing problem. The logs really don’t give me any indication that something happened, but it does give me the following error:
The game module could not be found. Please make sure it is compiled.
This error makes no sense to me considering it was just working yesterday. I have tried deleting everything other than Source, Config, and the uproject, regenerating the VS solution files, then building in VS, then lastly starting back up in Switchboard and still the same problem.
My shipping build launches without any issues, however, the viewport uses a free camera and not the nDisplay viewport. Any other build uses nDisplay viewport.
I am at a point where I want to test this with a packaged project (shipping) and I am having the same thing.
Switchboard will launch with nDisplay on all the nodes, but it doesn’t connect to each node to synchronize, and each node starts up as the default instead of the nDisplay it was sent on the command line to start as.
I am trying to get log files to be generated when running the packaged build to see what the issues are.
If I package a development build and start it up with Switchboard (with SwitchboardListener running on all nodes), the nodes will start up and sync up.
If I use the same package development build and start it up via command line using what Switchboard would have sent, each node stays dark, waiting on the other nodes to connect. When I start them up, they will connect and start up, but I can tell the mouse movement isn’t syncing across them (starting via Switchboard, move mouse, all nodes move, start via command line individually, move mouse, only the node’s screens will move).
I am going to perform some more testing to see what the heck is going on.
Found out what my issue was, the command line I was starting with, both contained Node_0 (basically starting both up as the primary node).
Now, I just need to get a Shipping build to compile and work.
Edit:
I am still at a loss on why everything works except from a shipping packaged build of the project. It’s just not starting nDisplay at all, based on the command line I send it.
I am trying to run the debugger through executing this on the command line to see the execution path, but it’s being difficult at the moment.
That is exactly what I have tired, along with taking the command line that Switchboard sends and starting each node with that command line for the specific node. nDisplay just plain fails to load.
I am attempting to perform debugging to actually follow the code execution path to see where the deviation is at, but, unfortunately, every time I package a build, doesn’t matter if DebugGame, Development, or Shipping, I can’t step into the Unreal engine at all. I can only step into my own game logic with my own GameInstance.h/.cpp class as the earliest.
I can see the initial execution from C++, starting in exe_winmain.cpp → exe_common.inl → LaunchWindows.cpp:WinMain(), but, after that WinMain() call, I lose the loaded symbols and I can’t step into LaunchWindowsStartup(). I need to step deep into the engine to follow what modules are loaded to see if DisplayCluster gets loaded when this program is packaged.
I was hoping to recompile this project as Modular (instead of Monolithic), but every time I do this, the compiler complains about UnrealGame-Engine.lib is missing for linking. That is a confusing error as the compiler should be building that library while I compile this to be utilized for linking. And I am not even certain if I compile this as Modular, attempting to run the game will load up all the dlls possible so I can load up symbols to allow for me to step into the Unreal Engine calls.
I was unsuccessful in getting any type of meaningful information out of attempting to debug a packaged build. I attempted DebugGame, Development, and Shipping packaged builds and they all look the same when starting. The issue is that I can’t get past the LaunchWindows.cpp:WinMain() due to what code is being executed and symbols are loaded in the debugger.
So, I am going down a different path. Obviously, when packaging for Shipping, optimization is turned on. There is an option that I am using in MyGame.Build.cs that is OptimizeCode. I am setting that to CodeOptimization.InShippingBuildsOnly to ensure optimization is turned off for Development and DebugGame builds and testing what the app does when starting from the command line as nDisplay.
My initial thoughts are that optimization might be causing nDisplay to fail but I need to test some more.
This is what I have found out. Optimization is not the issue, as I have built a Development packaged build with optimization turned on and executing nDisplay for the project correctly syncs up and runs with other nodes.
When I compile a Shipping packaged build, nDisplay just flat out doesn’t engage. It almost feels like the nDisplay monitor resolution and viewport gets setup, but the DisplayCluster module doesn’t start up, which should begin the syncing between nodes dependent on the .ndisplay file loaded from the command line.
I am at a point that basically thinks this is an engine bug. Since I can optimize a Development build, that is the path we are going to take is to compile our UE projects for development. I am going to place this as a bug into the Unreal Engine Issue tracker website. In a future version of Unreal, when this is resolved, we will upgrade to that version of UE.