What is the intended way for a release build of a game to start?

  • Game launchers don’t autoload levels

  • Batch files are ugly, no games released by any other engine require you to run them from a batch file

  • Console commands are also ugly, I’ve never in my life played a game and had it load up a black screen on which I have to enter a console command to load the game. Also, I’m not clear on whether or how a release build can even have the console enabled.

Clearly none of these methods are suitable for a release build. Is it just not implemented yet? What are you supposed to do?

For example, running the 1.11 starter game from its launcher automatically loads a camera panning over a scene. How can you do this without automatically loading a level? If you need to automatically load a level, how do you do that?

I was able to get the level to load automatically from the exe by adding the following, in Visual Studio, in Gamename/Launchers/GamenameWindowsLauncher/Source/Main.cpp, in RunGame() function:

    std::string stringCommandLine = commandLine;
std::string loadLevel = " +map Workspace";
std::string newCommandLine = stringCommandLine + loadLevel;
// And modify this existing line of code by inserting the new string
strcpy(startupParams.szSystemCmdLine, newCommandLine.c_str());

Where “Workspace” is the map name. Obviously this is very hacky but I’m not aware of a better way.

Add a file called “autoexec.cfg” in your gem’s root folder, and in there add the console command to load the level.

See here:


FWIW, I modified my System Component to choose which cfg file to load and run under certain circumstances (e.g. dedicated server, client, lan server, etc), inspired mostly by “MultiplayerSampleSystemComponent::LoadInitialLevel()” (see Multiplayer Sample gem)

I attempted to use the autoexec.cgf solution and it didn’t work. Like in the post you linked, it just didn’t work. It seems to be a really brittle solution depending on a bunch of other stuff than having the autoexec file.

I’m not entirely sure that I followed a proper trajectory for my project. It seems like Lumberyard expects you to do a lot of things a certain way, but this isn’t really described in an accessible manner anywhere and it’s very easy to just cobble something together and find out later that you did it wrong. You’d have to read and internalize the entire user guide, developer guide, etc. and there’s probably still more information that’s just floating around or mentioned once in half a sentence somewhere.

I have no idea what sort of things I’ve done that may have affected the autoexec file working or not working. It’d be useful to know all the things that it needs to work, where exactly it needs to go, and so on. Luckily I found an acceptable workaround for now.

Did you look at the Multiplayer Sample gem to see how they loaded up their cfg files? I’ve adopted that flow, and it works well for me (loads different levels and settings depending on client, gamelift server, or lan server builds)

I didn’t look at that since we have no plans for multiplayer in the near future. I’ll remember to check it out next time I have to deal with this issue. Thanks!

I found that this is a poor hack because what VS refers to as “Gamename/Launchers/GamenameWindowsLauncher/Source/Main.cpp” Is actually NOT a game specific launcher. It’s actually points to Code\Launcher\WindowsLauncher/Main.cpp… for every project. Don’t edit this file unless you want to change your launcher for every project you’ll ever build with your LY install.

One COULD make the VS project point to an appropriate file - a copy of this Main.cpp in a suitable location with your other game code. I don’t understand Waf well enough to know how to do that.

I wound up instead editing GameStartup.cpp. That is to say:

VS Solution display: GameName/GameName/System/GameStartup.cpp

File location: \Code\GameName\Game\System\GameStartup.cpp

I added the following code at the top of the GameStartup::Init() function:

    // Force game to execute map load ////////////////////////////////////////////////////////
const char * commandLine = startupParams.szSystemCmdLine;
std::string stringCommandLine = commandLine;
std::string loadLevel = " +map Mapname";
std::string newCommandLine = stringCommandLine + loadLevel;
strcpy(startupParams.szSystemCmdLine, newCommandLine.c_str());
startupParams.bExecuteCommandLine = true;

According to this, “the console does not work properly in a release build”. Therefore the autoexec solution will not work, hence, I suppose, its not being included in that article.

You can’t open the console in release, but you can still run console commands.

When your module is done loading, just do this:

gEnv->pConsole->ExecuteString("exec whatever.cfg");

… where “whatever.cfg” is a file in your gem’s root folder.

And you’re right, “autoexec.cfg” isn’t engine functionality, it’s included in some gems (like SamplesProject or somesuch). That’s why it’s not loaded for you out-the-box. BUT - you can add that into your gem in < 10mins :stuck_out_tongue:

On my side, I pilfered the code from the MultiplayerSample’s startup to run my own .cfg files in my System component. Works like a charm, even in release. And has the added benefit of being able to set specific settings and whatnot on game launch without having to do any recompiles.

Btw, I noticed you’re going the “GameStartup.cpp” path as well. I don’t have that file, so I hooked into the generated SystemComponent. But, since you’re working with that, take a look at \dev\SamplesProject\Gem\Code\Source\System\GameStartup.cpp:

    int GameStartup::Run(const char* autoStartLevelName)
gEnv->pConsole->ExecuteString("exec autoexec.cfg");

Just add that line. And then create an autoexec.cfg file in your gem root. That’s it, you’re done :stuck_out_tongue: If you still can’t get it to work, I suggest you run the samples project and see how they do it, and go from there.

The point is: Somewhere, somehow, wherever you deem it appropriate, just run:

gEnv->pConsole->ExecuteString("exec somefile.cfg");

That’s it :stuck_out_tongue:

Bumping this because autoexec.cfg should work in release build IMO

autoexec.cfg does work in a release build? I made one a month ago or so and it works, I just think it might be in some pak file, not sure where though.

It doesn’t work for me. autoexec.cfg is inside the misc.pak (I still use the old way of packing assets because the new way is too involved and there’s still file dupes). I build the release, copy over all the necessary files. Run it and I get a black screen. But when I run the profile build autoexec.cfg works fine.

Can somebody here make a tutorial about releasing or publishing game with encryption.

Any ideas on what I’m missing, then? Since it doesn’t work for me.

wait I was wrong it was not in a pak file, it definitely can be in one, but I had it out of the pak while I was testing a few percentages, so it should work if it is out of the pak for sure, I just checked the build I made, and it seems to work with the autoexec out of it. I will try on a later date to have it inside of a pak folder for a more convenient release build, but for now it works.

I think I took mine out of the pak too and it still didn’t work, though.

are you sure it is the autoexec? I started with my build a long time ago with issues with the pak’s themselves. did you try to launch the level through command yet? If that works then it is the autoexec, if not then it is probably the pak files.

The console is disabled in release builds. If you have a console then you’re not in release build. I am sure it’s autoexec.cfg. I see it in misc.pak. I took it out and placed it outside of a pak. Still doesn’t work with a properly built release executable (console is disabled in release builds - using lmbr_waf build_win_x64_vs2019_release -p game_and_engine).

Further proof that autoexec.cfg does NOT work in release build

You are right my bad, that was not the release build I was on, but I did go onto the release build and it is broken for me, but it is paks so not this issue. Have you tried this, Run the exe file, after doing so close the project after the screen sits dark for a little while (maybe 10 sec). Then open the directory with your project, there should be a folder called user. In there you should see a fill that is a log of the game. Scroll to the bottom of the log, and see why the game does not use the autoexec, mine shows it is being used and after it is executed then mine breaks because my main menu pak is not set up correctly. This log should show you anything you need to know on why something is not working in a release build.