Amineri

There's nothing magical about the 0.08 seconds number. In fact, I think I wanted a longer time, but JC exported from Blender with that time-line, so we called it "good enough". The other option is to copy the full-body animation of the soldier, and attach the sound in there. This works for single-shot weapons (like Laser Sniper Rifle), but we didn't use that generally because most of our lasers use multiple shots, with multiple projectiles, and we wanted a sound for each projectile. I believe the base-game Cannon_CV does something similar -- it doesn't have a sound/projectile, but instead a single "buzz" sound that plays for the entire firing duration.

The assumed framerate is 30 FPS, so 0.033 seconds is basically the length of one frame. So if/when framerate drops below 30, that sounds can get skipped over ... a bit of weirdness from Unreal Engine. During our initial testing we were either running with low graphics settings or on beefy machines, so it didn't get caught until QA was testing it. We ended up exporting and extending/re-importing the animations out to 0.08 seconds, which is good to 12.5 FPS. Below that the game is pretty unplayable anyhow, and we figure that not playing sounds is the least of concerns.

I guess my checklist would be something like this : 1) Does the SoundWaveNode play in UnrealEd ? 2) Does the SoundCue play in UnrealEd ? 3) Does the sound play when playing animation in UnrealEd? 4) With graphics settings at min (for max framerate), does sound play in game ? 5) Raise graphics settings, use \slomo 1.x command to stress game until sound no longer plays #5 is to give an idea of how much margin there is, so that people with slower systems won't get missing sounds.

Back on sound topic, another thing to check is that the SoundCue is part of the correct "Sound Class". This is shown underneath the SoundCue, and can be changed by right-clicking on the SoundCue in the Content Browser, and selecting : Sound Classes / Sound FX. Grouping new weapon sounds into Sound FX class allows their volume to be controlled properly by the Audio Sound Effect Volume slider.

Further, the WWise toolset only allows a single project per game, adding in new WWise sounds is extra difficult. We did explore this option a bit, but the obstacles are high. You are correct that the X2UnifiedProjectileArchetype isn't currently set up for SoundCues -- only akEvents allowed.

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: