abeclancy

Ahh, makes sense. If the issue is just that only a single Node can be added to your animation tree, I wonder if we can't just modify the animation tree code so that you can have more than one Node. If you want some assistance and don't mind PM linking to your code, you could link it here and see if someone can't find a solution. Or if you want you could PM me and I could take a look and see if I can't help you figure it out.

This looks very cool! I'm curious what you would need in order to have multiple sliders. I haven't touched any sort of asset modifications, so I might just be unaware of the limitations you are dealing with, but it looks like you are adding in a Weight slider just fine, to the UI at least. Where's the value stored? What would you need?

That was added on the March 10th patch.

I think that there might not be anything that we can do to prevent this, as that is kind of the risk of modding. But what we could do is start discussing ways in which life can be made easier for modders. For example, tomorrow I think I might try putting up a Git repo of the SDK SrcOrig files so that people can view what changed in updates. Someone could make a website that mod developers could subscribe to, that would: send emails to them if classes they override are updated; list all mods that override classes that your mod overrides, so you can work with other developers to deal with or prevent conflicts; etc. We could develop a singular core mod that the community can update, so that individual mods don't need to be core in order to make the one modification necessary for their mod to work, and so that certain super-common ideas can be consolidated by the community. For example, I'm working on a replacement Protect the Device mission type, but need to add functionality to the spawn-generating algorithm in the game, and that's the only thing that makes my mod core. I've also written some code to "fix" critical hit chance calculations so that a flashbanged enemy doesn't only land critical hits: a 40% critical chance is 40%, not 100% if a unit's aim is reduced. I can't exactly make these different mods if I want them to be used at the same time, they're both core modifications.

Alright, I've kinda narrowed down the question and testing now that I'm not tired. https://www.dropbox.com/s/ydxokazclc7gx55/TestModConfig.zip?dl=0 This is a core mod that, when the EULA popup appears, prints debug information in the form of a sequence of trace statements to the Launch.log file. It reads the value "TestVar" from the "XComTestModConfig.ini" file, and prints either "ReportVarTrue" or "ReportVarFalse" to the log file, depending on this value. When there is no INI file present, the default value is false based on UnrealScript's rules regarding default values of variables: Boolean defaults to false. The log file has ReportVarFalse. When there is the INI file present in the Mods/TestModConfig/Config directory, and the value is set to "TestVar=true", then the code loads this log file and the string ReportVarTrue is printed. When there is the INI file present in the User's Config directory, but there is no INI file present in the Mod's Config directory, then the code loads the config file from the User's directory and the string ReportVarTrue is printed to the log. When there are both INI files present in the User's Config directory *and* the Mod's Config directory, then the file located in the Mod's Config directory takes precedence over the User's Config directory. Now, I can handle it if the config file doesn't get automatically copied to the User's Config directory, you can just SaveConfig() and it will write the file. But even if I was to do that, it doesn't matter because any customizations in that file just get overwritten by the Mod's Config file. So how am I supposed to include default configuration options in Mods/TestModConfig/Config that get loaded when no User's Config file is present, but not let the Mod's Config file overwrite the User's every time the game loads?

Sounds about right from when I looked at it. Of course there's also native code updates as well that are not in the UCs. For example, targeting priority is now once again highest percentage to lowest percentage. The 2016-03-10 patch bugged it out so your default target was the one with the lowest percentage, and I made a quick-and-dirty mod to reverse it, but it's no longer needed. They fixed their C++ native code so it works correctly now.

Well here's what Amineri has to say about it when asked in another thread: 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. So obviously there is some mechanism that triggers the INI files from the mod directories to be loaded and even saved to the User's Config directory. I guess my question is more of a request for specific information regarding this so I can try and debug why my mod's Config files don't seem to ever be loading, slash a request for people to use that test mod package link so I can confirm that it's not just some environment issue (which has screwed me over in the past).

