Amineri

Sorry, I'm going to have to slow down on answering questions on how to develop specific mods -- basically only if it illustrates some general principle of modding. I wish I had the time to help everyone, but my own coding productivity that last few days has really tanked :( I'll still be dropping in once a day, but need to get back to coding myself. Plus still a lot for me to learn :)

This would require heavy work in Kismet, which is where most of the mission scripting is handled. Kismet is located inside the umap files. I'm not sure which is for the tutorial.

The game makes certain assumptions about classes, but you may be able to to what you want in the ClassData.ini. You'd need to add your new class to XComGame.X2SoldierClass_DefaultClasses section. Then create a new section for [AdvSoldier X2SoldierClassTemplate] in the same config

So this use of "template" is a little more XCOM 2-centric, and not really an Unreal Engine 3 thing. It fits together something like so: Template base class (e.g. X2WeaponTemplate.uc). Extends X2DataTemplate.uc (root class) There's only one of these, and it defines all of the things that can be configured. It's a class and not just config data because templates can include delegate functions, which can't be defined in configuration files Template class instances (e.g. X2Item_DefaultWeapons). Extends X2DataSet.uc (root class) Creates a bunch of instances of X2WeaponTemplate and fills out details for each Native code runs any child class of X2DataSet to create the template instances when game is launched Not saved as part of savefile, but recreated each time game launches TemplateManager class instances (e.g. X2ItemManager.uc) Extends X2DataTemplateManager.uc (root class) Provides single access point to retrieve all data template instances created Gamestate instance (e.g. XComGameState_Item) Extends XComGameState_BaseObject.uc (root class) Creates a particular instance of something, such as a particular soldier's customized weapon Typically initialized using data from a template instance Saved as part of savefile, loaded from save when loading game There is also an XComGameStateHistory that manages all of the gamestate objects, but that's more complex and getting away from your question about templates.

Yes, this was exactly the error I had, and it took me forever to figure it out. In my case it manifested with a screen listener on UITacticalHUD, and would show up when attempting to load a tactical save from within a tactical mission. This is because the UIScreenListener child class instances aren't destroyed and recreated on a save, so anything they reference can't be garbage collected. The safest thing to do is to not hold references to the triggering UIScreen in a class variable in the UIScreenListener. This is what I ended up doing in the listener for UITacticalHUD. For the other strategy layer classes, I added code to clear the reference when the relevant UIScreen is removed: event OnRemoved(UIScreen Screen) { //clear reference to UIScreen so it can be garbage collected ParentScreen = none; } Sometimes it may seem necessary to hold a reference to the UIScreen in order to implement button callbacks, and it's definitely the most straightforward. However, it was discovered that UISquadSelect doesn't call OnRemove when entering the final mission, so I had to use the following workaround to access the UISquadSelect: SquadSelect = UISquadSelect(`SCREENSTACK.GetScreen(class'UISquadSelect')); Of course, this assumes that there is only one instance of UISquadSelect on the stack, which is the sort of thing that causes problems when garbage collection fails :)

Looking at your mod ini file, it looks like you are treating it as if it were a replacement for the Default version, but that's not how Unreal Engine 3 handles config files -- and for good reason. If it were simple replacement, then only one mod/DLC could make changes to a particular config file. Instead, it is a merging process. There are "command prefixes" that allow adding lines to and deleting lines from the Default version. From the Epic documentation page : The full page is here : https://udn.epicgames.com/Three/ConfigurationFiles.html

The "Default" versions are more like the "base" version that everything else is built from. The "XCom" versions in the My Games folder are the versions that are built/updated when the game launches. These are built by merging the "Default" version with any "XCom" versions of mod files in DLC or mods (functionally, DLC and mods integrate into the game in the same way). One very important thing to realize is that the versions in the My Games folder are rebuilt using file timestamp information. So, if a mod applies a delta file that removes/changes a line that was in the Default, if the mod is made inactive or even deleted, the versions in the My Games won't be updated (because timestamps haven't been changed). This will result in inactive/delete mods "leaking" into cases where they shouldn't. Firaxis is aware of this issue. The current workaround is to delete the config files in the My Games folder to force the game to rebuild them. This will be necessary when removing or not using a mod that makes adjustements to the Default configurations. This is actually a common problem in Unreal Engine 3, and was something that often had to be done with Long War for EU and EW.

