Development Server compilation and Debuging ...

Well I’m in the process of setting up connection between the client and server and started working with the source code.
Working with 4.1 zipped version not forked git. Got the additional zips in as well, all compiles fine, no issues there.
I have this working and tested in editor mode no issues there. Now tho I’ve setup the Cooked dir’s and then compiled
Development Server, again no issues there until it actually gets to loading the server up (This is in DEBUG Mode)
as one of the ways I learn a system is to step thru it in debug mode…

In International.cpp, Line 183:



        DataDirectory = FPaths::EngineContentDir() / TEXT("Localization");
	if( !FPaths::FileExists(DataDirectory / TEXT("icudt51l.dat")) )
	{
		DataDirectory = FString(FPlatformProcess::BaseDir()) / FPaths::EngineContentDir() / TEXT("Localization");
	}


Is failing as the directory it ends up with is incorrect on how its getting the ( FPaths::EngineContentDir() )
It is close, it has gone Up dir …/…/ correctly, but is missing the names where the (engine/) dir is located
which is (Unreal4/UnrealEngine-4.1), but during debug, this part is not in the path…

Ends up: C:\Development\EWProjects(game)…\engine (etc)
Where as it should be: C:\Development\EWProjects\Unreal4\UnrealEngine-4.1…\engine (etc)
notice the missing (game) in the correct dir…

I have the two sitting side by side,
(root drive)\game
(root drive)\Unreal4\UnrealEngine-4.1

This causes it assert not suprisingly.

So the big question:
Is compilation an issue for dedicated server versions still?
I have (i think) got my (game)server.target.cs build file correct.
I am using a code base customized from the original shootergame for testing and learning…

two additional notes on this…
The cooked dir is the following:
(root dev dir)(game)\Saved\Sandboxes\Cooked-WindowsNoEditor
(root dev dir)(game)\Saved\Sandboxes\Cooked-WindowsServer

Interestingly, the cooking only creates the content in the \Cooked-WindowsNoEditor
So I copied that over the auto created \Cooked-WindowsServer

I also noticed that the \engine\Content\Localization was not in the client dir so I copied that over from the source dir

This resolved the issue with finding: icudt51l.dat which started this post as that was where it failed.
Instead I now get a :
unrealengine-4.1\engine\source\runtime\core\public emplates\SharedPointer.h(195): Assertion failed: InRawPtrProxy.Object != NULL
from here:

Here’s a tutorial for dedicated servers:

The problems you describe can be solved by moving the server binary to the binaries directory of the cooked game.

That would be true for just running the Server, I am discussing running it in debug mode local debugger
That cannot be done that way unless I connect to the instance after it starts up. Stepping thru the startup is
very important during intial design with an unfamilair code base. Try running debug mode and you will see what I mean :slight_smile:
Its configured to start in the project/intermediate dir.
I have played around with changing the start location to the new directory, but that doesn’t work and
I have already been reading all those and what is found in the answers/forums.

I have read up also on using the UnRealFrontend but have been unable to successfully Cook the
server version as talked about in one of the answers posts: https://answers.unrealengine.com/questions/27802/packaging-and-creating-a-dedicated-server.html

So yeah, I have been reading all the posts…

I see, but you can still move the exe to the right place, open the project properties in Visual Studio, go to “Debugging”, set the “Command” field to “C:\path o\your\server.exe” and “Working Directory” to the same directory and start debugging.

Yep, and that isn’t the problem. I get it to load and use the Cooked content I created. I get it started in Debug mode
THEN it asserts due to localization issues… That is the issue, not the location of the Exe file.

Weird, I just tested it a second time in debug mode and it doesn’t assert for me.
I know that assert occurs when the exe is not in the right location or the working directory isn’t set correctly, that’s all I can say.
Also, I start the server without any uproject file, just with -debug.

Okay… so if ya got it working lets see what I did different…
I started with the Original ShooterGame Project, was 4.0, updated to 4.1 and redid all my current files to the changes
in the sample project for 4.1 as all my files are renamed and modified… It runs fine in editor.

I then Uninstalled the Original launcher code app and setup just the 4.1 source files from zip and recompiled the engine.
I then switched (using the switcher application) in engine binaries dir to 4.1

I removed the Launcher app as it was giving me conflicts with using both and so this was easiest way to go for the moment.

