bunnytrain

Yup, this seems to be a widespread problem. I have it too. I've heard that starting ModBuddy as an administrator fixes the problem. I wasn't willing to do that, so instead I just run StartDebugging.bat from the Binaries/Win64/Launcher folder.

Yup! That's basically what I had in mind. The problem with doing that specific thing is that the widgets (especially sliders and dropdowns) are already very width-constrained on space for the label. I might try to show that icon on mouse-over or something in order to preserve the extra 2-3 characters of horizontal space. Or maybe I'll just expand the entire window's width by the corresponding amount and remove the soldier mesh like you at one point suggested.

^ Yup. Bronzeman Mode is going to get a rewrite to fix some compatibility things as well. Edit for 7/7/2016: Still WIP. Haven't had access to the mod SDK since the DLC release, until today. Edit for 7/11/2016: Bronzeman Mode is now updated for proper DLC UI support. Steam Workshop version is up to date, Nexus version will follow in a few days.

Dragon32: Yeah, the tooltip text issue is an annoying thorn in my side. The reason for the problem is that the built-in text tooltips were never meant to display extensive text, so in order to accommodate more sophisticated tooltips I will probably have to replace the existing tooltip system. I'll have to admit, that's relatively low on my list of priorities compared to a few other things I have in mind. What I might do is add an info button feature to let you pop up an explanatory dialog. Much more conducive towards extended descriptions. Kregano: Some personal and professional things got in the way of me putting in more quality time working on mods in general. I'm hoping to get in more time over the next few weeks to finish some much-needed improvements. Expandable settings groups and dynamically adding/removing settings is near the top of that list, which didn't get implemented in the past just due to some UI quirks I just didn't want to deal with on the road to initial release.

Since it looks like you're adding a new class, I'd try to put it in a separate, unique INI file without the + signs. Mod behavior when trying to read from the game's default INI files tends to be a bit weird.

I'm guessing there's some other set of interactions thresholded by getting the right values into the class defaults and calling StaticSaveConfig at the right moment. The way I'd debug it is to log the variables where you're storing the values that MCM spits out, and make sure that inside the "save handler" you're logging the correct values and also saving them correctly.

Based on your code, both SuppressionWeaponsSettings and SuppressionWEaponsListener use "config(SuppressionWeapons)". What happens if you require that they use different files? Second, did you try inserting log statements into the beginning of "LoadSavedSettingsInitial()" to see if that function gets called? If It's getting called but doesn't seem to be showing results, then perhaps there's something wrong with trying to save the results to file. If it's not actually getting called, then I wonder what "class 'SuppressionWeaponsSettings'.static.LoadSavedSettingsInitial();" is actually doing, since you're not getting a compiler error. Just some ideas. If the behavior is the same whether MCM is installed or not, then chances are it's not MCM, it's something in your code that's mishandling config variables. Granted, handling config variables is also the most complicated part.

So there's theory and practice. In theory, MCM doesn't actually touch any INI handling code, other than the part where those version handling macros get compiled into your mod when you build it in ModBuddy, MCM should have pretty much nothing to do with problems initially creating the INI file. My best guess is that there may be something breaking when you try to combine multiple classes into the same INI file. What happens if you try to put the FirstRun entry for SuppressionWeaponsListener into a different INI file? Separately, does your logging tell you that the contents of "class 'SuppressionWeaponsSettings'.static.LoadSavedSettingsInitial();" is running? If that contents is actually running and is actually calling StaticSaveConfig() on the defaults, and if it's still failing even when FirstRun is written into some other INI file, then we're onto some more mysterious problem in how INI handling works, but let's rule out all of the low hanging fruit first.

Mods that take content from one game and inject it into another game occupy a gray area of US copyright law. It's not necessarily fair use. It's certainly within any content creator's rights (in this case the Planetside publisher/studio) to issue a DMCA takedown for this kind of thing. I think your expectations might be a bit skewed. Just because nobody has filed a DMCA takedown on the Halo or Titanfall content mods doesn't mean that they're legally fine. It only means that nobody has decided to make an issue of it. US law, especially copyright law, mostly only kicks in when somebody has a problem with what you're doing. What you're seeing is that somebody out there has decided that they're not okay with the content crossover that (might) be using assets ripped from their game specifically. So... 1. It's not clearly fair use. 2. The assumption that it didn't rip assets from Planetside might not be correct. 3. DMCA specifically requires a quick takedown, and as the website hosting the content, Nexus is legally obligated to follow a specific script that includes taking down the content quickly. The mod author has the right to contest the takedown. It's not great for people who were using the mod, but as far as US copyright law goes, this is all by the book, and the mod/author are not clearly in the right on this one.

