Amineri

The "approved solution" to issue #1 is to use the X2DownloadableContentInfo.InstallNewCampaign method to create your gamestate when starting a new campaign. It gets passed the StartState, which you add your new gamestates to. Then you don't submit, but let the base-game code that called X2DLCInfo.InstallNewCampaign do so when it is ready.

It certainly is. You need to set up a new configuration in the ModBoddy VS Shell. Where it says Default, click and go into "Configuration Manager...". Create a new one copied from Default and name it "Debug". Build with the new configuration. I think if you hit Start Debugging (F5) it's automatically updated, but I generally have some batch scripts I used to launch with debugging : ModLauncherWPF.exe -allowconsole -log -autodebug if I only need to set breakpoints in my mod code (it loads stuff faster), or : ModLauncherWPF.exe -allowconsole -log -autodebug -NOSEEKFREELOADING if I need to set breakpoints in XComGame or some other deeper package. Note that the -NOSEEKFREELOADING tag runs with only uncooked packages, so all the Firaxis DLC won't load.

This only works when running the game uncooked. There is a ton of text being assembled and cached for these logs, so I'm pretty sure they are wrapped in NOT_FINAL_RELEASE precompiler directives. I got it working by launching with the -NOSEEKFREELOADING commandline option. You may also may have had to make some change so that XComGame.u ends up in your Mods/<YourModName>/Scripts folder. But if you can run with run-time breakpoints in your XComGame.u, then I'm pretty sure it must be running the non-final release version. FYI, what I do to run the game is create two new batch files within the XCOM 2/Binaries/Win64/Launcher/ folder, with contents : ModLauncherWPF.exe -allowconsole -log -NOSEEKFREELOADING and ModLauncherWPF.exe -allowconsole -log -autodebug -NOSEEKFREELOADING The first is used for regular uncooked running. The second is used for uncooked run-time debugger.

Made a discovery in debugging Behavior Trees that may be of use to some. The console command is \AIDumpLogs. This only works when running uncooked (commandline parameter -NOSEEKFREELOADING ). It dumps a serious amount of cached information about BehaviorTree operation into the Launch.log. A single enemy's (2 action) turn resulted in ~750 lines of dump data.

