Cooking U to UPK

[abeclancy]

I think it would be nice if we could have a thread for instructions and advice for cooking game files.

 

Amineri made a post in the XCOM 2 forum that mentioned that the U files are uncooked, and should be cooked before publishing so they run faster and run without the NOSEEKFREELOADING argument on the game executable.

http://forums.nexusmods.com/index.php?/topic/3775625-discussion-about-how-do-i-change-xxx-in-the-game/

 

I'm currently in the process of trying to get the Unreal Engine (around version 3.5) installed, though the Epic Games Launcher doesn't quite work for some reason. So, I'm hoping that there is actually something in the XCOM 2 SDK directory or ModBuddy that would automate the process of cooking the U files.

 

If anyone has any additional information regarding cooking, or what process a mod creator *should* go through before publishing their final version of their mod, I'd love to hear your advice, and it would be nice to have this information on the forum for anyone else with similar questions.

[davidlallen]

I'm not sure what you mean by cooking. In modbuddy, you compile the uc files into a u file. Then, as far as modders are concerned, you are done, and you publish, and the NOSEEKFREELOADING flag is not required. If there is anything beyond that, it must not be required, since hundreds of mods have already been published and are working.

[Amineri]

My understanding is that cooking is possible via a commandlet.

 

The ModBuddy build script runs two commandlets. For example:

 

1) XComGame.com make -nopause -mods LW_OfficerPack "C:\Steam\SteamApps\common\XCOM 2 SDK\XComGame\\Mods\LW_OfficerPack\

 

This runs make commandlet, which actually does the compilation of the src .uc files into the .u script package

 

2) XComGame.com precompileshaders -nopause platform=pc_sm4 DLC=LW_OfficerPack

 

This runs precompileshaders commandlet, which scans through the packages and builds the ModShaderCache.

 

The FrontEnd app included in regular UDK is just a front end for running these commandlets through a GUI. From my understanding, all of the functionality to cook is present in the XComGame included in the SDK, if we know how to invoke it.

 

A full set of the commandlets included in Unreal 3 by Epic can be found here : https://udn.epicgames.com/Three/CommandletList.html .

 

Of particular interest for this discussion is the "CookPackages" commandlet : https://udn.epicgames.com/Three/CommandletList.html#CookPackages Commandlet :

 

 

 

CookPackages Commandlet

The cookpackagescommandlet will process and convert package data into a format that is readable for consoles.

Generally, you will run the cooker with the Unreal Frontend, but if you want to automate cooking or similar, you will want to use the commandline interface.

 

Syntax

gamename.exe CookPackages [map1 [map2] ... ] -platform=<Platform> [options]

 

Parameters

• platform=PLATFORM - Sets the platform to cook for. PLATFORM can be one of: pc, ps3, xbox360 or xenon
• full - Forces all of the existing packages to be resaved. If this option is specified, the contents of the CookedYYY folder is deleted first.
• recookseekfree - Forces all of seekfree packages to be recooked (startup, standalone seekfree, maps on commandline or .ini). Useful when the default dependency checking doesn't work (standalone seekfree packages in particular, because it won't recook all standalone seekfree packages when any non-seekfree packages change, unlike maps).
• cookallmaps - Cooks all maps in the game.
• mapsonly - Only cooks maps, will not attempt to cook anything else.
• inisonly - Only cook the .ini and localization files (into the Coalesced.ini and Coalesced.int, etc files).
• sha - Generate SHA hashes for the startup and coalesced files, and output to Hashes.sha.
• skipsavingmaps - Cooks, but doesn't save, maps. Useful for cooking LOC data used by maps.
• skipnotrequiredpackages - Skip loading & saving packages not required for cooking process to speed up LOC cooking.
• languageforcooking=LANG - Sets LANG as the language for localized cooking. Defaults to int (English).

 

 

 

[Amineri]

I'm not sure what you mean by cooking. In modbuddy, you compile the uc files into a u file. Then, as far as modders are concerned, you are done, and you publish, and the NOSEEKFREELOADING flag is not required. If there is anything beyond that, it must not be required, since hundreds of mods have already been published and are working.

 

You can find a useful article about Unreal Cooking here : https://udn.epicgames.com/Three/ContentCooking.html

 

A couple of salient points :

• PCs, as well, can now use cooked data, which will result in much faster loading speed.
• On consoles, UE3 only supports loading cooked packages. UE3 on PC can load cooked, uncooked, or even a mix of both.
• Launching the game with an uncooked XComGame.u requires special commandline parameters, and is not suggested for a deployed mod

In general, there's two categories that you are going to want to cook :

