Split up Fika plugin to multiple independent plugins that focus on their own thing, rather than clutter the main co-op handling.

[DeadLeavez]

To simplify handling and developing of the different parts of the project. Basically leaving stuff like name plates, performance, etc to their own mini mods.

Suggested Categories

• Core
• Name Plates
• Ping system
• Performance
• Gameplay

Thoughts?

[hograthm]

But why? It will bring a lot of complexity like compatibility window and ICU(individual component upgrades) that need to be maintained.

[Lacyway]

The components will be built with the main project into the solution. It won't be much different from how it is now, and they will rely on each other. It will give people more freedom to add new features to existing components without bloating our configuration and primary Fika code further. It will also free up resources as the now optional features will not get forcefully loaded.

The code base is growing to a point where I think this will be beneficial, and we can then move the bundles to the server mod rather than loading it from memory.

The only situation where I would be against this is if we figure out a way to categorize the BepInEx configurations with drop downs, but I am pretty confident there is no way.

[MerijnHendriks]

I wouldn't be against this even if there were to be drop downs, more code and files makes navigating the project harder. Splitting it is a nice way to keep things compartmentalized.

@Lacyway would you like me to create a new branch for this with the initial projects set-up?

[nexus4880]

Reasons to do it:

• Relocate config entries from Fika.Core to their own categories
• Abstracting the logic from the main code base allows us to clean it up
• Helps us know exactly where what is as right now it's all kind of mashed together
• If people don't want something (like health bars) they can choose to not download it at all instead of having it bundled in Fika.Core
• It would improve modding compatibility as having them in separate modules would require us to write more flexible code (and more useful events that people can use)
• More events mean less patches (for the developers that actually look into how to use them) which results in better performance (not that patches are that expensive but when people run 50+ mods that all patch things, it can get hectic) and higher stability

Reasons not to do it:

[wolfgangvc]

To add to @nexus4880 comment, ontop of possibly making "fika core" more modable by dogfooding, it would also provide some nice examples for making fika compatible mods.