MCM hits 1.0! (Soft Launch)

[bunnytrain]

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). ;)

[Zyxpsilon]

Speaking of UI coding.. is there any "easy ways" to just somehow hi-jack some key gfx assets to enhance various (default or new) components of MCM?

 

Here's what i mean. As i am trying to prepare a solid Mockup of the qUIck_FLG mod-options entirely built with your tool, i came upon a few tricky principles that would need to use indirect functionality found in different areas of the vanilla content or screens. These are purely Flash devices, granted... but i feel it wouldn't take a lot of busy work to exploit these resources directly without much "custom" adaptation coding.

 

Basicly, the drop-down lists (of nationalities -- editable) would almost mimic the RECRUITS screen.. see below;

 

http://s32.postimg.org/ptcp6m6md/Flags_Names_Drop_Down_List.png

 

These names are simply being replaced by real "Countries" while the cool (RECRUIT) green button and its embedded Arrows animation might host other details related to *this* mod and various options.

So, all i'm saying is that multiple frameworks are readily designed by the game itself while precious & highly variable HUD concepts (even when constructed with minimal core assets like what MCM currently offers) could receive Hooks to a variety of structured flows of relevant data & gfx elements.

 

To me, the essentials can be demonstrated by what RealityMachina was able to provide in his brand new "Buildable Hunter Weapons" mod and how he managed to create a relatively obvious set of options via purely basic MCM implementation.. but still, without some extra IDE/UI graphics (that i wish anyone could just have handy).

 

Think it over -- please. :wink:

Edited May 20, 2016 by Zyxpsilon

[bunnytrain]

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?

[Zyxpsilon]

1) Well.. that's where the formal (planned & currently under early development) MockUp would make things a lot easier to "visualize" my exact intentions. In general terms, i'd have multiple contexts each with its own dropdown-list (i feel 12-15 lines might fit in the current framework to leave room for other stuff) selection steps. All would follow the same structure created by the modular FLG versions (FP1 to FP5.. as shown in my Nexus thread & into the Workshop snapshots of the core FLG mod) whereas unique access to a few settings (such as.. UnitWeights=Slider, ID-Tag=Symbols, On/Off=CheckBox, maybe Languages=DropDown-Defaults & Race types==DD, etc) belong to each individual Country lines. FP(#) supply exactly 41 Nations maximum each while FLG has the basic 36 (US to Venezuela).

 

Check/OFF shopping list is a relatively good term to define how people would activate (or lock away) anything from these lists. A bit like the RECRUIT button above that is in fact an indirect (embedded) drop-down structure that could host the selectable settings (=)'s -- some of which needing to be nested (Languages & Races) as well. Complex, yet simple. :ninja:

 

Ideally too... specific buttons should offer direct contexts. Like --- FP1.. FP5.. Continents (NA, SA, EU, AF, AS, OC) & some Regional Groups similar to what's used to expose the Flags contained in every packages.. Only Bonuses (Batman, StarTrek, etc).. Favorites (configurable).. and so on.

 

2) As references if possible but still highly desirable, the UI would then show up direct relationships between Lines and what they each have to offer. Generally speaking, this intuitive method "accelerates" the process of detecting what players really want.

 

3) Of course, Save'n'Load principles with maybe custom "Naming" convention of the necessary Config files!

 

Trick here i guess is.. If MCM can offer as many optimal components (IDE or features) as possible.. Then players will be attracted to the power in that device.. Else.. the cool factor is being lost in somehow limited controls some people would tend to wish for in the near future -- or immediately! :wink:

 

qUIck_FMO (Flags Mod Options) is just a dreamy device as of today -- yet, the code & tasks seems pretty simple to handle. Thanks to good tool design decisions you've already taken -- so far.

 

There you go. Soooo busy lately with the wild SwappImg mod (which worked flawlessly on my benchmark tests ealier this afternoon) .. i can't seem to find quality time for FMO. Soon, baby, soon! :smile:

Edited May 21, 2016 by Zyxpsilon

[Amineri]

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). :wink:

 

This is a perfectly valid approach, in my humble opionion. I just decided to go down the other road, leaving more things up to the modders, which also gives (I think) more flexibility in terms of how to set it up.

 

Plus you also went the other route of having it save to config (which is persistent across all campaigns) instead of saving into the savefile (which is only per-campaign). I debated a lot trying to decide between these two options, and I don't feel that one is necessarily clearly superior to the other in all cases, so I'm glad that the other option has been released via MCM :smile:

[abeclancy]

Technically I don't believe there's any reason why you couldn't write to the savefile with MCM: It doesn't handle the config/save writing on behalf of mods that use it (unless there's been an update in the past week or so).

 

Right now in my own mod, when I get an event that the options menu is loaded, I just pull the options from the config file and build any necessary checkboxes, buttons, dropdowns, etc. When a save event is sent, I write the options to the config file. If in a tactical or strategy layer, if I wanted to I could load data from the current save and add those options to the menu, and mix-and-match at will. The only reason why I'm not doing that currently is just for simplicity's sake so I can focus on other features.

 

I suppose what someone could do, is write a mod that abstracts away the saving and loading of data from config files or the savefile. But saving to/loading from a config file is easy (just make a class with config variables and call Save), and structs can't really be abstracted away that easily (I know array.Find() can use a variable property name of a struct, but I don't think anything else can reference struct properties dynamically like that).

