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?