The Issue One current issue with XCOM 2 (which it really inherited directly from Unreal Engine 3) is how config file merging is done. When the game launches, the Default*.ini files in the XCOM 2 root game config folder ( \Steam\SteamApps\common\XCOM 2\XComGame\Config ) get merged with all DLC and mod XCom*.ini files (located in the DLC and Mods folder, also in XComGame). The result of the merge named as XCom*.ini is put into a writeable folder (on Windows, \Documents\My Games\XCOM2\XComGame\Config). Firaxis has modified this slightly so that for some config files, the result isn't cached, but is regenerated each time. The logic for the merging has an optimization that checks file time-stamps to determine if merging is necessary. I believe the way that it works is that if the time-stamp on either the merged XCom*.ini or the Default*.ini file is later than the time-stamp on the DLC / mod config file, then the merge does not occur, because it "must be up to date". This can fail in one of two ways that I know of, but only for particular config files : The user starts the game with a mod disabled. Disabling doesn't change the time-stamp on any config file, so merging may not occur Firaxis releases an update, with config files with a later date than a mod's config files. Since the mod's config file is older, merging may not occur.Config files in particular that I've observed this behavior with : *Engine.ini*ClassData.iniThere may be others ... I don't claim this list is complete. Issues with these two config files can result in particularly nasty bugs. Engine.ini holds class-overrides, so a failure to merge can result in class-overrides not taking effect, which definitely can lead to buggy operation. ClassData.ini hold classes and ability data, so this file not updating can result in extra classes/ability info hanging around, or not being present when it should. A (Partial) Solution One current way to handle the issue is to delete all of the cached XCom*.ini files in the My Games (or equivalent on Mac/*nix). This has been part of the standard set of "Troubleshooting Tools" for Long War for Enemy Within for a long time. Deleting these files forces the game to regenerate them on the next game launch. Another solution is to add the commandline option -REGENERATEINIS. This has the same effect, forcing a regeneration of all config files when the game is launched. More info about the commandline parameter can be found here : https://udn.epicgames.com/Three/CommandLineArguments.html#INI/Config Files So why is this a partial solution? Because forcing regeneration of the config files has some undesirable side-effects. In particular, graphics settings are stored in the cached version of XComEngine.ini, so forcing them to be regenerated will reset your graphics settings to default each time it is done. There are a lot of other changes to this file as well ... just do a diff of the XComEngine.ini in the My Games folder against the DefaultEngine.ini in the XCOM 2 game config folder, and you'll see that there are a lot of changes. To avoid the headache of constantly re-setting my graphics settings each time I launch, I've copied some of these settings that get created in the XComEngine.ini to the default version, so that the game always starts with a (to me) more preferable set of graphics settings. These settings are found under : [SystemSettings] The steps I took were : Launch the game, using -REGENERATEINIS command-line argument In-game, change the graphic settings to those I want Exit the game Use a text editor to open both XComEngine.ini from My Games and DefaultEngine.ini from XCOM 2 game config folder Copy settings under [systemSettings] from XCom to Default version Launch the game, using -REGENERATEINIS command-line argument Observe that the new default system settings are used for graphicsThis still isn't perfect, since there are other settings that would be nice to preserve. For example, the history of console commands used is wiped out by -REGENERATEINIS. However, for me, the benefit of always getting the correct config file merging every time is outweigh the negative side effects that come from always re-merging.

GAD = Global Asset Database. Info on how to turn it off here : http://forums.nexusmods.com/index.php?/topic/3901170-tiptrick-launching-unrealed-quicker/

There's a couple of things going on here. Due to the way Epic architected Unreal Engine 3, pretty much everything runs through the *Game.exe (UDKGame.exe for stock UDK, XComGame.exe for XCOM 2 SDK). This includes the make and precompileshaders commandlets that the ModBuddy Build command executes and the UnrealEditor. If you run into the SDK Logs folder and look at the various logs, you'll see in various logs the following : Launching Unreal Editor: Init: Command line: editor -noscriptcompile Build make commandlet: Init: Command line: precompileshaders -nopause platform=pc_sm4 DLC=LW_OfficerPack Build precompileshaders commandlet: Init: Command line: make -nopause -mods LW_OfficerPack "C:\Steam\SteamApps\common\XCOM 2 SDK\XComGame\\Mods\LW_OfficerPack\" What's happening is that all of these processes are all run through the same copy of XComGame.exe in the SDK folder. And so they all try and write to the same log file. This log-file collision is technical the first thing that breaks if you try and build while UnrealEd is open. That's because the UnrealEd process has the Launch.log open already when the make commandlet tries to rename the existing Launch.log to the Launch-backup. This fails, so the process fails. However, there are other interdependencies between the scripts and UnrealEd. UnrealEd actually loads all of the ModShaderCaches, script packages, and config data from the mods in the SDK. In some cases this is 100% necessary (build XComPerkContent archetypes, build new archetypes based on mod script). So it's likely that other stuff would break as well.

Ah, sorry, I missed the forest for the trees :) The code to get the owner (in a component sense) of a component is : XComGameState_Unit(`XCOMHISTORY.GetGameStateForObjectID(OwningObjectId));

GetParentGameState doesn't appear to be related to the component system. Instead, it's more involved with the XComGameStateHistory. Because of how the XComGameStateHistory works, there is more than a single instance of XCGameState_Unit for a particular unit. In fact, there is (in general) one instance of it for each change to a particular unit. In this way it's much like a VersionControlSystem -- a history of past changes to each gamestate is maintained within the history. "Uniqueness" of an object is maintained via it's ObjectID. So there might be a bunch of copies of XComGameState_Unit floating around with the same ObjectID -- these are the same unit at different points in time during play. This is why things are accessed via pointer to XComGameState_BaseObjects -- because a pointer might reference an out-of-date on in the past. Instead, the ObjectID is used and the most recent version (typically) is retrieved from the History. GetParentGameState is somewhat unfortunately named -- it's not a parent in the sense of "object oriented class inheritence", nor is it a parent in the sense of "owner of this component". Instead it's the previous version of the gamestate in the history -- a parent in the sense of time. This is why it's often used within contexts. Contexts are basically a sort of "series of planned gamestate changes". They aren't all entered at once to allow for interruptions. A very typical instance of this is unit movement. Each movement to a different tile constitutes a change to the unit gamestate. So a unit that is dashing 12 tiles is going to get 12 gamestate updates (at least), one for each new tile position. The context wraps up all of these planned gamestate changes into a single container. After each move to a new tile, there is a MovementObserver that has a change to insert a new gamestate change into the sequence, possibly disrupting the planned series. A typical example of this is reaction fire, which can interrupt a move, resulting in the unit never making it to the planned final destination tile. So the reason you see GetParentGameState getting frequently used in Contexts is that they are checking the current versus previous (in the history) to see what changed, in order to implement either some gameplay logic or visualization.

This is true, when we started off, we were hardly thinking of making some massive overhaul mod. As we went along, I kept figuring out new technical tricks to add new bits to the game, while JL kept on saying "This is it, we need to release final version"... ha ha ha :) In part I think it worked because JL and I happen to work well together.

Another option for playing particle effects is via an XComPerkContent archetype. This archetype is primarily used for particle effects that are linked to abilities/effects. Although you can sort of cheat around that by creating a persistent ability that doesn't really do anything :).

The lighting in the ContentBrowser preview browsers is pretty terrible. As for maps, sometimes they open up in "Unlit" view mode instead of "Lit". "Lit" looks much better when there's actual lighting (like on parcels), but when there's not any lighting (like in Cinematic maps), you have to use "Unlit" to see anything.

I don't think a TypicalAbility_BuildVisualization is going for such a custom ability. The TypicalAbility handles common stuff like triggering FF_Fire animations on weapon items and the like, not running and attacking a unit. A decent example is in the OfficerPack, the FallBack ability. It has a custom visualization : Template.BuildVisualizationFn = FallBack_BuildVisualization; The FallBack ability is an activate-able ability used by the officer on another unit, which makes the targeted make an immediate AI-controlled defensive move (typically toward cover). In our case, the visualization is just what's happening on the officer, which triggers the 'HL_SignalEncourage' animation with : PlayAnimationAction = X2Action_PlayAnimation(class'X2Action_PlayAnimation'.static.AddToVisualizationTrack(BuildTrack, context)); PlayAnimationAction.Params.AnimName = 'HL_SignalEncourage'; PlayAnimationAction.bFinishAnimationWait = true; What happens on the unit (including animations) is handled via X2Effect_FallBack with a special invocation into the BehaviorTree code : // Kick off panic behavior tree. FallBackBehaviorTree = 'FallBackRoot'; // Delayed behavior tree kick-off. Points must be added and game state submitted before the behavior tree can // update, since it requires the ability cache to be refreshed with the new action points. UnitState.AutoRunBehaviorTree(FallBackBehaviorTree, 1, `XCOMHISTORY.GetCurrentHistoryIndex() + 1, true); I'm not sure if it will help, but it might give you some clues in the right direction :)

I've looked over this, but not yet in a really detailed manner. Part of the issue sounds like a problem with the VisualizationFn, which is used to actually view stuff on screen. There was a pre-release version of the game where the pistol 'Faceoff' didn't yet have an associate animation/visualization function, with the same result. The game would simply pause for a bit until the visualization timed out, then all the units would take damage.

As described at the end of this page : https://udn.epicgames.com/Three/TextureSupportAndSettings.html You can adjust the LODBias of each imported textures. I found that if you change LODBias from the default of 0 to -3, then the in-UDK max resolution changes from 256 up 3 MIP levels to 2048. Basically it seems that UnrealEd is defaulting to the minimum texture size in the LOD group settings in Engine.ini: TEXTUREGROUP_Weapon=(MinLODSize=256,MaxLODSize=2048,LODBias=0,MinMagFilter=aniso,MipFilter=point) In the game the maximum texture size is controlled via the options menu / texture quality setting, but there's no such controls in UnrealEditor that I can find. Instead, the easiest alternative I've found is to edit the DefaultEngine.ini file in : \Steam\SteamApps\common\XCOM 2 SDK\XComGame\Config\DefaultEngine.ini You'll want to change only the section SystemsSettingsEditor, not SystemSettings: [SystemSettingsEditor] ResX=1280 ResY=720 Trilinear=True TEXTUREGROUP_Character=(MinLODSize=256,MaxLODSize=4096,LODBias=-4,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_CharacterNormalMap=(MinLODSize=256,MaxLODSize=4096,LODBias=-4,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_CharacterSpecular=(MinLODSize=256,MaxLODSize=4096,LODBias=-4,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_Cinematic=(MinLODSize=4096,MaxLODSize=4096,LODBias=-4,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_Effects=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_EffectsNotFiltered=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_LightAndShadowMap=(MinLODSize=512,MaxLODSize=4096,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_RenderTarget=(MinLODSize=1,MaxLODSize=4096,LODBias=0,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_Skybox=(MinLODSize=512,MaxLODSize=2048,LODBias=0,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_UI=(MinLODSize=512,MaxLODSize=1024,LODBias=0,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_UI3D=(MinLODSize=128,MaxLODSize=1024,LODBias=0,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_Vehicle=(MinLODSize=512,MaxLODSize=2048,LODBias=-2,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_VehicleNormalMap=(MinLODSize=512,MaxLODSize=2048,LODBias=-2,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_VehicleSpecular=(MinLODSize=512,MaxLODSize=2048,LODBias=-2,MinMagFilter=linear,MipFilter=point) ;TEXTUREGROUP_Vehicle=(MinLODSize=512,MaxLODSize=2048,LODBias=0,MinMagFilter=aniso,MipFilter=point) ;TEXTUREGROUP_VehicleNormalMap=(MinLODSize=512,MaxLODSize=2048,LODBias=0,MinMagFilter=aniso,MipFilter=point) ;TEXTUREGROUP_VehicleSpecular=(MinLODSize=512,MaxLODSize=2048,LODBias=0,MinMagFilter=linear,MipFilter=point) ;TEXTUREGROUP_Vehicle=(MinLODSize=512,MaxLODSize=1024,LODBias=0,MinMagFilter=aniso,MipFilter=point) ;TEXTUREGROUP_VehicleNormalMap=(MinLODSize=512,MaxLODSize=1024,LODBias=0,MinMagFilter=aniso,MipFilter=point) ;TEXTUREGROUP_VehicleSpecular=(MinLODSize=512,MaxLODSize=1024,LODBias=0,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_Weapon=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_WeaponNormalMap=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_WeaponSpecular=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=linear,MipFilter=point) TEXTUREGROUP_World=(MinLODSize=256,MaxLODSize=1024,LODBias=-2,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_World1x2=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_World1x4=(MinLODSize=256,MaxLODSize=2048,LODBias=-3,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_WORLDHIGH=(MinLODSize=256,MaxLODSize=8192,LODBias=-4,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_WorldNormalMap=(MinLODSize=256,MaxLODSize=1024,LODBias=-2,MinMagFilter=aniso,MipFilter=point) TEXTUREGROUP_WorldSpecular=(MinLODSize=256,MaxLODSize=1024,LODBias=-2,MinMagFilter=linear,MipFilter=point) In the above I've set the LODBias for each texture to use the MaxLODSize instead of the minimum (in the editor), which is similar to setting Textures : Max in the game Graphics Settings.

This needs to be adjusted in the Archetype, the XComUnitPawn / CollisionHeight is what I've played around with.

If you need something to be ultra-persistent, you can create a UIScreenListener child class. These are created when the game loads up and aren't even destroyed/recreated when the game does a load-game. So you could create a persistent instance of X2StrategyElement_DefaultMissionSources in the ScreenListener, and reference that from your template definition. Of course, these is getting really ugly/hack-ey, basically trying to work around something that wasn't created as a static function. It may be cleaner to duplicate the code (as a static function) into your new class.

Hmm, yes, in that example, it looks to me as if the StartOnComplete should be defined as static. It's only some unrealscript delegate weirdness that is preventing it from throwing errors, I suspect. That and the native code that finds the X2DataSet-derived classes must be keeping the instances around so that the delegate can find something. Unfortunately, it seems that the handling of the X2DataSet-derived classes is only done by native code, and there's no way to access them via mod code. You might try something like : local X2StrategyElement_DefaultMissionSources MissionSources; MissionSources = new class'X2StrategyElement_DefaultMissionSources'; Template.OnFailureFn = MissionSources.StartOnComplete; However, since MissionSources is local in scope, I'm not really sure if the delegate would be able to trace back to it.

My suspicion is that the problem is because you are trying to override a parent class. There are 10 other classes that extend X2AbilityToHitCalc. X2AbilityToHitCalc itself is an abstract class : class X2AbilityToHitCalc extends Object abstract; so it's not even going to ever be instanced with new -- so the class override just isn't going to work. The class override isn't an "automagical" fix it -- all it does is replace one type of class with another when the new or Spawn functions create class instances. It doesn't figure out how to make the other 10 classes that extend X2AbilityToHitCalc use your new version. For example : class X2AbilityToHitCalc_Hacking extends X2AbilityToHitCalc config(GameCore); Fixing it at run-time to make the Hacking extension use your new override version would be a somewhat minor miracle ^_^ I'm not sure what a good solution is here, short of either a total overhaul replacement of XComGame.upk or doing class replacement on all 10 child classes of X2AbilityToHitCalc.

Sometimes functions that could be used as static aren't defined as such, which is a shame since then you have to workaround calling it. If it's not static, then there's a couple of options : 1) If it belongs to a singleton instance of a gamestate, simply retrieve the singleton instance from history and then access the function. 2) If it belongs to another class, and it truly can be used as static (not calling any class variables), then you can simply define a local instance of it and use new/Spawn to create it, then use the function in your local instance.

So one feature of Unreal Editor is that it can connect to an "Asset Database" to keep available maps/assets synchronized between developers on large teams. For a modder, however, this Asset Database isn't available resulting in a few extra seconds of load time each time UnrealEd is launched as it tries to find the asset database, fails, then displays a warning dialogue. Information about this can be found here : https://udn.epicgames.com/Three/ContentBrowserDatabase.html#Offline Mode Essentially what you need to do is open the config file DefaultEditorUserSettings.ini in the folder \Steam\SteamApps\common\XCOM 2 SDK\XComGame\Config\ and add the following : [GameAssetDatabase] OfflineMode=true This will skip the Game Asset Database test on UnrealEd startup, shaving a few seconds off the launch time, and will prevent that particular warning dialogue from appearing.

Try expanding your search to the config files (AI.ini in particular). Behaviors=(BehaviorName=AdvTrooper_RedAbilitySelector, NodeType=Selector, Child[0]=MimicBeaconBehavior, Child[1]=AdventRedFirstAction, Child[2]=AdventRedLastAction)

We did a similar sort of customization for the Centurion WarCry ability. We found and used an otherwise unused "Berserker roar" voice-type sound effect. However, in order to time it to the animation at a certain point it gets trigger during the anim via a notify. This is configured in UnrealEd, and allow more precise control of when sound effects play relative to an animation. However, it makes it more difficult to change it up at run-time, or to mod, as you've found.

Thought I would bump this in light of today's patch. The patch to the SDK does appear to include the auto-deletion of the LocalShaderCache from SDK Content folder. So it's an improvement. However, the precompileshaders commandlet is still loading ModShaderCaches from other the SDK Mods folder. So if you happen to have two mods that both build the same customization of a material instance, there can be cross coupling between the shader caches of the two mods. Hence you still need to at the least delete the ModShaderCaches from other mods when building. This is a bit of a corner case, but is something I was able to reproduce in a non-pathological use-case.

Nope, this was a problem I ran into with OfficerPack as well, which is why I had to resort to the more extreme measures of class replacement. Note that I didn't use the built-in new/spawn driven class replacement as set up in Engine.ini (since that wasn't available when I wrote the code), but instead replaced the SquadSelect_ListItem from within a UISquadSelect ScreenListener. Overall it's a fairly hack-ey solution, and I can't recommend it, and I can't really recommend it. Especially since the mod would be incompatible with OfficerPack.