Sorry for the delayed response, I had to step away from modding for a few days to deal with some other things. I'm still not sure what you mean by the warning messages, but if those are warning messages that your code pops up (because MCM doesn't pop up any warning messages itself) then it sounds like something where your code just needs to make sure that you don't show both messages. So you're saying that your code works fine if you don't include the if statement and just type in those four "AddAbilities" lines literally. But when you do use the if statement, those "AddAbilities" lines never seem to be called? That would point to there being something wrong with your if condition, and the most likely reason your if condition is failing is that "class'SuppressionWeaponsSettings'.default.RIFLE_ENABLED" is always evaluating to "false". The most likely reason that would happen is that for whatever reason the ini file isn't actually getting generated correctly or isn't saving the values correctly. Maybe insert this line to check whether you're ever actually entering the interior of the if statement: if (class'SuppressionWeaponsSettings'.default.RIFLE_ENABLED == true) { `log("Base game rifles have Suppression!"); AddAbilities('AssaultRifle_CV', 'Suppression'); AddAbilities('AssaultRifle_MG', 'Suppression'); AddAbilities('AssaultRifle_BM', 'Suppression'); AddAbilities('AssaultRifle_Central', 'Suppression'); } else { `log("Suppression on base game rifles disabled."); } If it's logging that second message all of the time, I would try checking the INI file for SuppressionWeaponsSettings to see if the RIFLE_ENABLED setting is actually set to true right after you generate that INI file for the first time.

Which warnings about setting a default .ini? I wasn't aware of this bug so I'm not quite sure what you mean by it. Separately, which hook do you mean for the function that's supposed to be adding Suppression to the guns? Do you mean code that runs to register templates?

Hey Kregano! First of all, thanks for trying to use MCM! I took a pass through the code that you showed, and it looks like you're trying to implement a system where default settings get pushed into an INI file you want to save into the My Games folder on an initial run? This is a generally brittle approach with a bunch of pitfalls, so I can either try to help you get that working, or I can suggest my own preferred approach that generally lets you avoid needing a "first run". Tradeoff is a bit more complexity in your template loader. I only read your code once, so I might be missing something, but what is the purpose of "SuppressionWeaponsListener "? It seems like it's supposed to execute exactly once, the first time the mod runs, right? In that case, it might be missing a key line in SuppressionWeaponsSettings.LoadSavedSettingsInitial() where you need to call "StaticSaveConfig()" to make sure that those default settings are written into the INI file during your first run.

