abeclancy

Nice! Yeah, looking at the updated SDK it's clear that only the UITacticalHUD and *_AbilityContainer files changed. It's difficult comparing UPK files unless you know what you're looking for, I should keep copies of the old UPKs in case it's needed for some reason or another. Turns out I didn't keep them previously, and comparing an official build UPK to one that I made is just a plain old mess.

Took a look with your instructions, worked just fine. There are other changes to other .uc files, but unfortunately it's hard to determine exactly where the changes are because the official UPK files contain comments and logging calls, while the ones that I cooked do not. It's 2300+ files that are different, so either someone's going to have to look through them all individually or I need to figure out how to either get a cooked package with comments/cpptext/logging functions intact or strip them out of the official packages.

I have a repository of the previous SDK versions, so I already have both XComGame packages. How would I go about decompressing and comparing them?

Nice sleuthing! But, poop. Was there just the one change in the UPK, or are there significant changes? It's quite possible that they don't consider the missing scripts that important, and they might not push an update just to fill in the missing files. It might be worth it to compile a list of all the changes if there's no update soon.

Just thought I'd make a little post regarding the couple of most recent XCOM 2 patches. The patch from November 8th made numerous changes to many of the SDK .uc files regarding controller stuff, making information more visible, button prompts, etc. Anyone overriding core packages would need to compare against the approximately 264 updated files. But the BIG thing from that patch is that mod loading was finally fixed after being broken for over 4 months. Mods can override UPK files in the game's /mods/ directory, AND can override UPK files when downloaded via the Steam Workshop. The latter was promised in the June 2016 patch but never correctly functioned, and the former was broken in that same patch. It looks like there was another XCOM 2 patch on November 15th, but as far as I can tell this one does not change any of the UC files. This looks like a pure EXE-related patch.

Pardon the terrible MS Paint skills, but this is kind of what I hope the menu looking like eventually, to allow for a bunch of information to be presented to the user: https://www.dropbox.com/s/xaewlylebagups8/mcm-example-tooltip-icons.png?dl=0 Yellow question mark icons (like the game uses for describing soldier skills in detail) would open a right-side pane. The mod list on the left could be used by the mod to display information like the mod author, license, etc. The option list on the right can be used to display a long tooltip string, examples, maybe even a format for including descriptive images in the game would be nice? Something that would allow for a cropped screenshot to be displayed that a mod can use to show what an option does as well as describe it with text.

Ahhh, that makes much more sense, and explains a couple of peculiar issues that seem to have been hinted at via various online discussions regarding certain mods not working. Hopefully Firaxis does a patch in a few days, instead of waiting for their next DLC release. If I'm not mistaken, Shen's Gift is the last of the "promised & scheduled" DLC, so maybe we'll see some faster turnarounds now. Guess for the time being, core mods just need to edit their installation instructions and continue on as normal. Edit: Can confirm, XComGame/Mods doesn't work for overriding the XComGame.upk packages, even though it used to before the June 30th patch. Manually overwriting the XComGame/CookedPCConsole still works, so Nexus mods will just have to do this, just like the Workshop mods have had to do up until this point.

Took a look around, didn't really run across anyone else discussing this. I've sent out a few messages about it, and if I get a response I'll update it here, but if anyone has a link to a source it would be appreciated.

Yeah, I mean, I know how to get it working normally, I've been doing that for some time, as have other modders who are taking advantage of XComGame.upk overrides. Kinda wrote the forum tutorial on it: https://forums.nexusmods.com/index.php?/topic/3868395-highlander-mods-modding-native-classes-and-core-packages-xcomgameupk-etc/ But when you say "there is a bug" do you mean a new bug as of the June 30th patch that renders their addition of this feature unusable? Or do you mean from day one, February 2016, that it never worked in the first place? Do you have some source on this, that the June 30th patch is bugged and doesn't work? In their latest patch they said that you don't need to do this copy/overwrite process anymore, that it should "just work" from the mod directory instead: Updates to allow Steam Workshop DLC to be enumerated before native script packages are loaded. Will allow mods that override XComGame.upk to work through Steam Workshop

Question: Has anyone been able to get the XComGame.upk override working though the Steam Workshop yet? Putting the XComGame.upk (and uncompressed_size file) in both the Workshop mod directory's Scripts\ and CookedPCConsole\ folders doesn't work. I've tried recompiling a bunch of times, trying different changes to directory structure, nothing works. Is this "actually" working for anyone?

