[LE] Splitting MCM menu into multiple smaller scripts

[PeterMartyr]

In my experience 128 is limit for a few things, Alias, Arrays, etc, etc, so this not something that is specific to States alone.

[IsharaMeradin]

In my experience 128 is limit for a few things, Alias, Arrays, etc, etc, so this not something that is specific to States alone.

I am aware.

 

But the lack of warning by the compiler does leave a logical assumption that one must test first for proof of failure rather than blind assumption that should the CK complain then the game must also complain. After all, if it were true that all errors/warnings in the CK were also problems in the game then the game would have way too many problems to function properly at all. Have you seen the list spit out by the CK every time it is loaded?

 

At any rate, I tested for my own curiosity. An externally compiled script with 130+ states (which was pre-attached to a start game enabled quest) yielded the following in the papyrus log:

[10/29/2017 - 12:50:23AM] error: Class abim_test overflowed the named state count field(s) while linking. The class is marked as invalid. A programmer must adjust the bit field sizes

Think I will dust off my CK wiki login and edit the States talk page at least to indicate this limit.

[PeterMartyr]

I agree with you, but I learned the hard way not to argue with the 128, in regard to FormList, upon not getting any Errors in CK, I commerce ingame testing, it failed. I have never attempted to beat it again. So it was more a case of: once bitten, twice shy.

[IsharaMeradin]

128 in regard to FormList? Do you mean Arrays? Formlists are not limited by count. If they were, half my mods would not work as intended.

[PeterMartyr]

OOpps my bad, freakin English.... I gotta stop speed writing.

[foamyesque]

I agree with you, but I learned the hard way not to argue with the 128, in regard to FormList, upon not getting any Errors in CK, I commerce ingame testing, it failed. I have never attempted to beat it again. So it was more a case of: once bitten, twice shy.

 

Yeah, I've put thousands of forms into a formlist without problems (well, aside from a certain amount of slowdown when operating on it). A 128 limit on Aliases would be news to me as well; the CK will cheerfully let you put far more than that into a quest.

[Anubis22]

Just to clarify again, my problem is indeed about the state options being too many, as tested by IsharaMeradin.

 

To summarize some good workarounds were already mentioned:

1. Extending the MCM script and have the extended scripts each handle part of the menu

2. Assigning multiple UI elements to the same state and dynamically checking which one is currently in use (compromise between State options and optionIDs)

3. Reverting back to optionID layout

4. Using two independent mod entries for MCM

 

I listed them according to my preferences and hope I got the ideas right. I believe splitting the script in several (if it can be done reasonably well) by extending could yield the cleanest results in the end and scales very well. So that is what I am going to try first.

 

A state for every single option strikes me as major overkill. Have you considered, say, using one per page? You could, say, have one page for Destruction, and all your relevant code and variables set within a DestructionPage state. That keeps your OnWhatever events from turning into truly ridiculous spaghetti, but should keep your state count sane.

 

Could you explain further what you meant by this? Is it the same which PeterMartyr suggested / does my point 2. sum it up correctly?

 

 

 

Edit:

Tried option 1. with a minimal setup and could not get it to work. It compiles fine, but the pages will be empty. it seems MCM only accepts UI elements from the base script

 

Edit 2:

Looks like I'll be going with a compromise between states and optionIDs. One state per page and within that state I check for all possible optionIDs for the given page. It may not be the nicest possible way, but at least it is reliable.

Edited October 29, 2017 by Anubis22