I'm glad you brought that up. It's always cool to hear from somebody who has been working on this problem for far longer! MCM is actually agnostic to how you save because I anticipated that people want to do it in different ways. The tutorial only talks about saving to INI because it's a convenient integration mechanism for mods where players were already editing the INI files anyway. But saving to game state is also quite straightforward with MCM. I should update the documentation to show how to do it. If you were trying to mimic how LW Toolbox does it, you would do it this way: Use MCM's API parameters that allow you to conditionally show options based on UI mode (specifically strategic/tactical), maybe show a "options only available in a campaign" page if you're in the main menu. Load/save your data via game state in the appropriate events that MCM dictates during initialization and when the save button is clicked. Also when the reset button is clicked if you want to go the extra mile.In general though, you're right that you give up some freedoms in MCM (specifically the ability to do freeform UI's) in order to take advantage of the UI conveniences that MCM provides. My hypothesis is that you don't really need that much freeform UI because the list format is often a good enough way to organize things. However, I definitely want future versions of MCM to give the developer more flexibility, which is also why I'm keenly interested in a UI challenge like what Zyxpsilon is trying to accomplish.

Based on what you said, I went back and tried something out. Turns out it was a very specific issue: UIPanel.SetTooltipText only seems to work if the panel you're calling it on is currently visible. Since MCM creates a bunch of UI elements that aren't immediately visible, it was hiding the panels after creating them, and that seemed to break the tooltips. So now every time a page of settings is pulled up, it just does a once-over and re-establishes the tooltips. Problem fixed!

Yeah, definitely! I've been thinking about how to make aspects of your particular set of configuration issues easier to do. Couple questions for you: 1. Do you want to use something like a dropdown where every option is a checkbox? Like some sort of "expandable setting item" for you to check off a "shopping list"? 2. Do you want to include images of flags in the settings?

Yeah, I'm obviously biased, but I think MCM will probably save you a bunch of the work that LW Toolbox doesn't. It removes the vast majority of the UI coding you'd have to do, including a bunch of different pitfalls and quirks that only show up once you try to implement the settings menu yourself. It also makes compatibility with other mods' settings pages automatic (if they use MCM, or at least if they don't mess up MCM). I guess what I'm saying is that MCM solves a ton of UI headaches for you that you might not know you have yet, even though it doesn't solve all of them (especially the issue of saving settings into INI files). ;)

Yeah, Zyxpsilon, there were some tooltip fixes in the patch specifically addressing missing tooltips in the options screen. Maybe I missed some important detail, but when I tried to replicate the setup on MCM's sliders, no tooltip shows up. I've searched through the entire call stack under UIPanel.SetTooltipText to try to figure out what's going on and eventually hit the black box point (native or Flash stuff). Again, maybe I just missed some important detail, but otherwise I'm a bit stumped.

Hey fxsjosh! Yeah, I get the rule for doing that. However, in order to let mods save configuration changes to INI from in-game, you currently have to break a few rules in a few specific ways. (Wrote up the exact method here.) It's because SaveConfig() doesn't work to write settings back to INI files located in the mods folder, but it does work to write settings to INI files located in the My Games/XCOM2 folder. So if you want to be able to save settings to INI files in-game, it leaves you with a few limited options, all of which seem to involve calling SaveConfig() or StaticSaveConfig() on an INI file that should exist but currently doesn't. One other alternative is to save the data into the game state, but that doesn't persist across different campaigns whereas INI stuff does. Now that I mention it, I don't suppose you know of a way to do this that doesn't involve trying to be clever about breaking INI/config handling in just the right places?

I'm running into something, and I'm not sure what I'm doing wrong. Maybe someone here has solved the problem before? I'm trying to get tooltips to show up when you mouse-over a UIMechaListItem. Looking at the implementation of UIMechaListItem, I see two main calls being used: "BG.SetTooltipText(TooltipReason);" and "BG.RemoveTooltip();" So I tried to use those, but I'm getting a problem where BG.SetTooltipText doesn't actually make a tooltip appear. Calling BG.ProcessMouseEvents(), which is recommended in the UI guide in the SDK documentation, also doesn't seem to fix it. The UI guide suggests using "UIPanel.AddTextTooltip", but I also don't see that defined anywhere and get a compiler error when trying to use it. Maybe in the native UI class? The end result is that for settings in MCM, tooltips just don't show up on mouseover. I've dug a bit into the tooltip code to try to figure out why, but it seems like I may have to implement custom tooltips? Thanks in advance for any help! EDIT: Found the solution. See Post #6.

fxsjosh: One of the mods using MCM is using config variables as a flag for loading/not loading certain templates. Since the INI file (in My Games vs. mods folder) might or might not exist by that point, I was curious about whether there would be an elegant way to check for and possibly create the INI file. There's an alternative that works fine, it's just a bit verbose.

So it's been a whirlwind couple days dealing with the various bugs. Two major updates to add: 1. Now compatible with LW Toolbox. It overrides the options screen, so we had to change how we hook into it. 2. Dealing with the mess of INI's that make in-gave saving of settings possible is... messy and has some serious gotchas. I added an extra section of the tutorial on how to do it properly. Also, I have two requests for help: - I'm looking for a way to hook into the game at a point before templates start being loaded. Any ideas? - Got a mysterious report of Xbox controller buttons showing up in the UI. Huh? Anybody know what this might be?

After a bunch more work, I wanted to take this moment to announce that MCM is now publicly available both here and on Steam Workshop! We've been working on this for a while, so it's an honest sigh of relief to finally say "yes, you can download it now!" Nexus: http://www.nexusmods.com/xcom2/mods/573/ Steam Workshop: http://steamcommunity.com/sharedfiles/filedetails/?id=667104300 It's a soft launch because this mod is only as good as the mods that use it. So I want to offer my help here to any modder who is interested in building an in-game configuration menu for their own mod. I've already written a bunch of documentation here, but of course I can't anticipate every question. The features, in short: - MCM handles (almost) all of the UI code for you! - It's an optional dependency, meaning your mod will still work even when MCM isn't installed. - You compile directly against the API, so you'll know that you're making the right API calls. - Built-in versioning mechanism so that stuff doesn't break when your mod version and MCM version are out of sync. - Laundry list of advanced capabilities. So what now? Bug fixes and improvements. Some things still have bugs. Also, we want to add more types of settings and other capabilities. You can see the plans in the issue tracker. Many thanks to: Super-d22, Blue_Raja, and Abeclancy for their help in designing, coding, and testing.

Yeah, abelancy, would definitely like to see how you're doing that for MCM. It's a definite problem for clipping the UI.

Haha Superd22 isn't "andrewgu", that's me. :wink: But Superd22 did contribute a sizable chunk of code and is entirely responsible for the UI looking as "native" as it does. Yeah, there's another options menu project. This one is more fleshed out in terms of sheer feature support (https://github.com/andrewgu/ModConfigMenu/blob/master/documentation/advanced.md), and is more concise to use as a consequence of its underlying mechanism for letting other mods call into it. The bunch of us who have been discussing stuff in the Github repo have been going over the API design absolutely neurotically, so I think it's become very developer friendly.

Awesome thread! It's really cool to see the new content that everyone is building here! Me... I'm chugging away on the Mod Config Menu (MCM). You can track our progress here: https://github.com/andrewgu/ModConfigMenu The documentation is mostly written, and there are a bunch of remaining bugs to iron out. Several modders in the community (Super-d22, BlueRaja, and abelancy) have been doing an amazing job helping with architecture, finding bugs, and contributing code, so we're getting very close to a proper 1.0 release. Unfortunately it doesn't lend itself to sharing screenshots/videos, but if you look at the example code I hope the elegance of the API design is obvious!