Amineri

There is also an issue with config files that I've run across. If any of the config files in your mods in the SDK folder have \\ line continuations, and if any of those have whitespace after the \\ it tends to cause UnrealEditor to crash when loading. These config files are no problem when loading into the game, it's just some quirk of the UnrealEd script package. The simplest way to test this is to move your mod folders out of the SDK and try and launch UnrealEd. This will prevent UnrealEd from loading your mod script/config packages to quickly determine if it is the problem.

So a little background on what's going on with the XComGame.upk replacement ... The issue before this patch 6 was that there was code to access the Steam API dll residing inside XComGame.upk. And that access was needed in order to find the mods in order to load them. This is what made it impossible to load XComGame replacements from workshop mods -- Nexus-style mods reside in the game folder, and have worked pretty much since release. Patch 6 moved the Steam API calls into the XCom2.exe, thus allowing the workshop mods to be loaded prior to XComGame.upk being loaded. However, there is currently a bug in the ported code which breaks the XComGame.upk replacement for both the workshop and Nexus-style mods XComGame replacements. I've been in contact with Firaxis to help troubleshoot the issue, so they are aware of and working it.

This is a perfectly valid approach, in my humble opionion. I just decided to go down the other road, leaving more things up to the modders, which also gives (I think) more flexibility in terms of how to set it up. Plus you also went the other route of having it save to config (which is persistent across all campaigns) instead of saving into the savefile (which is only per-campaign). I debated a lot trying to decide between these two options, and I don't feel that one is necessarily clearly superior to the other in all cases, so I'm glad that the other option has been released via MCM :smile:

So the issue here is that the function is called, it's just called from another native function. Unfortunately this means that you can't intercept it, as native-to-native calls don't pass through unrealscript to check for the override. To override this practically, what I've had to do is to override the upstream native function that is calling GetMultiTargetOptions. Since it is a member of X2AbilityMultiTargetStyle, the options are fairly limited. This is the method I used in the OfficerPack override to create the variable range Leader abilities. However in that case I skipped on re-implementing the GetValidTiles, since I didn't want a tile preview (having built a separate preview mechanic), and was worried about the overhead of computing all of the valid tiles in unrealscript -- things generally get optimized into native code for a reason. There are some other tricks possible to get around X2AbilityMultiTargetStyle native code, depending on the situation, which don't require completely rewriting the native code functionality in UScript. Since you are extending X2AbilityMultiTarget_Radius, what you can do is override all of the native classes, with each calling a helper that will update the fTargetRadius value based on your criteria, then continue on calling the super. native function. For example : simulated function float GetTargetCoverage(const XComGameState_Ability Abillity) { fTargetRadius = MyTargetRadiusHelper(Ability); super.GetTargetCoverage(Ability); } If you do this for each native function in the class (and the ancestor classes), as well as override GetTargetRadius completely, then whatever the hidden call order is in native code, your fTargetRadius will get set.

So another thing I discovered just recently ... If you try and launch uncooked (like say want to run the debugger through some base-game code, or trying to build an XComGame replacement), you can't run with the AlienHunters DLC. I just tried, and the game hangs while trying to load a strategy savefile, with the log spamming the message : [0119.92] ScriptWarning: Accessed None 'Level' XGBase Avenger_Root.TheWorld:PersistentLevel.XGBase_0 Function XComGame.XGBase:AreAuxMapsLoaded:040C This is because the DLC is only shipped in cooked fashion, so when running uncooked it can't load what it needs to in terms of content packages. I had this problem with Anarchy's Children as well, but in that case at least I'd only get missing body part content, which was fine for debugging. In this case my suspicion is that it is trying to load the new Armory backdrop and failing, and falls into an infinite loop because of it. For now the solution is to simple turn off the DLC while doing such tests.

I'll try and explain it in simple terms :) As an example, I'll mention a couple of things coming up in PerkPack, which I was able to implement without so many explicit class overrides. However, I still needed to provide some measure of the functionality needed. There were two particular cases where this came up : 1) UIArmory_Promotion -- the thing that displays the perks. We're going to have a lot more perks, so I built a new perk tree. Probably not a big surprise :) 2) Ability bar -- with more abilities (like from LeaderPack, etc), we're crowding the 15 ability limit. So we needed some solution handle 16+ active abilities on a soldiers. In both of these cases I I built a solution that swaps out the relevant class at run-time, rather than using the built-in class override system. What's the difference? 1) Built in class override. This is built into the game Engine itself. It's not code that resides in XComGame.upk, but in Engine.upk and Core.upk -- these are Epic's Unreal Engine packages that Firaxis has altered. What happens is that they overrode the Spawn and new functionality, so that when code requests to create one type of class, it actually builds another (child) class instead. Neat, and it effectively changes all instances where it's created, for those places in code that are hard to get to. The problem is that only one mod can override in this fashion, and there's no clean way to disable it, save requiring your player to go into and edit config files -- messy. 2) Replace the calling instances. This is more similar to what I did with LeaderPack, which has no explicit overrides (but does so indirectly at run-time). For PerkPack and the ability bar, for instance, instead of an explicit class override like above, I use a listener that listens for the UITacticalHUD to be created, then digs into that and finds the UITacticalHUD_AbilityContainer, and swaps it out for my customized version. The advantage here is that I can use an in-game configuration menu to turn that off and revert back to "default". Which can be either the base-game version, or one supplied by another mod. In all the cases where I can, this is what I do. However, in some cases option 2 isn't available, either because the code where the class is created is buried someplace inaccessible (like SquadSelect) or there are just too many places that call it. In that case I either have to resort to option 1, or abandon the functionality.