• Maps -- streaming in maps takes a lot of time already, and streaming in uncooked maps takes even longer
• XComGame -- for total conversion mods that replace XComGame, cooking is basically required

 

One thing I noticed ... the list of parameters on the ContentCooking page is longer, and includes :

 

usermode: Cooks content as if it's DLC or a mod (this will only cook what's specified on the commandline, it won't cook shipped script packages, etc). For more information about DLC, see DownloadableContent and DLCOnPS3.

I suspect that we are going to want to cook our mods using this usermode option. Unfortunately, additional information about usermode and cooking DLC or mods on Epic's site is restricted.

[davidlallen]

But. normally for a mod which changes several uc files, no cooking is required, and there would be no visible difference in load time. Correct? I don't want casual readers to come away with the idea that all this setup for cooking is required or else your mod will "load too slow".

[Amineri]

But. normally for a mod which changes several uc files, no cooking is required, and there would be no visible difference in load time. Correct? I don't want casual readers to come away with the idea that all this setup for cooking is required or else your mod will "load too slow".

 

This is correct. In most cases cooking isn't required.

 

All three of our release-day mods were released uncooked, with little performance consequence. As time goes on and more and more mods get released, and people start loading up tons of mods, there may be a shift toward cooking mods for performance reasons, but at this point it shouldn't be a concern in the majority of cases.

 

P.S. In Long War for Enemy Within, I played around with cooking the Content Package we created to hold all of the UI textures we used. There was a substantial size reduction in the file (from around 70 MB to 30 or so, IIRC), but in the end we never ended up releasing it as cooked.

 

Another big downside to cooking is that it becomes impossible to open such cooked upks in Unreal Editor. This is why all of the content in the SDK remains uncooked.

[abeclancy]

Alright. So when you create a new Default Mod in XComBuddy, it creates a mod that contains two separate folders in the \Src directory of your project: \Src\XComGame\Classes and \Src\YourMod\Classes. It compiles and creates two files in the resulting steamapps\common\XCOM 2\XComGame\Mods\YourMod\Scripts directory: YourMod.u and XComGame.u. This seems to be the process that you want to follow if you are looking to modify native core game functions.

 

(Note: If you are just making an Example Mod, such as a new weapon or a new mission, then you only get the one \Src\YourMod\Classes directory in your project, and one \Mods\YourMod\Scripts\YourMod.u file when it compiles.)

 

If you run the game with the -NOSEEKFREELOADING option through Steam, it loads the custom XComGame.u file and all your changes work. But if you don't use that flag, then your mod isn't loaded.

 

So I guess what the overall question is (and what I thought you might be required to cook the XComGame.u file for) is how to get your custom XComGame.u file/mod loaded without requiring the -NOSEEKFREELOADING argument, so that it can "just work" through the steam workshop or through unzipping and placing the mod in the \Mods directory. My assumption from Amineri's original post (see original post in this thread for link), is that you CAN'T get your XComGame.u loaded unless you cook. Other mods are working because they don't have to cook because they are not modifying the core XComGame.

 

Unless I'm missing something silly, like `log() is disabled without the -NOSEEKFREELOADING argument. But there are ScriptLog messages in the Launch.log, so I'm assuming that `log() works regardless of the flag.

 

Edit: The XComGame.u in \Mods\YourMod\Scripts isn't loading, it's not just an issue with log statements.

Edited February 29, 2016 by abeclancy

[davidlallen]

Your steps seem way more complicated than mine. Are you really trying to remove every single file in the distribution and replace with your own? If so, why?

 

The first thing I do when I create a new project in modbuddy is delete the entire directory Src/XComGame.

 

I never use the flag -NOSEEKFREELOADING.

 

My mods load and run fine, both when distributed through workshop and when downloaded through nexus.

 

Is it possible your mods appear not to run due to some other problem, such as missing/wrong/overridden entries in XComEngine.ini?

[abeclancy]

I'm wondering if you're just not changing any of the native core files. Are you overridding any classes that have a class declaration that includes native(core)? If you are, and you have a working mod, then I would love to know what you are doing to properly override those classes, or functions within those classes!

[davidlallen]

OK, that is the difference. I am not trying to extend anything which is declared native. My understanding is that this is doomed to failure, regardless of whether you cook. These classes have C++ code involved, and trying to change just the uc part will lead to weird, unpredictable behavior. But, #std_disclaimer, I am not an expert.

 

Which are the classes you are attempting to change, and what are you attempting to mod into them?

 

Is there a way you can use screen listeners, or some other approach, instead of attempting to change these classes?