Mods Enable/Disable UI

I know you can easily delete/add mods to an aternos server, but it would be awesome if there was a UI to quickly enable/disable loaded mods. This could helper server admins quickly troubleshoot/test mods, especially with version updates. For example say the new minecraft version breaks several mods I like to use but it's more important to me to update. I could remove them but then have to manually keep track of updates and add them back in.

I'm envisioning a UI in the MODS section that shows loaded mods and lets you enable/disable/uninstall the mod directly. Similar to how the OPTIONS UI simplifies access to the common server.properties settings, the MODS UI could simplify mod install/uninstall and unify mod management to one place. The one downside I can immediately see is an increase in unused server storage if the mod is left installed, but aternos already lets you add files/folders to the server so maybe that's a non-issue. If it is an issue then maybe this could be an exaraton only feature. Or alternatively the mods UI keeps a list of previously installed mods and disabling merely uninstalls the mod while leaving the list entry, whereas uninstall would remove the mod and remove the list entry.

Something like this:

(For context I have a year left of a B.S. in Computer Science, so I can definitely appreciate the unexpected amount of work to implement a "simple" idea. However, I think I failed to explain the idea clearly, because what I was thinking would sidestep any need for a "build" step.)

The main idea would be that disabling a mod would function exactly as deleting the mod, aside from savings a database entry for later reference. Enabling a mod would then function exactly the same as as the user installing the mod from scratch. This keeps the mod directory clean since it would only ever contain mods which the user wants. The only difference would be a registry file in which entries are only removed if the mod is explicitly uninstalled/deleted. The change is adjacent to the current workflow, not in it.

Now adding a small file to 1000s of servers quickly racks up used memory, that's certainly true, but a database entry wouldn't need anymore information than a unique reference to the mod, and a boolean value. I assume your internal API was some way to reference the mods, how else could you view/search/load mods. But even if it doesn't worst you're looking at writing a String of the exact mod name and version that you could lookup using the user facing search tool. Doing all that with Strings is probably the slowest and most memory intensive way to reference a mod, but it makes a generous upper bound for the problem.

Based on the jar filenames i've seen, we could say the average database entry takes up 100 B to store the mod name and an enable/disable flag (actually all the mods I checked were lucky to push 50 chars, so 100 bytes in UTF-8 should be generous). Now lets say the average server uses 50 mods. There's certainly servers that use way more than that, but i'm willing to bet the majority of servers are close to vanilla with less than 10 mods, if any—so again, a generous estimate. So on average, each server would get 5 KB bigger. That's 2 orders of magnitude below most mod file sizes, that's negligible compared to having a single mod installed, let alone compared to the minecraft region data.

Functionally, the idea works as a lightweight abstraction for your current user mod handling flow, but it keeps mod handling in one place, and more importantly, it makes configuring mods easier and more intuitive. All for a practically non-existent cost. Now, admittedly, that is conjecture. I don't have access to Aternos' analytics to be able to put a cleaner number on that estimate, nor do I know how your internal APIs function, but I think the argument is sound. I will admit that most mods/plugins I use are ridiculously easy to use with simple "plug-and-play" of the jar files directly to the mods folder. So maybe there are common mods that have to do a bunch of weird config whenever they get loaded and that breaks this idea. But again, the idea reuses the current functionality of solely installing or deleting a mod. It doesn't modify your workflow, it interfaces it for the user's benefit.

All that being said, I don't work with you all, and you can develop the software however you think is best. If there's some underlying weirdness that totally breaks that idea, you have the context I don't, and that's totally ok. I like looking at details like this and sometimes there are just big errors I couldn't see, or don't see till later. None of this was meant antagonistically, and if it comes across that way let me apologize in advance. I really appreciate Aternos' niche in the minecraft hosting world, and my experience so far has been clean and to the point—the ads don't even remotely bother me, that's how clean the UI is. The intent here was to clarify my reasoning in suggesting this feature, and and lay out the best argument I can put together for it. I just want to improve an already tremendous product, and make an already easy UI a little easier. Thank you for taking the time to look into my suggestion.

Cheers.

TL;DR: I think I didn't explain well enough. It wouldn't add overhead, and it definitely wouldn't require a "build" step. I think it would make the "modding" interface on aternos a bit more intuitive. Then again, i'm not helping you guys develop aternos, so if you think it wouldn't work, then cool, thanks for replying and for putting together some awesome software. No hard feelings.

Yeah that's where I was originally thinking, but idk if it might evolve into a source of clutter with unused mods taking up space, and since Aternos is free maybe prioritizing space saving is better. But I think that would work just as well from the user perspective.