If you mean "Are we going to break Toolbox into 4 or 5 separate mods?", then we have no plans to right now. Managing 7 mods is enough for me ... that's a lot of possible combinations to troubleshoot, plus a lot of different forums to keep up with, and mods to update with patches. In terms of separating out the class overrides, arguably the UI changes to support 12 soldiers in squad select is one of the core features. Unfortunately, there's no option at run-time to enable/disable class overrides in the general case. Where I've been able to, I've avoiding using the class override system in favor of extending the class and swapping it run-time (PerkPack actually will support this option). Unfortunately UISquadSelect is triggered in such a way that run-time swapping of the UIScreen class just isn't possible -- otherwise I would have done so on the LeaderPack. The Tuple thing is isolated -- we made it a separate mod script package for that very reason. The ModOptions was another case like SquadSelect -- called from too many places and in ways difficulty to intercept to swap in a new one at run-time.

A note on manipulating cosmetic pawns... In X2CharacterTemplate, was added : var(X2CharacterTemplate) delegate<OnCosmeticUnitCreated> OnCosmeticUnitCreatedFn; However, this is used when cosmetic attachment units are created on a unit -- e.g. gremlin. This doesn't work generically whenever a cosmetic pawn is created. For that functionality, you need to use the : //Trigger to allow mods access to the newly created pawn `XEVENTMGR.TriggerEvent('OnCreateCinematicPawn', SpawnedPawn, self); called in XComGameState_Unit.CreatePawn

Have verified via running it that the new X2DownloadableContentInfo.OnLoadedSavedGameToStrategy works as advertised. It runs whenever loaded into the strategy, even if the DLC/Mod was already installed. For tactical, looks like we still have to rely on UITacticalHUD screenlistener, though.

So a common thing that may affect any mod that adds new abilities ... In X2Effect_Persistent.GetAttackingDamageModifier, the prototype has changed from : function int GetAttackingDamageModifier(XComGameState_Effect EffectState, XComGameState_Unit Attacker, Damageable TargetDamageable, XComGameState_Ability AbilityState, const out EffectAppliedData AppliedData, const int CurrentDamage) { return 0; } to function int GetAttackingDamageModifier(XComGameState_Effect EffectState, XComGameState_Unit Attacker, Damageable TargetDamageable, XComGameState_Ability AbilityState, const out EffectAppliedData AppliedData, const int CurrentDamage, optional XComGameState NewGameState) { return 0; } This will result in compile-time errors when building the mod against the new SDK. For mods that haven't been updated, I think this results in a CTD since there is a call in X2Effect_ApplyWeaponDamage where the NewGameState parameter is passed, and mods built under previous SDK won't be able to handle them. --------------------------------------- In terms of new functionality, some of the nicest is a series of new additions to X2DownloadableContentInfo. This includes : OnLoadedSavedGameToStrategyThis method is run when the player loads a saved game directly into Strategy while this DLC is installedOnPreMissionCalled just before the player launches into a tactical mission while this DLC / Mod is installedOnPostMissionCalled when the player completes a mission while this DLC / Mod is installedOnExitPostMissionSequenceCalled after the player exits the post-mission sequence while this DLC / Mod is installedOnPostTemplatesCreatedCalled after the Templates have been created (but before they are validated) while this DLC / Mod is active --------------------------------- One of the other nice changes in X2DownloadableContentInfo is that exec functions can now be created. For those not up-to-date on this : https://udn.epicgames.com/Three/ExecFunctions.html . This basically allows a modder to create her own console commands. Handy for testing out that big mod! :smile:

This sounds a lot like you've got some persistent reference to UITacticalHUD (or possibly a sub-element of it), which is preventing garbage collection on the re-load process. The simplest example of how this can occur is if a UIScreenListener maintains a class reference to UITacticalHUD.

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.