I'm just going to list the files changed by today's SDK update. I keep copies of the previous SDK on hand and in a repository so that I can compare and update my mods as I need to. If people think this information might be useful for them, I could do something like create a Git repo and put all the SDK files up there. XComGame/Classes: CharacterPoolManager.uc UIAlert.uc UICharacterPool.uc UICustomize.uc UICustomize_Info.uc UICustomize_Menu.uc UICustomize_Props.uc UICustomize_Trait.uc UILoadGame.uc UIMechaListItem.uc UIMouseGuard_RotatePawn.uc UIOptionsPCScreen.uc UIScrollingText.uc UISquadSelect.uc UIText.uc X2BodyPartTemplate.uc X2BodyPartTemplateManager.uc X2DownloadableContentInfo.uc X2ItemTemplate.uc X2SchematicTemplate.uc X2SimpleBodyPartFilter.uc X2TacticalGameRulesetDataStructures.uc XComCharacterCustomization.uc XComCheatManager.uc XComGameState_Unit.uc XComHumanPawn.uc XComOnlineProfileSettingsDataBlob.uc XGCharacterGenerator.uc XGUnit.uc edit: Update on March 27 updated XCom2.exe but nothing else. Don't know what it actually changed. edit: Update on April 7th (or somewhere abouts) that updates XCom2.exe but nothing else.

Seems like Nay. I don't know if either I'm not setting up filtered logs correctly or what, but attempting to pipe logs through the `CHEATMGR doesn't seem to work. Maybe the native code has its own list of allowed filters or something. So, back to square one, and trying to figure out a way to allow some form of logging in a mod's final release build.

So I've been trying to figure out the answer to what sounds like a relatively simple question: When does the mod package's Config/INI files get copied over from the Mod's Config/ directory to the User's Config/ directory, when a mod is first installed or loaded? I ask because, while testing out adding configuration to a core mod that I've been working on, I can't get the XComMyMod.ini file loading or copying over to the User's Config/ directory at all. While debugging the mod, it does seem to load values from this file, but when trying a release build the values don't get loaded and the config file doesn't get copied or saved to the user's Config directory. Now maybe this is just an issue with core modding, or maybe (once again) something on my system isn't being cleared out and I either need to search the filesystem and registry for anything XCOM or Firaxis related and nuke it. But it *looks* like I'm doing everything just like other mods are, it just doesn't seem to want to work. (I already restore steamapps/common/XCOM 2 and XCOM 2 SDK and delete User/Documents/My Games/XCOM 2/XComGame/Config as I test.) So I have a request from anyone on the community: Install the following mod file, wait for the EULA popup to appear in-game (I've rigged my code to execute on that event), then exit the game and report a) whether your User directory contains XComTestModConfig.ini and its contents, and b) the contents of Launch.log (namely the trace statements near the end). Ideally, a) the INI file would be present in your User/Config directory (for me it's not), and/or ideally b) the Launch.log would be full of "ReportVarTrue" functions, which means that it read the value "true" from the INI file. If either (a) or (b) are true, then either I'm doing something incorrectly or I need a new clean environment or something because it's just me. If both (a) and (b) are false, then either I'm doing something incorrectly or INI config file loading in core mods works differently than non-core mods. edit: removed link, SDK updated, new link later (Note: Source code is included. Other than the one call added to the XComOnlineManager or whichever class it was, it's a very simple test.) My current theory is just that core mods, since they are just replacing one of the core packages, don't have their configuration files executed on the first run of the mod. If this is the case, then any core mods that would add a class that has configuration wouldn't be able to count on the configuration file to be loaded or present. This doesn't *seem* accurate though, because mods do have their INI files parsed, so maybe the question is what is the trigger for executing this process, and how can a core mod emulate that? Anyways, the forum's all about discussion and discovery, and I've been wrestling with this for awhile and am getting nowhere, so I don't feel particularly bad about asking about it. If I'm being an idiot about something, let me know what I'm being an idiot about and I'll read it in the morning. For now though I'm going to sleep with the hope of making some more sense of this in the morning.

I did actually manage to find something that might allow me to write log messages to the log files in UnrealScript, regardless of whether the build is a final release build or not. Basically, instead of using `log() or `warn(), the following is used instead. This appears to use a native C++ function to do the actual logging, so it is completely unaffected by the build state of UnrealScript code: `CHEATMGR.WriteToFilteredLogFile("To Hit: " $ ToHitValue, 'XCom_HitRolls');I haven't looked at this in too much depth, but it works in my tests so far, the cheat manager is a part of WorldInfo, and it seems to be a valid object everywhere. Unless someone comes up with a better workaround, this is as good as a solution to logging as I can get. (This is also a very early idea that might be a very bad idea in the long run, I'm just trying to find things in the code to use for logging.) However, do note that using this to do logging means that log messages are not disabled in release builds! Logging always has a performance impact, which is why `log() and `warn() are removed from final release builds in the first place! So, use `log() and `warn() during testing of your mod. Use the `CHEATMGR macro to log errors or information that you KNOW that you will want to have in your final release version. But try to keep the use of these to a minimum, both for performance impact purposes as well as log file size purposes! Yay/Nay?

Also... is the XCom_HitRolls log filter broken? It's filtered to the "Combat" log file along with "XCom_CombatLog", but doesn't show up. "XCom_CombatLog" messages show up in "Combat.log", but "XCom_HitRolls" don't. Doesn't seem to matter how you change the filters, what you suppress or unsuppress (neither are suppressed or unsuppressed by default), `log("TESTING", true, 'XCom_HitRolls'); doesn't log anything, but `log("TESTING", true, 'XCom_CombatLog'); logs perfectly, to both log files in fact. Maybe it's just the XCom_HitRolls logging that isn't working, or maybe I'm just losing my mind. I mean, it's not particularly important for this one log filter to work properly, because I can always test using an empty filter and it works fine. But it doesn't seem to work as intended which makes me worry that when someone releases a massive mod, the logging might not function as they intend, which might be important for things like basic bug reports or debugging.