I then rebuilt my vc files from the updated engine source by right click project->generate…

I then built the Development Editor… Runs fine, allows me to run standalone or in editor window.

I then selected Development Server as the configuration and made sure my project was set to that and set to x64
I only build the project not the whole engine files as they should not need to be rebuilt (so build project not solution).

I then load the project and cook the contents.
When I then click on local windows debugger with no changes it then fails :slight_smile:

I suspect you have done this differently :slight_smile:

Also I just tried this again with a clean setup (removed all built binaries for game)
I did the cooking, it creates the following dir:
(projectdir)\saved\sandboxes\Cooked-WindowsNoEditor

When I then run debug with JUST -debug removing the “$(SolutionDir)$(SolutionName).uproject” from the front part of line
I still get the missing Localisaztion file path assert…
Localization dir IS NOT in the Cooked-WindowsNoEditor dir

I can run it in Debug mode for Developer Editor no problem and as long as I don’t run it standalone I can debug it then.

I also tried the DebugGame Server Configuration. Same result.
I am also going to try this as DebugGame Client next just to test it.

the main thing to know here is I am using the default setup for debugging that utilizes the sandbox dir
by just cooking the content not cooking for release so it is suppose to use the SandBox dir, which when doing the
editor, it does use it. If I don’t create the Cooked contents, it properly complains that they haven’t been created.

(edit)
Just tested the DebugGame Client… This one fails as does server with no localization found …:frowning:
And for good measure I’m going back to the base original shootergame and testing that one the same way.

well, at least I know it wasn’t me :slight_smile:
Just took the basic original ShooterGame 4.1, compiled it (Development Editor)
Ran editor, tested in editor window…
Cooked the Files (not packaged), then compiled Development Server x64 and got the same assert
DataDirectory L"C:/Users/mythic/Documents/Unreal Projects/Shooter Game 4.1/Binaries/Win64/…/…/…/Engine/Content/Localization"
Is not there :slight_smile:

(edit)
Reminder… The Sandbox Dir is the one being used, not a packaged dir
It is NOT copying the Localization dir from the Source Engine, (UnZipped source dir has it), dir to the cooked dir

Another thing I’ve noticed in the ShooterGame is the Error:
LogPackageName:Error: DoesPackageExist: DoesPackageExist FAILED: ‘/game’ is not a standard unreal filename or a long path name

Which has carried over to my verison and I cannot find Where is setting that and causing the error sigh
The best I can figure from log is here…
LogInit: Build Configuration: Development
LogInit: Branch Name: UE4
LogInit: Command line: /game

I’ll figure this out yet…
For further testing I’ve created the simple FPP c++ project with sample content.
Compiled Development Editor, Ran Editor, tested in Viewport, Cooked sandbox, Compiled Development Client, Ran Local Debuger…

Bam: Localization Error lol
C:\Development\Unreal4\UnrealEngine-4.1\Engine\Source\Runtime\Core\Private\Internationalization\Internationalization.cpp(188): Assertion failed: FPaths::FileExists(DataDirectory / TEXT(“icudt51l.dat”))

As the Localization Dir has again NOT been created in the Sandbxo…
This is with absolutely No Changes to defaults

Interestingly:
LogInit: Compiled (64-bit): May 7 2014 10:56:37
LogInit: Build Configuration: Development
LogInit: Branch Name: UE4
LogInit: Command line:
LogInit: Base directory: C:/Development/Unreal4/UnrealEngine-4.1/Engine/Binaries/Win64/

The base creation does not add the /game to command line, and that command line is nowhere
that I can find withing the project or files… I’ve done a in-depth serach of all files and manually
checked every setting in the project.

(I should always use spell check lol)

Heres another test of that same Project with the Exe moved to the sandbox dir…

So it is correctly using the sandbox dir it is in…
Sadly it has Locked the Starting dir to the binaries dir even tho this was started from a copy in the sandbox dir.

hmm, I hate any errors but this is unusual…
I have finally found where it is setting it but not how to change it.

In SSessionLauncherPreviewPage.cpp (Engine Source) we have the following:

This is part of the // launch section
But in the Editor I am unable to locate that Menu item anywhere in the editor settings so far… been looking hard.