[bunnytrain]

 

[snip]

 

Plus you also went the other route of having it save to config (which is persistent across all campaigns) instead of saving into the savefile (which is only per-campaign). I debated a lot trying to decide between these two options, and I don't feel that one is necessarily clearly superior to the other in all cases, so I'm glad that the other option has been released via MCM :smile:

 

 

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:

1. 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.
2. 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.

Edited May 24, 2016 by bunnytrain

[Kregano]

Here's an interesting bug (or I just set everything up wrong): if I use MCM check box hooks in the DownloadableContentInfo file to control changes, the mod will compile, but it won't work when I test it in debug w/o MCM, even though the mod did work when the MCM stuff wasn't there.

 

The only possible sign of a problem I've got is this:

E:\SteamLibrary\SteamApps\common\XCOM 2 SDK\Development\Src\SuppressionWeapons\Classes\SuppressionWeaponsDefaults.uc(3) :
Warning, INI file contains an incorrect case for (Version) should be (VERSION)

which is total BS, because I've looked in both files and seen that it's in the same case.

 

Here's my code for reference:

static event OnPostTemplatesCreated()

{//first entry is the weapon you want to add an ability to, second entry is the ability to add

	//base game guns
	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');
	}
	if (class'SuppressionWeaponsSettings'.default.PISTOL_ENABLED == true)
	{
		`log("Base game Tier 2-3 pistols have Suppression!");
	AddAbilities('Pistol_MG', 'Suppression');
	AddAbilities('Pistol_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.CANNON_ENABLED == true)
	{
		`log("Base game cannons have Suppression!");
	AddAbilities('Cannon_CV', 'Suppression');
	AddAbilities('Cannon_MG', 'Suppression');
	AddAbilities('Cannon_BM', 'Suppression');
	}
	//LWS SMG pack
	if (class'SuppressionWeaponsSettings'.default.LWS_SMG_ENABLED == true)
	{
		`log("LWS SMGs have Suppression!");
	AddAbilities('SMG_CV', 'Suppression');
	AddAbilities('SMG_MG', 'Suppression');
	AddAbilities('SMG_BM', 'Suppression');
	}
	//Total Advent Weaponry
	if (class'SuppressionWeaponsSettings'.default.TOTALADVENT_RIFLE_ENABLED == true)
	{
		`log("Total ADVENT rifles have Suppression!");
	AddAbilities('AssaultRifle_Advent_CV', 'Suppression');
	AddAbilities('AssaultRifle_Advent_MG', 'Suppression');
	AddAbilities('AssaultRifle_Advent_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.TOTALADVENT_SMG_ENABLED == true)
	{
		`log("Total ADVENT SMGs have Suppression!");
	AddAbilities('SMG_Advent_CV', 'Suppression');
	AddAbilities('SMG_Advent_MG', 'Suppression');
	AddAbilities('SMG_Advent_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.TOTALADVENT_CANNON_ENABLED == true)
	{
		`log("Total ADVENT cannons have Suppression!");
	AddAbilities('Cannon_Advent_CV', 'Suppression');
	AddAbilities('Cannon_Advent_MG', 'Suppression');
	AddAbilities('Cannon_Advent_BM', 'Suppression');
	}
	//Halo Reach weapons
	if (class'SuppressionWeaponsSettings'.default.REACH_SMG_ENABLED == true)
	{
		`log("Halo SMGs have Suppression!");
	AddAbilities('WP_ODSTSMG', 'Suppression');
	AddAbilities('WP_ODSTSMG_MG', 'Suppression');
	AddAbilities('WP_ODSTSMG_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.REACH_PISTOL_ENABLED == true)
	{
		`log("Halo pistols have Suppression!");
	AddAbilities('WP_REACHMAGNUM', 'Suppression');
	AddAbilities('WP_REACHMAGNUM_MG', 'Suppression');
	AddAbilities('WP_REACHMAGNUM_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.REACH_SAW_ENABLED == true)
	{
		`log("Halo SAWs have Suppression!");
	AddAbilities('WP_REACHH4SAW', 'Suppression');
	AddAbilities('WP_REACHH4SAW_MG', 'Suppression');
	AddAbilities('WP_REACHH4SAW_BM', 'Suppression');
	}
	if (class'SuppressionWeaponsSettings'.default.REACH_AR_ENABLED == true)
	{
		`log("Halo rifles have Suppression!");
	AddAbilities('WP_REACHAR', 'Suppression');
	AddAbilities('WP_REACHAR_MG', 'Suppression');
	AddAbilities('WP_REACHAR_BM', 'Suppression');
	}

	//if you enter stuff that doesnt exists (i.e. ruler autopsies in builds that dont have the dlc) nothing happens, so compatibility should be assured
	AddAbilities('blablabla', 'blubblubblub');
}

[abeclancy]

Kregano I'm unsure as to your exact issue. You're not entirely clear as to what the problem actually is (all you say is "it won't work"). The code you pasted is difficult to parse due to the wild spacing. And you haven't included any information as to what this has to do with the MCM mod. DownloadableContentInfo doesn't have anything to do with MCM.

[Kregano]

This code should be adding the Suppression ability to the weapons named in the code.

All the MCM stuff is the

if (class'SuppressionWeaponsSettings'.default.REACH_AR_ENABLED == true)
	{
		`log("Halo rifles have Suppression!");
        }

things, which are the only change from when it worked and when it didn't.