andrewgu / modconfigmenu Goto Github PK

A mod that needs to access individual settings in one of the page-level handlers (say, to implement ResetHandler) but doesn't keep references to these settings as instance variables (to avoid the garbage collection-related issues mentioned in the tutorial) could, until recently, find the relevant setting objects from the SettingsPage parameter by using GetGroupByName and GetSettingByName.

The recent introduction of MCM_SettingsPanelFacade broke this functionality. The SettingsPage parameter passed to these handlers is the MCM_SettingsPanel (not the MCM_SettingsPanelFacade), meaning GetGroupByName will always return none.

At a glance, it seems like MCM_SettingsPanel could hold a reference to the MCM_SettingsPanelFacade (populated in MCM_SettingsPanelFacade.CreateUi) that it could pass to all three SaveStateHandlers instead of self to fix this.

There's probably a memory leak related to using UIScreenListeners without specifying a default class. Would be generally better to be able to register handlers without needing to go through the hacky interface.

it does not look like it does in the example images that are posted here

The current design is mostly functional, but isn't exactly good looking.

Once we've settled on the final API, we need to produce documentation and helpful guides for anybody to easily integrate their mod settings.

It should work with the DLC :)

I currently have a mod that uses MCM to confer Suppression on guns from the base game, DLC, and mods. While the mod works fine with MCM installed, I now have 10 groups on a single page, with many that have 6+ items on them, and it's become very unwieldy to set the options due to the amount of scrolling required.

The ability to collapse the groups or pick them from a dropdown list would solve this problem, since I intend to support this mod well into the future and foresee adding more mods to the list.

If a Page has a bunch of settings, scrolling doesn't work with the mouse wheel if your mouse cursor is over a Group label. Scrolling does work if your mouse is over a Setting or the scrollbar itself. (Note that this issue only seems to present itself when the mod options are displayed as a 3D screen, scrolling seems to work fine as a 2D screen.)

andrewgu
I think we'll leave that as a bug to fix in version 1.1. It's not great, but it also doesn't require API changes, and mostly works.

Hey there, sorry for clogging up the issues with a request, but I'm at my wits end and you're probably holder of the knowledge I need.

I'm trying to implement the interface approach to exposing a Public API for a mod, for me its going to be for Mission Logic.

I got it all working as a package without that stuff, but now I'm trying to reverse engineer how you set it up and its just not building for me:

https://github.com/GuerrillaWar/XCOMMissionLogic

I think it has to do with the loading order but I don't know well enough how the build scripts do there thing. I noticed that when ModConfigMenu builds it always does the API package first (so the main package always has its depedencies available by the time it compiles), but I'm unsure what or where determines this.

When I pulled down your Mod to test out building it worked first try, so I can only assume I'm doing something wrong but I have no idea what that something is.

Beat my head enough against this tonight so I figured I'm putting out the bat signal.

The "editor package" based mechanism for sharing the interface across mods isn't thoroughly tested. These aspects of the dependency system need to be tested:

1. Dependent mod is before MCM in the load order.
2. Dependent mod is after MCM in the load order.
3. Multiple dependent mods (both before and after MCM) in the load order.
4. 1+ dependent mods installed without MCM installed.

MCM_UISettingSeparator.uc, MCM_GroupLabelSeparator.uc

defaultproperties {
    TITLE_X = 7;
    TITLE_Y = 8;
    DESC_X  = 7;
    DESC_Y  = 20;
}

According to 1, 2 the opening brace MUST be on a new line. Otherwise the variables won't have any effect.

For every MCM_API_Setting you should be able to declare a Tooltip (on-hover help text to indicate what a setting does.)

• Related, InitAsLabel might be improved with a "Description" paramaters, would a mod user wish to create "sections of settings" separated with a label and a small description.

ie :

General Setting

Tweak everything general

• Setting 1
• Setting 2

Advanced setting

You should really think about changing those as they are advanced.

• Setting 3
• Setting 4

Currently the example code has

APIInst.RegisterClientMod(0, 1, ClientModCallback);

where the first two parameters are the version of ModConfigMenu. This is sure to lead to all sorts of trouble when people forget to update it, copy+paste code from other mods, etc.

Instead the value should be included in one of those files that they're forced to copy into their mod but not allowed to touch.

Hi There!
One piece of functionality I'd like to see is a new API call to Checkbox.SetReadOnly();

See, right now you can only set Editable, which hides the checkbox completely (and it calls Read Only too, not sure why). I need my users to be able to see what the settings are on the disabled checkboxes. But they can't, because SetEditable hides that. SetReadOnly, on the other hand.... And really since the function is already there, I imagine you'd only need to add the API Interface.

I'd do it myself if I wasn't swamped, and knew SOMETHING about Git repositories...

Anyways, hope it's something you could get to. It's a big one for me.

Right now each control is hard-coded into the control class, and to specify a control type you need to call InitAsSomeControlType().

If we break each control out into a different class, not only will the code be much cleaner, but it will be much easier for users to create their own controls, as well as for us to add new control-types in the future.

On the downside, it will require us to include more interfaces in the ModConfigMenuAPI folder.

The links in the description on the nexus are outgoing steamcommunity links, so when you click then, you get a big warning about leaving steam (even though you aren't)

For example:
on the nexus
https://github.com/andrewgu/ModConfigMenu
has the url
https://steamcommunity.com/linkfilter/?url=https://github.com/andrewgu/ModConfigMenu

Also, http://steamcommunity.com/sharedfiles/filedetails/?id=667104300 is shown as plain text.

Noticed while debugging that cursor sometimes disappears in menus due to redscreens, causes issues. Remedy is to hit ESC until you can bail to a sufficient UI level to regain cursor. MCM needs to support at least mashing ESC to bail.

The API design can't be changed once it's out (without a major, non-backwards-compatible revision), so we need to test/refine it several times before we officially release.

This bug shows up because after PR-45 MCM_Slider no longer calls SetStepSize to configure the increment/decrement size for actual slider control.

The method doesn't need to be a member variable, might as well make it static to allow more broad usage.

See this image for example: http://imgur.com/TrG6srF

Currently, a mod has to call MCM_API_SettingsPage.ShowSettings() manually in order to tell the settings page to render controls. As BlueRaja suggests, we should be able to do this automatically, but first I need to know where to stick the code that would execute right after all of the UIScreenListener.OnInit() events have been triggered.

Several users reporting graphics errors and game freezes when transitioning scenes. Usually happening after the mod options menu has been opened.

Subsequent comments are going to include debugging info.

Hi,
I use the "Mod Config Menu Legacy" Version with Xcom2 Original (no dlc,wotc, etc).
My aim is Grimys Loot Mod + Legacy Mod Everything Reloaded and Mod Config Menu Legacy.
But with only the Mod Config Menu Legacy enabled the game crashes at startup.
I even uninstalled all mods (deleted all files) and used only Mod Config Menu Legacy, but the game still crashes.
Is the current legacy version compatible with standard xcom2?
I have the crash dump files if needed.
Thanks Jan

The line "var config bool CONFIG_VERSION" should be an int, not a bool.

When trying to make a slider, sometimes the save appears to subtract one from whatever was selected. Can't reliably reproduce but happens more often than not. I know the save is the problem and not the load because the config file will have the wrong value in it after saving.

Have tried the ranges 0-30, 1-30, 0-20, and 1-20. I've also tried having the step parameter at 0 and 1. Issue appears to be more common on numbers not divisible by 3 but it's still not consistent.

Have tested on 2 different sliders saving to 2 different options. One was an array element and one was a normal variable.

Creating a slider with min/max/step of 0/100/1. Accessing value via MCM_API_Slider.GetValue(). Log shows that the range is between exactly 1.0000 and 100.0000, along with integers between these two points. Presumably the "min/max" values are inclusive, so it would be nice if "0" was a value that could be reached with the slider, otherwise I'd have to make the range (-1)-100 to get a usable range of 0-100.

As an aside, might also be nice to have the value displayed next to the slider on its left (would even make viewing this issue easier). There's a big gap between the horizontally-scrolling label text on the left and the slider's left-hand side arrow on the right, with apparently nothing displayed between these two things.

This is actually something that you might not be able to resolve without going to a 2D UIScreen, but a soldier with a big gun (say a Mag Cannon) can block-out the scrollbar or some checkboxes, making interacting with the options menu a bit hit-or-miss at times. The tactical/strategy game works fine, the main menu is just an issue because the soldier can appear "on top" of the menu data.

andrewgu
Mag cannon blocking out scrollbar and checkboxes: yeah, not sure about that one. I believe the options screen has a similar problem. This might be avoidable by shifting the whole panel to the left. Again I'm inclined to make it a 1.1 thing.

This is one that I'm actually looking in to. I figure if I can iterate over the Actors on screen, I can just grab a reference to the soldier standing there, and either adjust his occlusion of the options menu when it is open, or just straight-up make him invisible while the menu is open. Kind of blunt, but if it works, it works.

Hello @andrewgu. I'm the author of the Additional Difficulty Adjustment mod.

I encounter a bug in your mod.

In my mod I create a slider for parameter "HP Multiplier":

Group.AddSlider('SliderHPMultiplier', "HP Multiplier", "The coefficient applied to the points of health of enemies.", 0.0, 10.0, 0.05, HP_MULTIPLIER, SaveHandler_HPMultiplier);

Initial value is 1.00.

When I click right arrow button the value change as follows:

1, 1, 1.1, 1.15, 1.15, 1.25, 1.25, 1.35

But the parameter should change as follows:

1, 1.05, 1.1, 1.15, 1.2, 1.25, 1.3, 1.35

How to achieve an accurate setting of the value by the slider?

Right now each settings tab can specify which set of buttons to use. Each tab is expected to keep track of config changes using change-handlers.

This has a number of issues:

1. It leads to an inconsistent user experience between tabs, making the config menus harder to use.
2. It is inconsistent with the conventional way settings dialogs work, in both Windows and Mac
3. It is inconsistent with the way the XCOM 2 settings dialog works
4. In order to implement "cancel", developers need to keep track of the initial values of every variable, which is a pain. We could add this as a value to the controls (and maybe still should), but there is a better way.

Here is my suggestion:

1. A single set of "Ok" and "Cancel" buttons, which do exactly as you'd expect. We could also have "apply" and "restore defaults" on a per-tab basis. Here is an example from Eclipse:

   

2. We ask developers not to set values in change-handlers, and instead provide an OnSave() callback, which is called on every tab when 'OK' is clicked (or on individual tabs when 'Apply' is clicked). In this callback, they will apply their settings using a series of MyConfigVar = MyControl.GetValue() calls. When can call SaveConfig() for them afterwards.

   This combines the small code-footprint of @Superd22's Default*Callback suggestion with the compile-time safety of using change-handlers.

   It also makes implementing 'Cancel' trivial. When cancel is clicked, we simply do nothing.

Tooltips don't seem to be working. I don't see tooltips on the vanilla options, even though some of them have tooltips defined using the same method you're using (BG.SetTooltipText). Maybe the vanilla tooltips are just garbage? They do work in some situations, like when you are in UIArmory_Promotion and the right-side ability summary screen shows ability tooltips when you mouse over them (defined in UIUtilities_Strategy.AddAbilitySummaryTooltip or thereabouts).

andrewgu
yup, they're broken. I spent some time trying to figure out how it worked in the UIOptionsPCScreen, and I think there's some hard-coding going on in the Scaleform UI. There's a tooltip system in the UI scripts that should be usable, but it may take some time to hook that feature up. I'm inclined to leave the relevant parts in the API and make it a 1.1 feature.

If you create a dropdown menu and it is low in the list of options in the menu, it can get cut off. In this example, there are four settings under the dropdown, but if there were only two then only about half of the dropdown would be visible. If the dropdown was the last option, then it would be virtually impossible to interact with.

https://www.dropbox.com/s/enwmegl3xormkql/mcm-dropdown-cutoff.png?dl=0

The ability to group controls is pretty essential to having a good config UI, for any config that has more than just a few options.

Something like this:

...or even just a group header would work.

When you change the value on a control that doesn't have a change handler set, you get errors in the console

[0047.61] ScriptWarning: Attempt to call None through delegate property 'ChangeHandler'
        MCM_Slider XComShell_Arid_Day.TheWorld:PersistentLevel.MCM_Slider_0
        Function ModConfigMenu.MCM_Slider:SliderChangedCallback:006F

Since the change handler is explicitly marked as optional (and also isn't set in the tutorials), this shouldn't happen.

There are tabs mixed into the spaces in the codebase. Should standardize on 4 spaces per indent.

This should be fairly easy to fix on your end, but before too many mod authors try implementing MCM support and get flooded with complaints about it: as is MCM is completely incompatible with the Toolbox because of how it's structured.

Specifically the problem is this in MCM_OptionsMenuListener:
defaultproperties { ScreenClass = class'UIOptionsPCScreen'; }

That part of the code will not hook into any classes that override what's specified there, it will look for only UIOptionsPCScreen, and will not hook into the Toolbox's UIOptionsPCScreen_LW.

What you want to do instead is set that to none and instead do the filtering like this:

event OnInit(UIScreen Screen)
{
    `log("MCM Listener OnInit");

 if(UIOptionsPCScreen(Screen) != none)
 {
     if (ENABLE_MENU)
     {
         InjectModOptionsButton();
     }
 }
}

When filtered in there, it will catch any classes that happen to be overriding the UI class it's looking for, fixing both problems with the toolbox and any future mods that end up overriding the class as well.

EDIT:

It occurred to me that I could just make a pull request for this.

Tooltips are working fine, but I've noticed that long tooltip descriptions can be difficult to read, since the tooltips themselves are very narrow and tall. Only 4-5 words can be displayed on each line of the tooltip, so it ends up being 15 or so lines long. Ideally, the tooltips would be much wider. They're currently ~300 pixels in width, increasing this would be nice.

Note that this also causes the tooltips to occasionally be cut-off near the bottom of the screen, because there is only enough room for 10 or so lines near the bottom of the list.

Firaxis finally released an update to fix UPK mod package loading that they broke back in June. Noticed that when I disable and re-enable menu options, the tooltips for those specific options no longer load. Not sure why, haven't looked into it yet.

In theory MCM can be used with game states, but there's no documentation for it. Need to write a tutorial for making this work. Upcoming Bronzeman Mod actually has an implementation of it, so might just offer that as the example.

This is a weird one. MCM_Slider uses UISlider to do its slider rendering. UISlider.SetStepSize() seems to jump the slider knob to one full step from the left edge regardless of the current value/position of the slider knob.

The fix seems to be to set the value both before and after calling SetStepSize(). However, this seems to fail on rare occasions, not reliably reproduced.

Even though the knob is visually misplaced, the correct value is still stored, so if the value was originally 100 with a min of 0 and max of 100 and step of 20, even though the knob looks like it's at 20, hitting the right arrow won't do anything and hitting the left arrow will move the knob to 80.

Seems to me like UISlider.SetStepSize() is just bugged, but this does in turn affect MCM_Slider's behavior.

The Save and Exit and Cancel buttons are selected by default when the UIScreen loads (see image). I've noticed similar issues with the Guerilla Tactics School list of Upgrade Projects: Labels appear highlighted when the menu loads, but once you mouse over-and-out of each label they appear correctly.

andrewgu
yeah, not sure why it's happening, but again I think we can leave it as a 1.1 bug since it's small and should not require API changes, and it's not unique to this particular interface.

Scenario :
User is using MCM with Mod1.
Mod1 contains two settings : S1 & S2.
By default, Mod1 sets S1 to 10 and S2 to true.
User changed S1 to 11 and S2 to false.

Mod1 updates,
Default S1 is now 20 because the dev tweaked the U.I
A new config S3 is now present.

1/ If the mod doesn't use StaticSaveConfig but SaveConfig instead, custom settings by the user will be lost.
2/ In any case, the user needs to be informed S3 is new and S1 was changed by the dev.

This would necessitate keeping track of the current values we have when MCM is run.
Which can be done (fairly) easily by creating a config array which MCM_API_SettingsPage could populate with setting Names/Values when it's done.

tldr: ScreenClass=class'MCM_OptionsScreen' compiles to None if only compiling API without main codebase, so at the very least a note about this should be in the documentation, ideally in long form paragraph where appropriate and short form comment in example code.

This is just a suggestion for some information to add to your documentation.

Basically, when I was building MCM straight in with my own mod, everything worked fine for the options menu listener. But when I removed the MCM main code (keeping the API stuff), I realized that the listener was starting to listen to everything instead of just the MCM menu.

defaultproperties
{
  ScreenClass=class'MCM_OptionsScreen'
}

Basically, because the compiler can't actually find the class, it just prints a WARNING (not an ERROR) to the compile log file and successfully compiles the project, but in actuality it replaces all class instances with NONE, so the above is equivalent to "ScreenClass=none".

That one other Issue that you dealt with recently of MCM's own ScreenClass listener, reminded me of this. Basically there are two ways to get this working for a mod listening for MCM.

The first is to just listen to ScreenClass=none and do the UIScreen instance testing against the MCM_API interface only. This does mean that the test is done on every UIScreen instance, but it is the most accurate and isn't too much of a hit.

local MCM_API APIScreen;
APIScreen = MCM_API(Screen);
if (APIScreen != none) {
  ...
}

The second is to use one of the following to retrieve either the MCM_OptionsScreen class or the class of a mod replacement for it, should there be a mod replacing it:

local class<UIScreen> MCMOptionsScreenClassType;
local class<UIScreen> MCMOptionsScreenModOverride;
if (ScreenClass == none) {
  MCMOptionsScreenClassType = class'XComGame'.static.FindClassType("MCM_OptionsScreen");
  MCMOptionsScreenModOverride = `XENGINE.GetModReplacementClass(MCMOptionsScreenClassType);
  ScreenClass = ...;
}
// still do the screen test

Two issues with trying to disable a Setting field:

1. Seems weird, but it looks like the last Setting of a Group can't be SetEditable(false). It still appears brightly colored. If I disable groups of Settings anywhere else they seem to disable fine, but the last Setting of a Group doesn't change display at all.

2. Disabled settings are still editable. The change is visual only. Part of your doc says "Disabled settings look gray and aren't editable," so I assume that this is a bug and not intentional.

The SaveButtonClicked for nearly every mod is going to be the same: Get the values of each setting, save them each to some variable, call SaveConfig(). The API can and should handle that automatically.

MCM has no controller support. Since the game is fully controller-compatible, we should add this.