Found it. From the Unreal documentation page: https://udn.epicgames.com/Three/UnrealScriptPreprocessor.html So, all log messages from UnrealScript will be unable to make it to the log file in final release builds. Fiddlesticks. From https://wiki.beyondunreal.com/Preprocessor : More Fiddlesticks. There doesn't seem to be a good built-in way to log a message to the log file (in particular when doing core mod releases, since non-core mod packages don't have to be cooked). And when you try the following code: LogInternal("this is a test log message");You end up with this compiler error when making final release scripting: Error, Can't access private function 'LogInternal' in 'Object'This is because the final release makes these functions private, so they fail. We can theoretically remove this restriction by, say, removing the "privatization" of WarnInternal of Object.uc so we can at least use `warn() like was mentioned earlier (without the macro), which actually is quite doable in a core mod since there will likely only be a single core mod in use at a time. However it is not exactly pretty, as someone doing an XComGame.upk core mod would also have to overwrite Core.upk to allow for logging. Unfortunately this doesn't seem to work. I didn't try too hard, but log messages still did not seem to be writing to the log file for some reason. I'm guessing that might be part of the whole "don't call it directly" thing that UDK and the wiki pages are all recommending against. So, can't `log() or `warn() unless someone comes up with a way to do so from UnrealScript. I'm going to take a look to see if I can't find a native logging function built-in to the game code somewhere, like "native function LogWithFilter(msg,filtername)", but I doubt I'll find something too useful. And there's a ton of code to comb through.