I'll have to do a bunch of mod updating today and tomorrow to get things working, but allowing the XComGame.upk to be replaceable is very nice! I'll definitely take advantage of this as soon as I am able. I'm a bit curious if this also works with Core.upk or other base packages (as I currently make a small modification to that package in order to do some logging stuff, so I can always do without it). It's also interesting to see that they deprecated X2AbilityMultiTarget_SoldierBonusRadius and the Cone, Cylinder, and Line versions so that they can allow for extending radius in a generic fashion. Curious if this allows for more than a single soldier "ability" or not, so this might make my own modifications obsolete. Fixing proximity mines not blowing up properly is nice, though too late for my current campaign. Makes the item usable once again.

I've been making a mod over the past while, and I've just made an update that (among other things) allows people to specify changes to the sizes of area-of-effect abilities in the game, based on whether the shooter has an ability or effect. For example, if you wanted to give PSI troopers an ability called "Focus" (say from a new PSI tree) that increases the AOE of Void Rift, you can do that with just a few lines of code. And if you wanted to reduce the AOE of Void Rift if the trooper is poisoned, you can do that too. Or if you wanted to make a suicidal-unit that self-destructs and has a larger AOE blast if it is on fire, you can do that. Or increase the AOE sizes of heavy weapons. Etc etc. Might not be all that helpful to too many people, but I saw a deficit and coded a semi-working solution for it. It's a bit hacky, but I couldn't figure out a simpler way of accomplishing it. Should be mostly transparent to anyone using it though. http://www.nexusmods.com/xcom2/mods/569/? The TLDR for why I made this, was because I wanted to fix the critical chance of heavy weapons and make them by affected by Biggest Booms and Volatile Mix. Volatile Mix technically does give a radius bonus to grenades, it's just that the bonus is set to zero. I wanted to apply the bonus to the heavy weapons, so that if someone does make the bonus non-zero, it will affect them (Cone, Radius, Line, and Cylinder).

Not sure what your status on this is, and not sure if this helps at all. But I've noticed in the past that string localization doesn't work unless the class is also loading config variables. I have a proper description of it here: https://forums.nexusmods.com/index.php?/topic/3868395-highlander-mods-modding-native-classes-and-core-packages-xcomgameupk-etc/

If you're still having issues with "VERSION" and the compiler complaining about case, try just changing the variable name to something else. Unrealscript does some pretty weird and opaque things regarding naming collisions on variables that it auto-creates, such as "ReturnValue". Try "CONFIG_VERSION" or "SUPPRESSION_CONFIG_VERSION" or something and see if that gets rid of that error.

Kregano I'm unsure as to your exact issue. You're not entirely clear as to what the problem actually is (all you say is "it won't work"). The code you pasted is difficult to parse due to the wild spacing. And you haven't included any information as to what this has to do with the MCM mod. DownloadableContentInfo doesn't have anything to do with MCM.

