Amineri

defaultproperties are a little bit funny. They aren't really "proper" code. I mean, you can choose to leave off the terminating ; on a line and the compile and operate just fine. So I guess in hindsight it's not surprising that they are sensitive to line-feeds.

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.

I hadn't noticed this, and the OfficerPack has a UITacticalHUD screen listener. Which other UIScreens have you noticed getting picked up by it?

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 modIn 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 longerXComGame -- 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 : 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.

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 :

Building but non executing code is generally a normal step in the process of building a mod ^_^. At least it's not causing the game to CTD, which is a frequent occurrence for me... So yes, if you want more concrete feedback, you'll likely need to post the specific code so we can try and pick apart why it isn't functioning as expected.

In my experience this is the case. Users have reported, and I have confirmed, that disabling the Officer mod prior to ending a Tactical mission which would have triggered the CTD prevents it from occurring. Alternatively, adding the gamestate component to the transient gamestate list also prevents the CTD. The downside is that it (in my case) interferes with normal operation of the mod. When I tried to search the History for the offending objects, I was unable to find them. I suspect this is because they are components of a gamestate that has been obliterated, and the IterateByClass native accessor I used couldn't handle that. When I used the same IterateByClass method to search just after dismissing a unit (when the unit has not been obliterated, only had its bRemoved flag set), I was able to find the component gamestate, mark it for removal, and unlink it. In short, I haven't figured out a way to recover a tactical save that is about to break, short of draconian measure that involve breaking/uninstalling the mod.

Another method you can use to clean up after effect components is what we used for the effect components in officer pack. XComGameState_Effect is always cleaned up after a tactical mission because of its inclusion in TransientTacticalClasses. So, for OfficerPack, I've included an XComGame.ini config with the following : [XComGame.XComGameInfo] ;Transient tactical classes specify objects that should be set as removed in the history upon leaving a tactical session +TransientTacticalClassNames=XComGameState_Effect_FocusFire +TransientTacticalClassNames=XComGameState_Effect_Scavenger +TransientTacticalClassNames=XComGameState_Effect_Collector If you look in DefaultGame.ini, you'll see that XComGameState_Effect is also on the list, which is units don't clean up after themselves post-mission. For debugging purposes, I'd also added the XComGameState_Unit_LWOfficer component as a TransientTacticalClassNames object, and this prevented the CTD on switch from tactical to strategy maps, which indicated the same root cause.

Yes, posting it there was an embarrassing mistake ... :sweat:

I don't think I'd ever done anything special. I just make sure to save the package in the Mod Projects folder (not under XCom 2 or XCom 2 SDK folder).

Passive abilities are still abilities in XCOM 2. The distinction between "passive perks" and "active abilities" from XCOM EU no longer applies. The primary difference between passive abilities and active ones is just what the trigger is.

Okay, I think I see the issue. There's sort of two problems. The first is that you are attempting to directly manipulate the current GameState in the history, instead of submitting a delta state. This is technically valid, but I don't think it's the "approved" way to interface with the History. For submitting changes to the history in X2DownloadableContentInfo I typically use the following boilerplate: NewGameState = class'XComGameStateContext_ChangeContainer'.static.CreateChangeState("Descriptive Text"); stateTech = XComGameState_Tech(NewGameState.CreateStateObject(class'XComGameState_Tech')); NewGameState.AddStateObject(stateTech); << do stuff here>> History.AddGameStateToHistory(NewGameState); In other places, I'll replace the last line with `GAMERULES.SubmitGameState(NewGameState); ----------------- Second, this approach won't generally work in the InstallNewCampaign case. The StartState is being passed for a reason -- it's intended that the mod add things to/change things in the supplied StartState, not work from the History. The StartState being supplied is what is being created, and has not yet been submitted. So in this case, your code would look more like : stateTech = XComGameState_Tech(StartState.CreateStateObject(class'XComGameState_Tech')); stateTech.OnCreation(techMec); StartState.AddStateObject(stateTech); Where StartState is the GameState being passed through InstallNewCampaign.

When you first create a package, it shows up under "New". Then you save it. When you close UnrealEd and re-open your package, it should then show up under "External". That's how it's always worked for me.

Another thing to keep in mind is that Unreal Engine triggers the config merging process based on file date/timestamps. This can result in the merged versions in My Games not matching the expected config state (e.g. removing a config file won't trigger a re-merge). Like in EU/EW, a way to force a config re-merge is to delete all of the "XCom" prefixed config files in the My Games / XCOM 2 folder, which will force the game to re-build/re-merge them on next launch.

Abilities can be added to characters or items. When added to items, they generally use animations for visualization tied to that item (unless overridden). So, for example, in the Muton Centurion template code, in the X2CharacterTemplate definition we have : CharTemplate.Abilities.AddItem('CounterattackPreparation'); CharTemplate.Abilities.AddItem('CounterattackDescription'); CharTemplate.Abilities.AddItem('WarCry'); CharTemplate.Abilities.AddItem('Beastmaster'); //CharTemplate.Abilities.AddItem('BayonetCharge'); // moved to X2Item_MutonM2.CreateTemplate_MutonM2_MeleeAttack so that proper animation plays

Hmm, this is mysterious, since I've got stuff that overrides multiple classes in a single mod, and is working without this issue. My next step would be to add `LOG calls in your override code as another check to make sure that it's not actually overriding.

One other quick question ... what are you naming your config file in your mod? The correct answer is : XComGameData_CharacterStats.ini

Yes, I've had that problem, too. Not only HP, but maximum action points per turn are configured stats. So if you don't set the difficulty variant stats, you end up with a unit with 0 HP, 0 Action points, and 0 visibility range. :smile: The "trick" is that the game automatically creates three new templates, appended with the difficulty. So for the Muton Centurion (which I used the name 'MutonM2'), the difficulty variant code automatically creates 4 difficulty variant templates called 'MutonM2_Diff_0', 'MutonM2_Diff_1', 'MutonM2_Diff_2', 'MutonM2_Diff_3'. This happens in X2DataSet.CreateDifficultyVariantsForTemplate : for( DifficultyIndex = `MIN_DIFFICULTY_INDEX; DifficultyIndex <= `MAX_DIFFICULTY_INDEX; ++DifficultyIndex ) { NewTemplateName = BaseTemplate.DataName $ "_Diff_" $ DifficultyIndex; NewTemplate = new(None, NewTemplateName) BaseTemplate.Class (BaseTemplate); NewTemplate.SetDifficulty(DifficultyIndex); NewTemplates.AddItem(NewTemplate); } What's really fun is that you can't actually directly access these difficulty variants -- instead, the native code looks up the current difficulty and retrieves the one for the current difficulty. So when you request 'MutonM2' template, you get one of the difficulty variants, based on the difficulty setting in the CampaignSettings. However, to configure the difficulty variants isn't too tough : Note that you don't have to fully specify every change from the base, only what's different. Each variant should be starting off based on the default stats. Note that the above doesn't change anything for Diff_0 (Rookie/Easy). The base stats have to be specified in the "base" template name, that is in : [MutonM2 X2CharacterTemplate] +CharacterBaseStats[eStat_ActionPoints]=2 +CharacterBaseStats[eStat_AlertLevel]=2 +CharacterBaseStats[eStat_ArmorChance]=100 +CharacterBaseStats[eStat_ArmorMitigation]=2 ; +1 compared to muton +CharacterBaseStats[eStat_ArmorPiercing]=1 ; +1 compared to muton +CharacterBaseStats[eStat_CritChance]=0 +CharacterBaseStats[eStat_Defense]=10 +CharacterBaseStats[eStat_Dodge]=0 +CharacterBaseStats[eStat_HP]=12 ; + 4 compared to muton +CharacterBaseStats[eStat_Mobility]=12 +CharacterBaseStats[eStat_Offense]=75 +CharacterBaseStats[eStat_PsiOffense]=0 +CharacterBaseStats[eStat_ReserveActionPoints]=0 +CharacterBaseStats[eStat_SightRadius]=27 +CharacterBaseStats[eStat_DetectionRadius]=12 +CharacterBaseStats[eStat_UtilityItems]=1 +CharacterBaseStats[eStat_Will]=50 +CharacterBaseStats[eStat_HackDefense]=0 +CharacterBaseStats[eStat_FlankingCritChance]=33 +CharacterBaseStats[eStat_Strength]=100 ... ...

Try not duplicating the header... that is, try : [Engine.Engine] +ModClassOverrides=(BaseGameClass="UIDropShipBriefing_EndMission", ModClass="Apple") +ModClassOverrides=(BaseGameClass="UIDropShipBriefing_MissionStart", ModClass="Banana")

What you are suggesting should work. We did this when doing initial testing of the localizations for the release-day mods. You should note that if you create a "Text" file in ModBuddy, it will create by default a UTF-8 encoded text file. However, properly speaking the localization text files should be encoded as UCS-2 Little Endian. This doesn't matter for English (.int), but it does matter for other languages.

Can you paste in the config file where you are defining the overrides? It could be something in there...

I'm not quite able to follow what's happening here, since you didn't post the code in your X2DownloadableContentInfo child class. Your error says But I don't see any reference to such a variable in the posted code. However, you should note that OnLoadedSaveGame isn't supposed to trigger for every load, only the first time your mod is loaded for a particular save. This is the main reason I don't use this for changing templates with difficulty variants.

It could be that your override is working, but that the data set in InitScreen is being overwritten in the Update function in that latter.

Whoopsie, I meant to post this over in Mod Talk ... :sweat:

Yes, that stuff is always fun, right? I've done the same, agonized over code over and over, only to find some little config error that was causing the whole problem... Anyhow, glad to see you back modding Yzaxtol :)