(edit)
Argh… Its a default setting somewhere, once I started a Full Packaging of the TestFPP the error returned.
I suspect I have run the Launcher app seperate from the editor to get at it.

Alrite… My head hurts sigh
I have looked and still havent found where it is setting “/game” (Notice lowercase) for any of the projects.
I have loaded up the Game Launcher app and gone thru it… The Launch section has the Command Line: <empty>

Yet it is setting a default: “/game” in it when it cooks. Something is wrong with the settings and thankfully
it aint me…

Boy they hid that real good… I even searched thru the registry and still havent found it lol
its got to be something simple in the setup where it builds from pieces as the search features of Express
and all files cant find :slight_smile:

still havent found that dogone “/game” setting, at least the correct one…
There are several points where it uses “/game”, but not sure which one it is…

UnrealVersionSelector.cpp :

(this probably isn’t it as its accessing the registry)
DesktopPlatformWindows.cpp :

But I was able to Cook for “windows” and run the DebugGame Client and then attach after starting it in the correct dir.
This was done using the Launcher app to do the advanced build without deploying it.

Running it from VC it keeps setting the default startup wrong and trying to run from intermediate…..(etc) instead of using
the Values I put in. This means the NMake values are holding the local project settings and overriding the project properties.
I so love when you have extremely complex build configurations that interfere with what would be considered standard setups sigh

So the VC configuration setup by the unreal build system is the cause of the Localization issue, not anything I’ve done.
This interferes with doing a full debug as you have to start it manually then attach, makes it hard to catch startup issues.

well, I still am havin issues starting the server/client in debug mode, but I am able to compile/launch the dedicated
server basically.
It runs in headless mode and listens on the Lan IP mode allowing attempts to connect by local lan ip (not by 127.0.0.1)
but I still really prefer to start it in debug mode. Not happy at all…

Also the Launcher gives me the complaint when doing it just from the Launcher app or from within the editor…
Settings are for Windows (not window server / windows client) as both those fails to build:

Those 3 warnings will have to be cleared up. More to learn I guess.
Altho the the one about deploy makes me suspicous setting it to Windows maybe the cause?

Even more annoying is that if I redo the cooking it deletes out the Server exe I copied in :frowning:

Current state of where I am at…

The last few lines are why I prefer Debug startup… mind you this is very basic and just starting to get it configured properly…
Haven’t done any real work yet on the socket/udp connection/login, just getting it loading up and running from the base skeleton
of the original shootergame sample.

Alright, here’s what I did:

  • Package (not cook) ShooterGame for Windows to a directory i named ShooterPackaged
  • Compile ShooterGame 4.1 with Debug Server on Win64
  • Move ShooterGameServer-Win64-Debug.exe and the pdb to ShooterPackaged\WindowsNoEditor\ShooterGame\Binaries\Win64 (I cannot stress this step enough)
  • Open ShooterGame properties, go to “Debugging”
  • Set “Command” to C:.…\ShooterPackaged\WindowsNoEditor\ShooterGame\Binaries\Win64\ShooterGameServer-Win64-Debug.exe
  • Set “Command Arguments” to “-debug”
  • Set “Working Directory” to C:.…\ShooterPackaged\WindowsNoEditor\ShooterGame\Binaries\Win64
  • Start debugging
  • Get no asserts

It’s really as simple as that, there’s no need to change anything.

Thats great and defeats the purpose of the designed system with sandboxed cooking…

Plus you left out some information:

Are you using the Binary Launcher 4.1(updated) version or the Source self-compiled version

If the Source compiled, is it from the Zipped source or a clone, if a clone what verison? (Head / 4.1)

Which points to an issue possibly with one of two things:

Cooked/Sandbox has issues with server/client only builds
OR
Source compiled 4.1 is having issues that have been fixed in Head version (latest)

Reason I say this as I am using the Source Self-Compiled Zipped 4.1 version

which also in reference to the above, I also did attempt moving and changing those settings only to have the NMake
settings from the build system changing my settings for Working Dir and Exe location to the intermediate dir structure
thus making it impossible to set those to the correct dir… so even if I did do a “Packaged” it still would fail as the
Executeable is not found… So yeah, it looks like the current Zipped Source is having a problem.
Thinking about it, I know they don’t have Server Compile ability setup yet with binary launcher, so which version
(Clone) are you using?