About this mod
Script templates for complex but lean MCM menus using array maps. Switches MCM scripting from a static to a dynamic system that can be altered at any time in-game. Minimizes script size and overhead.
- Requirements
- Permissions and credits
- Changelogs
What it is:
This is a script template resource designed to help modders create complicated MCM menus that don't stretch out over multiple, simultaneously running quest scripts. Its main feature is that it keeps the entering of the information entirely separate from the handling of it.
This reduces the amount of code processed when the MCM menu is displayed or anything is adjusted, improves readability & navigation for the modder, allows for almost any aspect of your MCM menu to be adjusted in-game, and avoids silly mistakes on your part when it comes to specifying UI strings because you no longer have to.
The handling of it is done in a compact handling script, which should really be all you'll ever need no matter how many options, submenus or even menus you have. It is entirely set-and-forget. (The standard script provided assumes you have your intel in quest variables, but the system can easily be adjusted to read from and write to any other type of variable storage, see the "advanced use" folder.)
The entering of it is done separately in a UDF and becomes a one-time deal, unless you change or add options in a mod update, in which case you simply run it once again. A few other aspects that don't need to run all the time, like adding the MCM items to the formlist and creating submenus, have been exported to UDFs as well.
What it ain't:
- a replacement of MCM: you still need MCM
- a patch to or modification of MCM: it's just an alternate way of doing the scripting that you have to do in your own mod
- an actual mod: don't try to install this package to your game folder with a mod manager
Why I did it:
- script size
Rather complicated mods need lots and lots of different types of options for the player to manipulate in MCM. Creating MCM scripts isn't terribly difficult if you follow pelinor's manual & have some basic knowledge of scripting, but you soon run into problems with size and have to splice the code over multiple running scripts, several times in fact as your mod grows and you keep adding new options. This is mostly due to the fact that so far each and every bit of UI intel for every option needs to be entered in manually, using string parameters to the UI functions, and all of that takes up quite a bit of 'compiled script size'. The included handling script(s) are under 200 lines long, and can pretty much handle whatever you throw at them.
- readability, ease of use
If you have multiple types of options scattered over multiple submenus, keeping track of what everything does and stands for becomes a headache. Got distracted for a second, now I'm gawking at some intel pertaining to option 5, let me scroll back up - oh yes, submenu 3..., what was that again?, and what section am I in - default or defaultscale... Separating the handling of the intel from the entering of it drastically improves readability in itself. The only script you need to navigate is the map population script.
- script overhead
If you have multiple MCM scripts iterating over x elseif conditions, checking out in which submenu you are or what option you're manipulating for every section you're in, you're really always running chunks of code that are not applicable for the situation at hand. This system only ever processes code that is applicable to the current submenu (reset & default sections) or the current option (all other sections). Not that MCM scripting was ever considered a resource hog because it's in menumode 1013, but every little bit helps.
- adaptability
Because none of an option's parameters are manually entered in the handling script anymore, but kept in a map structure, it's now possible to change any of them on the fly from another script that adjusts the information in the map structure itself. Any option's title, type, the variable it refers to, a scale's min/max/incr/decimal parameters, or the strings associated with types 1 and 7 - it's all entirely adjustable by other scripts while the game is running. The same goes for the number or ordering of options per submenu, or display parameters like indentation, highlighting and coloring, etc etc. This allows MCM to be used to create dynamic systems.
- some extras
The templates are set up to automatically set all your variables to the default values you stipulate in the maps when your mod first initializes, and do the same for any new options you add when you update if you mark them as being new.
The system allows for the state switching of both options and submenus by consulting an optional UDF.
For each option type associated with a single variable (1/2/2.5/4/5/6), the handling script will also call an optional UDF when the value changes, providing a lot of intel as its parameters. This is necessary for the state switching of submenus, but can be of use for any number of things (see 'adaptability'). A way of doing the same for type 8 & 9 options is included in the "advanced use" folder.
Kudos:
pelinor for MCM
hlp for NVSE4+, as always
Odessa for most of the 'start log' script and her work on the GECK wiki these past few years
Needed:
NVSE 4.6.3+, ideally 5.0.3 because you should always use the latest version
MCM 1.5
Recommended:
A sense of what UDFs are.
A sense of what arrays are.
Failing that, the ability to follow instructions and follow a template should at least set you on your way.
Permissions stuff: Public Domain
This is a script template resource designed to help modders create complicated MCM menus that don't stretch out over multiple, simultaneously running quest scripts. Its main feature is that it keeps the entering of the information entirely separate from the handling of it.
This reduces the amount of code processed when the MCM menu is displayed or anything is adjusted, improves readability & navigation for the modder, allows for almost any aspect of your MCM menu to be adjusted in-game, and avoids silly mistakes on your part when it comes to specifying UI strings because you no longer have to.
The handling of it is done in a compact handling script, which should really be all you'll ever need no matter how many options, submenus or even menus you have. It is entirely set-and-forget. (The standard script provided assumes you have your intel in quest variables, but the system can easily be adjusted to read from and write to any other type of variable storage, see the "advanced use" folder.)
The entering of it is done separately in a UDF and becomes a one-time deal, unless you change or add options in a mod update, in which case you simply run it once again. A few other aspects that don't need to run all the time, like adding the MCM items to the formlist and creating submenus, have been exported to UDFs as well.
What it ain't:
- a replacement of MCM: you still need MCM
- a patch to or modification of MCM: it's just an alternate way of doing the scripting that you have to do in your own mod
- an actual mod: don't try to install this package to your game folder with a mod manager
Why I did it:
- script size
Rather complicated mods need lots and lots of different types of options for the player to manipulate in MCM. Creating MCM scripts isn't terribly difficult if you follow pelinor's manual & have some basic knowledge of scripting, but you soon run into problems with size and have to splice the code over multiple running scripts, several times in fact as your mod grows and you keep adding new options. This is mostly due to the fact that so far each and every bit of UI intel for every option needs to be entered in manually, using string parameters to the UI functions, and all of that takes up quite a bit of 'compiled script size'. The included handling script(s) are under 200 lines long, and can pretty much handle whatever you throw at them.
- readability, ease of use
If you have multiple types of options scattered over multiple submenus, keeping track of what everything does and stands for becomes a headache. Got distracted for a second, now I'm gawking at some intel pertaining to option 5, let me scroll back up - oh yes, submenu 3..., what was that again?, and what section am I in - default or defaultscale... Separating the handling of the intel from the entering of it drastically improves readability in itself. The only script you need to navigate is the map population script.
- script overhead
If you have multiple MCM scripts iterating over x elseif conditions, checking out in which submenu you are or what option you're manipulating for every section you're in, you're really always running chunks of code that are not applicable for the situation at hand. This system only ever processes code that is applicable to the current submenu (reset & default sections) or the current option (all other sections). Not that MCM scripting was ever considered a resource hog because it's in menumode 1013, but every little bit helps.
- adaptability
Because none of an option's parameters are manually entered in the handling script anymore, but kept in a map structure, it's now possible to change any of them on the fly from another script that adjusts the information in the map structure itself. Any option's title, type, the variable it refers to, a scale's min/max/incr/decimal parameters, or the strings associated with types 1 and 7 - it's all entirely adjustable by other scripts while the game is running. The same goes for the number or ordering of options per submenu, or display parameters like indentation, highlighting and coloring, etc etc. This allows MCM to be used to create dynamic systems.
- some extras
The templates are set up to automatically set all your variables to the default values you stipulate in the maps when your mod first initializes, and do the same for any new options you add when you update if you mark them as being new.
The system allows for the state switching of both options and submenus by consulting an optional UDF.
For each option type associated with a single variable (1/2/2.5/4/5/6), the handling script will also call an optional UDF when the value changes, providing a lot of intel as its parameters. This is necessary for the state switching of submenus, but can be of use for any number of things (see 'adaptability'). A way of doing the same for type 8 & 9 options is included in the "advanced use" folder.
Kudos:
pelinor for MCM
hlp for NVSE4+, as always
Odessa for most of the 'start log' script and her work on the GECK wiki these past few years
Needed:
NVSE 4.6.3+, ideally 5.0.3 because you should always use the latest version
MCM 1.5
Recommended:
A sense of what UDFs are.
A sense of what arrays are.
Failing that, the ability to follow instructions and follow a template should at least set you on your way.
Permissions stuff: Public Domain