Description
Game crashes when loading for the first time with Player's Choice + ElecCore (required library for a few mods, such as Deep Resonance):

java.lang.NullPointerException
    at elec332.core.module.ModuleManager.preInitLast(ModuleManager.java:83)
    ...

Full crash log: https://paste.dimdev.org/fepiqevami.mccrash

I know that the stack trace is pointing to elec332's code, but technically Player's Choice could be considered the root cause as it's responsible for nuking the mods on the first-time startup; though I'm more than happy to throw the issue over the fence if this is something that should be fixed on their end!
(Figured it would be valuable to bring to your attention either way.)

Versions
Player's Choice: 1.1-3
Forge: 14.23.4.2705

Title is self explanatory, the mod seems to crash while it's enabled alongside AE2 with this crash log:
https://paste.dimdev.org/iqunapajos.mccrash (log courtesy of VanillaFix).

If need-be i'll try to provide more info, but i don't think i can provide much info besides what's already here.

When i have Hwyla and the The One Probe as a required group it causes Hwyla to crash for some reason when i pick it instead of The One Probe. I have tried it with only Hwyla and it for some reason worked.

broken playerschoice.json (with extraMods):
https://gist.github.com/Zer0Lyfe/8f5d6c016ede221afe96574e8309b883

broken playerschoice.json (without extraMods):
https://gist.github.com/Zer0Lyfe/a5a925c96d57358504bbcae5a5b1da96

Working playerschoice.json
https://gist.github.com/Zer0Lyfe/e73218fd62efd346bd225dbc96e4052f

crash log:
https://gist.github.com/Zer0Lyfe/aff4abf39a02150a1e64f36fa87401ce

Even with adding the ModID to the crashing_mods section TConstruct results in a crash. It seems caused by baking the Smeltery model.

With it added to crashing_mods: https://pastebin.com/Lfe2C7wP
Without it added to crashing_mods: https://pastebin.com/epwQSdru

After the first run there is no need to have the client tick event running. This can save a few cycles per tick.

Currently, player's choice allows you to ship optional files/scripts from the "config/playerschoice_files" folder. However, if pack devs wanted to ship different versions of the same file, there is no current way to do this. Ex: if you want to ship an optional version of some mod's config file, you can only have one "config/playerschoice_files/config/XXXX.cfg" so you would only have one option to choose from.

An example of a way this would be used by pack devs would be to alter configs of a mod like "Rough Mobs 2" through a difficulty setting option. This could be done by having an important group called !difficulty for which the player had to choose either "easy", "normal", or "hard". Selecting "normal" would ship the default configs, but selecting "easy" would replace the config for rough mobs with one that has lesser difficulty settings. Selecting "hard" would replace the config with a different option that has higher difficulty settings.

One way I could see this being implemented would be if inside the "config/playerschoice_files" directory, the pack dev would have to make another folder with the same name as the id of the desired player's choice option. For example, if the id for the option was "test", every file inside the directory "config/playerschoice_files/test" would be automatically copied into the minecraft directory.

I hope I articulated this well. Thanks for the great mod, hope you consider this suggestion!

Is it possible to add a config option which modpack authors can update

The purpose of this option would be something like

Modpack Version: STRING

Where if the string changes the players choice runs again, that way when a modpack author updates their pack and wants players who are updating the pack to encounter the first load screen again they can.

It would also be nice if there was some way for the players choice to remember the previous selections a player made (assuming the same selections still exist)

This would be useful for modpack authors when they are shipping major updates or adding mods. Or other things change which might increase/decrease system requirements for a pack (and thus affect which mods a player might want enabled/disabled)

Forge: 14.23.4.2708
Hardcore Darkness: 2.0
PlayersChoice: 1.2-4

playerschoice.json: https://gist.github.com/TeetoKaziim/6d6efa26cc9a9dc4229e57a040c9dec3

Crash Report: https://gist.github.com/TeetoKaziim/041ea0ed41ae428855315561e18b7b45

How it happens:

Using Player's Choice, define Hardcore darkness as an optional mod in config\playerschoice.json.
If you select to have Hardcore Darkness disabled. After the restart, and when you load it again, it will get to the main menu just fine. But, when you open a world, you get the crash in the gist at the top of the issue.

Thanks for having a look. This is a crosspost from their issue tracker too, just in case collaboration is desirable: lumien231/Hardcore-Darkness#36

Crash when loading a world new or old...
Description: Ticking entity

java.lang.ExceptionInInitializerError
at mods.betterfoliage.client.Hooks.getUseNeighborBrightnessOverride(Hooks.kt:49)

Could you make it so that there's an easy way to rerun the mod choice screen (maybe like Quark's q button) so players can change their mind on mods?

Thanks

When used in a pack containing Custom Main Menu, Player's Choice will not display it's starting screen.

Even when excompressum is added to "crashing_mods".
Crash when "crashing_mods" is empty: https://hastebin.com/cuzefoxobo.sql
Crash when mod is added to "crashing_mods": https://hastebin.com/pazigayoga.sql