Technically I don't believe there's any reason why you couldn't write to the savefile with MCM: It doesn't handle the config/save writing on behalf of mods that use it (unless there's been an update in the past week or so). Right now in my own mod, when I get an event that the options menu is loaded, I just pull the options from the config file and build any necessary checkboxes, buttons, dropdowns, etc. When a save event is sent, I write the options to the config file. If in a tactical or strategy layer, if I wanted to I could load data from the current save and add those options to the menu, and mix-and-match at will. The only reason why I'm not doing that currently is just for simplicity's sake so I can focus on other features. I suppose what someone could do, is write a mod that abstracts away the saving and loading of data from config files or the savefile. But saving to/loading from a config file is easy (just make a class with config variables and call Save), and structs can't really be abstracted away that easily (I know array.Find() can use a variable property name of a struct, but I don't think anything else can reference struct properties dynamically like that).

Ahh. You should be looking at "UnrealScript", as that is the language of this modding. This website is good reference material for UnrealScript 3: https://udn.epicgames.com/Three/UnrealScriptFunctions.html There's some fundamental misunderstandings you have with the code you provided. For example, bInfiniteItem is a boolean itself. You can test it by `if (WeaponTemplate.bInfiniteItem)`, and change it via `WeaponTemplate.bInfiniteItem = true;`. It might help if you explain in detail what you are trying to accomplish with this code.

Your code doesn't make any sense. UpdateTemplate() doesn't have a return type, yet the code contains "return true" and "return false" in the loops. It is difficult to read due to the wild spacing and bracketing. The code in that post (14) shouldn't compile: UpdateTemplate is an invalid function.

X2TacticalGameRuleset.StartStateSpawnAliens() is where the alien pods are actually added to the mission. I've modified this a bit in my own highlander-type mod to add PreSpawnAlienPods and PostSpawnAlienPods events that I listen to and make small modifications to the gamedata in order to adjust some parameters for the alien pod spawning algorithm. Basically adjusting where the pods think the objective is located so that they can have a valid spawn location, otherwise the pods will literally fail to spawn in the level. `XEVENTMGR.TriggerEvent('PreSpawningAlienPods', BattleData, SpawnManager, None); SpawnManager.SpawnAllAliens(ForceLevel, AlertLevel, StartState, MissionSiteState); `XEVENTMGR.TriggerEvent('PostSpawningAlienPods', BattleData, SpawnManager, None);The MissionSiteState contains the selected encounter data. Looks like this gets populated with pods during XComGameState_MissionSite.CacheSelectedMissionData(), which calls the native function XComAISpawnManager.SelectSpawnGroup(). Anywhere in this chain the selected pods could be modified. If the community wants greater customization, it should be quite doable. I think the only question is how much effort it will take, whether it's possible to just edit the selected mission encounters before the alien pod generation, or whether the pods need to be modified after generation. (Ideally before, because who knows exactly what the pod generation native functions actually DO.) Well, the other question would be what format does the extra customizability come in? What's everybody's tldr on what they would ideally like to see?

Well that makes much more sense, I was worried that you were implying that the codebase itself was changing! But you were specifically talking about just the INI files themselves. Interestingly, "EncounterBuckets" doesn't seem to be used in the UC code, so it seems as though it is entirely native. Makes it difficult to know how it is used without testing.

I'm not sure if this is accurate. I do not have the DLC installed but I have "EncounterBuckets" in DefaultMissions and an "EncounterBucket" struct in XGGameData. I'm pretty sure there's only one codebase, otherwise every time they release a new DLC the number of different codebase versions would increase exponentially? That would be incredibly un-mod-friendly. I mean, it makes sense if mods are broken and need to be updated, but having separate codebases for each DLC combination would be a ridiculously horrendous idea. The SDK also doesn't care what mods you have installed or not I'm pretty sure, and there's only one SrcOrig as far as I know. If someone with the DLC bought and installed wants to force update their SDK installation and PM me their SrcOrig, I'll compare against what I have.

Anyone else experiencing an issue where the over-the-shoulder camera on a mind-controlled unit targeting another unit doesn't work? From what I can tell, this bug seems to only manifest when the game packages are built in final-release mode, as the camera seems to work fine when in a debug build mode. Can anyone confirm this (or at least the bug's presence)? I think I might be losing my mind trying to figure this out, because I can only replicate this without my debug tools, and I would really not like it if this bug is only present on my system for whatever reason (it's happened before). For the record, I do not have the DLC purchased or installed, and here's a couple file sizes and MD5 sums of the likely files involved: XCom2.exe 38,677,272 bytes, file version 1.0.0.53767, MD5 a4571709b88eb1bf10cbd9de0319146e XComGame.upk 11,357,383 bytes, MD5 28e033532dceeda2b7a3afcc3705f302

Filtered logs don't always work unless you unsuppress them first via a command call. I personally gave up on trying to get filtered logs working, but if someone has a working example of a new filtered log I'd love to actually be able to use one. But that's half besides the point anyways. I'm worried that there is issues with the vanilla version cause of all the log messages. (Edit: Spelling and grammar sucks. I'm in the middle of playing Rocket League. Sorry.)

@Amineri, I'm noticing similar issues too, but I don't have the DLC. An absolute metric s#*!-ton of ScriptWarnings about accessing None, everything from XComGameStateVisualizationMgr, XComHumanPawn, UIPawnMgr, UIPauseMenu... tons of "[0023.65] Warning: Property m_CharTemplate of XComGameState_Unit is not serializable for package: FArchive" warnings, "EventID: TacticalGameEnd BAD SOURCE OBJECT! A listener was set that is not referenced by the History object"... Do you think there there is some issue with the current build of the game that is causing so many of these errors? The game actually does seem to be functional...

@Zyxpsilon Alternatively, it's just pulling the class templates and using the icon data from them. Can you just edit the template icons on-the-fly? RankIcons is just a localized array<string>. You could try just replacing the data on load by modifying the template, or maybe adding in a new localization file that might be able to replace the icons without requiring code to do so?