Provided screen factories causing unnecessary overhead when opening mod menu screen

[MrCrayfish]

I'm currently using the API to provide config screens for other mods. As stated by the docs, I need to return a map of all the mods ids and their associated config screen factory. However ModMenuApi#getProvidedConfigScreenFactories is being called for every mod and library, and this means my provider is running 46 times at minimum (Fabric, it's libraries, and Mod Menu). My suggestion would be to call getProvidedConfigScreenFactories from each provider once, combine them and then request from that map.

[Prospector]

Good point, I am trying to figure out why I didn't do it like that to begin with, but can't come up with anything. I'll do what you suggested.

[Prospector]

So, it turns out this breaks a ton of mods that use config providers because they relied on the fact that it wasn't accessed until later... I may have to revert this until those mods have fixed their implementations. Affected mods so far seem to be Architectury and owo-lib

[Prospector]

I think I can fix it by delaying the accessing of the fields until the first time a config screen is requested, but it may cause a brief lag spike. At least it would only be one time instead of every time though.

[MrCrayfish]

Lazy initialize on the first time opening ModsScreen, that should fix compatibility.

[Prospector]

yup, that's basically what I did in 6.2.1