So I've actually been testing this for awhile, and can't seem to get any `warn() statements to appear in the Launch.log when doing final release building/cooking. If I have a few dozen "ScriptTrace();" calls, I can see those in the log file. But any `log() or `warn() calls both seem to be getting removed, regardless of deleting User\Config files, +Unsuppress=MyLogFilter, what-have-you. Any ideas anybody?

Interesting, and that does explain why a few of the Kismet actions are listed as (!C). Switch for example, does seem to have an internal state, in that you can have it disable outputs after they are used. Gate has an internal state because it can be opened and closed through signals to the gate. For anyone interested, FxsRMcFall's notes are spot-on as usual. In the Kismet view, in the Properties window is a wrench icon that lets you view hidden properties, and the one you are interested in is "Converted For Replay System". If you turn on the converted status for any action (Gate, Switch, etc.), then you can't use any state information in that action node because of... reasons. Seems like it is because the internal values of those actions are not saved, so that when the game is reloaded they are all reset to their initial values. So if you covert any (!C) action to a © action, do not use any internal states of those actions!

Alright, so I think I might have figured out what's been causing me issues. Apparently all of the (!C) (not converted) actions (Switch, Gate, etc) have issues and don't work properly. Seems like they all used to work, then stopped working for some reason. Since I have absolutely no idea how to make non-not-converted actions, my advice to anyone doing map scripting is to actually just go to one of the vanilla mission map files, copy any necessary (!C) actions from there, paste them in to your map, and use them from there. Actually, come to think of it I don't know what the heck "not converted" means anyways, so maybe they were never supposed to really work in the first place.

It's in New Action > Scripting > Current Difficulty. It seems like it doesn't work when you are using the Tactical debug menu's ability to generate missions. Seems like the scripting flow just dies when it encounters the Current Difficulty action, so you can't test how different difficulties affect your mission, and in fact any scripting tied to Rookie/Veteran/Commander/Legend output just doesn't trigger. Anyone back me up or prove me wrong? If this is indeed broken, how do you do scripting based on the difficulty? Is there a Tactical Tag that can be used instead? https://www.dropbox.com/s/dk0dlo16wmd3iwm/kismet-currentdifficulty-nottriggering.jpg?dl=0 (The first tutorial box is shown, the second isn't.)

Had issues with some vague mod data persisting, posted this in another thread, was told maybe you'd be interested:

Sure thing. I (roughly) deleted the following files/directories in their entirety (even my local save files), revalidated through steam, restored XCOM 2 and XCOM 2 SDK from my local copies of them, then rebuilt and it worked. Sounds like that guy in that thread is having problems with the workshop mods though, I'm not sure how related it would be. Worth noting, I didn't delete the workshop mods when I was fixing my issue (I believe that when you are debugging, XCOM 2 doesn't load workshop mods at all, since they don't appear in the launcher mod list). Users/name/AppData/Local/FiraxisUsers/name/AppData/Roaming/FiraxisUsers/name/Documents/Firaxis ModBuddyUsers/name/AppData/Local/CrashDumps/XCom2.exe.*.dmpUsers/name/AppData/Local/Microsoft/Windows/WER/ReportArchive/AppCrash_XCom2.exe_*Users/name/AppData/Local/Microsoft/Windows/WER/ReportArchive/AppHang_XCom2.exe_*Users/name/Documents/My Games/XCOM2Users/name/Documents/Visual Studio 2013/Settings/XCOM ModBuddyI know that the game's workshop mods are stored somewhere in steamapps\workshop (I think workshop\content\268500), maybe unsubscribing from all mods, deleting that directory, then revalidating XCOM through steam would help. I'll make a post there, but it's been 6 days since his last posted, so who knows if he's still interested in solving it.

It's more a matter of "the example is vetted and should work, and if it doesn't something is wrong". Anyways, I did manage to fix this issue. I think that there might be something outside of the User\Config, steamapps\XCOM 2, and steamapps\XCOM 2 SDK directories that may persist through modding. I ended up searching the entire C:\ drive for any mention of "Firaxis" or "XCOM", deleting files and directories in several places (though mostly in my User\ directory and the Temp directories). And it seems to work now, the mission is generating with just the bomb objective and not 6 additional ones. Guess the lesson here is, there is more than just the User\Config directory that persists when modding, so you might have to dig and delete all Firaxis/XCOM directories in your User directory to get things working properly.

Thanks for taking a look at it! Kinda not what I had hoped for actually, because it means that something somewhere in my system isn't being cleaned out properly, and I have no idea what it is. Guess I'll be doing a lot of scanning through my hard drive to find anything XCOM 2 related and nuking it. Something outside of user Config, XCOM 2 and XCOM 2 SDK. The Bomb Disposal example was just entirely built-in, ModBuddy's example project that everyone has.

Hey there, hopefully someone more knowledgeable with the missions systems in XCOM 2 can jump in and either confirm/deny this. Here's the short version: Creating a new mission type, aliasing an existing mission type, and trying to spawn a mission with a single objective actually spawns about 6 objectives, even though the SpawnMissionObjectivesForInfo() call GatherSpawnObjectives() yields only a single OSP object. Rebuild the map generation by changing just the objective parcel, so that the Tactical debug menu rebuilds only the objective parcel, makes it work and only spawns a single objective. Here's an example I did using the actual Bomb Disposal example mission, deleting Users\Documents\My Games\XCOM 2\Config, reverting the XCOM 2 and XCOM 2 SDK steam directories, and building and using only that example mission mod: https://www.dropbox.com/s/pr9jwao3sr4okvr/BombDisposalIssue.jpg?dl=0 The bomb can be seen under the green arrow icon, but there are also a bunch of transmitters from the Protect Device mission type. Now, I have been working on a mod that deals with Protect Device missions, but this is occurring after I've deleted my local config and reverted the steam directories. This makes me think that there is actually an issue with the mission generation. If I change my mod to instead of creating a new mission type, remove the existing Protect Device templates and arr* from XComMissions.ini and just straight-up replacing them, then it works fine. But trying to create a new mission type aliased to another mission type seems to make this happen (based on the fact that my mod breaks when I attempt it, and the Bomb Disposal seems to do this by default). And the weird thing is that the objective generation does work properly, but only if you forcibly have the Tactical menu recreate the objective parcel! If it was an issue with my own system, then shouldn't the issue still persist through a new objective parcel? I've linked the Bomb Disposal and my own mod (heavily stripped down) for someone to hopefully take a look at. At the very least, try building in ModBuddy on your own systems, launch Start Debugging, and try to use the Tactical menu to just run the mission and see what happens with the objectives. If it works fine for you, then there's obviously something somewhere that I need to delete or reset, some additional location for config files or some such thing that I am obviously missing. https://www.dropbox.com/s/le46hp4q0ituxwo/ExampleMission.zip?dl=0 https://www.dropbox.com/s/8ewkn32ph55n769/ARCDefendTheDevice.zip?dl=0 Could really use someone to verify if this works or fails for them!

Figured it out. Turns out there's a reason why all the vanilla UMAPs in the game have the prefix "Obj_" on them. If your UMAP has the same name as the mission name you are creating, it will refuse to load. Attempting to make the debug menu's Tactical map generator make a mission will cause it to hang, and a missing ULevel error appear in your Launch.log file. So, someone can add that to a list of things to watch out for when modding. Here's an example from the vanilla mission type Protect Device. Notice the "Obj_" prefix on the MapNames, which is the name of the corresponding UMAP file. -arrMissions=(MissionName="ProtectDevice", sType="ProtectDevice", \\ MissionFamily="ProtectDevice", \\ MapNames[0]="Obj_ProtectDevice", \\The more you know!

sigh UMAPs at least load in the Editor, but only when I revert the entire XCOM 2 SDK directory tree. Apparently some part of modding XComGame core packages is causing the editor (and the game itself) to freak out and either crash or hang on level generation respectively, even when the modded files are completely removed and unloaded. The editor crashes with assertion failures and no World.TheWorld error message, and the game complains about no ULevel object in the mission script package. At the very least, my UMAP is loadable and I can always save it out to another file, copy the scripting to another file, or what-have-you. I'm yet to figure out exactly what the issue is, but once I do I will update this thread with what I find out, unless someone else knows additional information regarding this and posts first.

Just a note to anyone who seems to have a corrupted custom UMAP file that isn't loading in the XCOM 2 Editor (ModBuddy > Tools) or the XCOM 2 game itself. If your Editor is crashing when attempting to load the file, or the XCOM 2 game isn't properly generating a mission map for your level/missions (and you get a message in your Launch.log indicating that a ULevel object can't be found), just try deleting the \steamapps\common\XCOM 2 and \XCOM 2 SDK directories and redownloading or restoring the directories. Might not work for you, but it did for me. Must have messed up my local directories at some point, preventing the file from working properly. edit: Could have also been fixed by deleting the local XCom*.ini files in my User directory. Try both. edit edit: Well, XCOM's still having trouble with my level, but it loads in the Editor at least! You should probably also make backups of your UMAPs, just in case something does go wrong with it.