MCM hits 1.0! (Soft Launch)

[Kregano]

While changing SUPWEP_VER back to VERSION, I spotted a typo in the default settings .ini file name. I fixed that and voila, everything works while MCM is installed.

 

If MCM is not installed, the mod's settings .ini file only contains this:

[SuppressionWeapons.SuppressionWeaponsListener]
FirstRun=True

This, as far as I can tell, violates the rule that the mod should work, even if MCM isn't there.

Edited June 7, 2016 by Kregano

[bunnytrain]

While changing SUPWEP_VER back to VERSION, I spotted a typo in the default settings .ini file name. I fixed that and voila, everything works while MCM is installed.

 

If MCM is not installed, the mod's settings .ini file only contains this:

[SuppressionWeapons.SuppressionWeaponsListener]
FirstRun=True

This, as far as I can tell, violates the rule that the mod should work, even if MCM isn't there.

 

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.

[Kregano]

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?

 

I'm not 100% what "put the FirstRun entry for SuppressionWeaponsListener into a different INI file" means. As for the log stuff, LoadSavedSettingsInitial() doesn't seem to run at all from what I can tell. Even when MCM is installed, it just skips it and forces you to save the settings manually before it'll do anything.

[bunnytrain]

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.

[Kregano]

Ah, I did try giving the two .uc files different .ini files to use. All that happened was that the listener generated an .ini, while the settings file didn't.

 

I did have a log statement in LoadSavedSettingsInitial, but since it never appears in any of my logs, I'm just assuming it doesn't work (I really need to put an 'else' condition in there to see what's going on).

 

If it's the code that's busted, that's going to be a pain to debug.

[Kregano]

I figured out why the default settings weren't writing on first run. I missed a command to write the initial settings to the .ini file.

 

Still can't get the settings to write when running it through the debugger, but this is good enough for now.

[bunnytrain]

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.

[Dragon32]

Hello, mod user here.

 

I'm using MCM with a number of mods. One of them is ABECoreMod. That mod has a number of options and each option has quite extensive ToolTips. The ToolTip for the bottommost option in the list (about reducing some of Bradford's VOs) is not completely visible onscreen.

 

Not sure how possible it is to dynamically change the size (or more importantly width) of the ToolTips so they fit on screen.

 

Maybe something could be done to count the characters in the ToolTip text and increase the ToolTip's width based on that count?

[Kregano]

How's development been going on menu features? I've managed to reach the point where I probably need a drop down menu to handle all the options I've got.

[bunnytrain]

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.