It probably is possible, but in the base game your starting location is randomized. As are the links between regions. Are are the contintent bonuses. Really the only thing not randomized are the 16 regions -- their shape and location.

Well, the very short answer is that I didn't make the MSK, we had our artist JC Lewis make the MSK. There are a lot of tools around for painting 3D objects, and I'm not actually sure what he used.

Gremlin models, textures and animations are under the "Weapons" section in UnrealEd. The Gremlin archetypes (as secondary weapons) are under GameData/Weapons/Weapon_Types. There are different archetypes for each of the three tiers, and the weapon animations used are defined in the archetype. It's a special archetype class, however : XComAnimatedWeapon. I'd suggest by starting with the WP_Gremlin_CV archetype, copying it to a new art package, and then modifying it bit by bit.

So, the answer depends somewhat on what material you used. If you imported the whole model with a material as defined in your 3D authoring tool, I'm not sure you'd be able to. We used the same materials as Firaxis (included in the SDK). WeaponCustomizable_TC for the conventional/magnetic, and M_Master_PwrdWep_TC for the beam. In both cases, you need to define the tint-able area of the model in one of the textures. The MSK texture, Blue color channel, if I recall correctly. Since it's the full channel, you can use grey values to determine amount of tint/pattern. Also, when configuring the material instance in UnrealEd, be sure to enable tinting. For the WeaponCustomizable_TC material, under Switches, enable UseTint and under Pattern, enable Pattern (and perhaps set the Pattern_UVScale if needed). For the M_Master_PwerdWep_TC, there's no toggle for tinting (it's on by default), but the Pattern/ Pattern toggle and Pattern_UVScale need to be enabled. And if you are curious about the difference between the two, the former allows for "metalness" in the alpha channel, while the latter allows for flickering emissive and has "gloss" designed to better match the powered armors.

The ModShaderCache is something that is built during the second step of the build process. Unreal uses compiled shaders (compiled from the materials). If the shaders are not compiled in advance, one of two things can happen. Sometimes the wrong shader gets used, and ends up with incorrect references, resulting in a "bad" material (we'd see solid block during our development), or the shader will be compiled at run-time, resulting in sometimes significant lag, depending on how many in total have to be compiled. So the ModShaderCache.upk is automatically build from the art packages in the mod Content folder, and is only used by the game at launch to load the precompiled shaders. When I was researching this a while back, I discovered that some UnrealTournament maps would take several minutes to load due to having to compile the shaders at run-time. And nobody wants that :)

Unfortunately I have not figured out how to do this, and will be quite happy when someone figures it out ^_^

So the reason comes down to templates versus game states. Templates are single things (e.g. this is what a starting soldier's stats looks like), while game states are instances of particular things, which often copy a bunch of data from a template (e.g. this particular soldier has these particular stats at this particular time). Since stats level up and can change dynamically (e.g. shaken soldier), the stats are stored per soldier, and so in the game state. When the soldier is created (starting soldiers, initial recruit pool, extra recruits each supply drop), the initial stats for the current difficulty are copied from the template into the gamestate, and gamestates are what get saved in the savefile. So to change the stats in an ongoing campaign, you'd need to write code into an X2DownloadableContentInfo.OnLoadedSaveGame function which scans through all the soldier gamestates in the game and updates them all. Templates, however, are not saved in the savefile, and instead are built from the config data and template code each time the game launches.

Also, there's currently only 7 categories of upgrades, and two of them are "mutually exclusive" (scope and laser sight) because the models overlap. So really you could only fit 6 upgrades -- until more upgrade types get added, anyhow.

It might be the way you are setting up your mod config files. You likely need to mark to delete the old line, then add the new line. Something like so: [Soldier X2CharacterTemplate] -CharacterBaseStats[eStat_FlankingCritChance]=50 +CharacterBaseStats[eStat_FlankingCritChance]=100 The first line prefix - tells the merger to remove the line, using both key and value. The second line prefix + tells the merger to add the line if it doesn't already exist. Alternatives are the ! prefix, which removes based on key, ignoring value, and the . prefix, which unconditionally adds the line, even if that results in a duplicate.

Thank you very much! It was really helpful However, whenever I try to import the .fbx to UnrealEd it shows up this message and crashes (It only does this with the modded file): <snip> Any thoughs on what could be wrong? Importing assets into UnrealEd can be an art in itself. We had our own share of issues with trying to set up an FBX import pipeline from Blender. The spam of error messages are indicating that it's some sort of native code crash when UnrealEd is trying to import. You might get some (slightly) more useful information from the Launch.log in the SDK folder. This is separate from the Launch.log in the My Games folder you get when running the game. Look at /XCom 2 SDK/XComGame/Logs/ (in your steam folder) for the Launch.log. This may give some additional context about what the problem may be. I know that JC and I had to go through several iterations with him tweaking Blender settings in order to get the file to import.

Since this seems to be a popular request, I did a little bit of digging and in the UIArmory_WeaponUpgrade.uc, the number of upgrade slots is always pulled from the weapon template info -- it's not cached in a game state. local XComGameState_Item Weapon; NumUpgradeSlots = X2WeaponTemplate(Weapon.GetMyTemplate()).NumUpgradeSlots; This is the difference between whether changing the template will have an effect on an existing save/campaign or not. If the value can be customized per item/character/etc, then the value will be stored in the game state and saved/loaded from there, so changing the template will have no effect. The side-effect of always pulling from the template (as in this case), is that's in not possible to directly customize individual weapons to have a different number of upgrade slots than another weapon of the same type. So you can't "upgrade the number of upgrade slots".

There aren't any significant animation editing tools within UnrealEd. The most you can do is time Notifies along the animation timeline (sounds, Kismet events, IK on/off, particle effects, etc). To actually modify the animation movement itself, you'll need a separate animation application (Blender, Maya, etc). You can export the animations to FBX, then open the FBX in you animator, work with it, then re-import it back into UnrealEd in a new mod *.upk. This page should be helpful : https://udn.epicgames.com/Three/FBXAnimationPipeline.html#Exporting Animations to FBX from Unreal Editor

For the most part this should be just creating a new art package in UnrealEd, then setting up the config files to read the new "BodyPartContent".

I'd have to do the same as you, and just search through the script files -- and I haven't tried to roundup all of the damage values to multiply them, as you are doing. You look to be on the right track. You might look at X2StatusEffects.uc for some of those. Also, X2Effect_Regeneration may need tweaking, since if HP values are 10x, then regeneration would need to be 10x to match.

Flanking bonus crit is now a character stat, so look for it in with the Soldier character stats (and aliens). This amount also varies based on difficulty.

I've had this sort of problem crop up. Usually the problem is an incorrect archetype definition in the weapon template. Less common but still likely is a broken mesh link within the archetype (accessed through UnrealEd).

This is because 'Critical' isn't a damage type, it's a to-hit roll result. Damage types are things like 'Fire', 'Acid', 'Poison', 'Mental', 'Plasma' or 'Ballistic'. Each ability that deals damage will define it's damage type, so the set of possible damage types is defined implicitly.

Well, some of that I can address. All of that will be done in Unreal Editor. The starting page for the UDK 3 documentation on that is here : https://udn.epicgames.com/Three/EditorAndToolsHome.html Textures can be imported and exported into a *.upk file using this. Textures are bound to materials. Materials are applied to meshes. Meshes are configured via archetypes, and archetypes are referenced/configured by code. For replacement, probably the best bet is to copy the existing archetype to a new package by the same name in your mod content folder. That way the package.file path to the archetype will be the same, and the mod version should override the base game version. Alternatively, if it is configured in DefaultContent/XComContent, you could mod that config file to match your new package.file path.