[feature request] Auto determination of sidedness about serverpackcreator HOT 24 CLOSED

Thanks for opening your first issue here! Be sure to follow the bug, feature, or documentation issue templates!

from serverpackcreator.

Heya kreezxil,

I remember we talked about this on the BH partner discord. I've thought about adding this feature, however, not many mods actually document their sideness in their mods.toml file. I've looked at the 20-something client mods in my server pack and of those mods, one specified that it was strictly clientside-only.

Could be a nice addition to the FALLBACKMODSLIST in Configuration.java, though. Not sure whether it's worth the effort, though.

from serverpackcreator.

Yes you can prepopulate, it will lower the amount of effort for pack devs. As it stands, your tool is great for that don't know how to build a server pack.

What I'm after if you'll partially implement my ideas is to stop having to manually make my servers. I have a workflow that works for me because in a given month I will create a server pack at least 6 times or more. But If I can do it easily with a tool, that would be a great boon too me.

Already, using https://github.com/TheRandomLabs/ChangelogGenerator/ my workflow has been optimized by a factor of at least 20% or better. Because now I can speed build a new pack version, and use that tool to compare the changes between exports and wala instant change log/block post.

from serverpackcreator.

Unless you add more clientside-only mods, you could always create a separate ServerPackCreator folder, with a configuration dedicated to a particular modpack/server pack. That way you'd only have to configure SPC once for each pack.

As for the clientside-only-detection.....I'm torn. On one hand, yeah sure it would be nice to have, on the other:
I just checked and yeah, of 10 1.16.5 clientside-only mods, only one mods.toml (AmbientSounds in this case) explicitly stated clientSideOnly="true". Other mods, which are definitely clientside-only, contained side="BOTH" (looking at you, PackMenu 👀 ).

Seems really unreliable and potentially dangerous to automate this process, as it could lead to server packs containing clientside-only mods which could destabalize a server.

Hm.

from serverpackcreator.

Update:
I'll take a look into this with version 3.x where users will be able to upload modpack.zip exported from the CurseForge app to the ServerPackCreator webservice, which will then in turn spit out a download of the generated server pack.

from serverpackcreator.

Here's another thought. Related to this. Would be advantageous to prolific pack designers such as me, or those that just update often.

Have the program maintain a local database of mods commonly selected for client side. And then prepopulate that field.

On a side note, when I click the folder, to select more mods, have the previously selected mods, also already selected.

from serverpackcreator.

Yeah, that's why I created FALLBACKMODSLIST. In case a user does not specify any clientside mods, or simply forgets, this will kick in. Pre-populating is a nice idea though. If the config has no entries for clientside mods, prepopulate so users get a clear example of what the list can look like.

from serverpackcreator.

Got the first results reading a mods.toml-file of a mod for its sideness, but I am struggling to find a way to detect the sideness of a 1.12.2 and earlier mod. Do you have any resources about that available? Your hint regarding the @mod annotation hasn't yielded anything so far. Not sure where to look here.

from serverpackcreator.

Hmm, 1.12.2 and earlier might be more complicated. Because there are multiple ways to pull the client only sidedness off.

Ways to do it

1. https://mcforge.readthedocs.io/en/1.12.x/concepts/sides/
2. with clientsideonly=true @mod annotation as seen in my own torchoptimizer. https://gitlab.com/kreezxil/Torch-Optimizer/-/blob/1.12.2/src/main/java/com/kreezcraft/torchoptimizer/TorchOptimizer.java#L21

from serverpackcreator.

Thanks.
Of course, I would have to somehow get a hold of these annotations from the compiled code, as mods don't ship with their source code, so I can't really check for annotations in classes...
We will see whether its possible in a reasonable way. If not, people who make 1.12.2 packs will have to continue to detect their clientside-only mods by themselves. 1.16.5 will definitely work, if the author has set up their mods.toml correctly, so at least there's that.

I'll go through the linked docs more in the coming days.

from serverpackcreator.

from serverpackcreator.

I'll move the fallback modslist to a property in serverpackcreator.properties, thus allowing users to expand said list without touching the code of ServerPackCreator. A global database which SPC would connect to, to gather a list of clientside-only mods sounds nice, but is out of the question as well. I would have to host and maintain said database as well as monitor everything anyone adds to said database. Too many trolls and not worth the effort. Not to mention the security risk that can come with hosting a publicly available database. lolnope :D Maybe a separate repository on GitHub/GitLab/whatever, which contains a textfile with a list of clientside-only mods. That would have to be maintained, too, though. In the end, the modpack-maker knows, or rather should know best which mod in their pack is clientside-only, but I will do my best in helping the users out with that process. It would help if modmakers would maintain their mods.toml files or otherwise make it known to their users what sideness their mod has....

As for the annotations, I'll see what I can do. Though I agree 100% that decompyling would be way too hacky and, most notably, too time consuming/resource intensive both runtime-wise when generating a server pack and work-wise as in coding that in.

I'll see what I can do. I won't promise perfection, but I'll do my best to aid users with this process. The better I can make this autodetection work, the better the UX.

Thanks for your input. I really appreciate it and you've helped me out a lot here. :)

P.S.: Starting to like the idea of a separate repository for the list of clientside-only mods. Caveat: Makes SPC even more dependant on a working internet connection than it already is. Humm.

from serverpackcreator.

from serverpackcreator.

I got the feature itself working for 1.13+ mods, however, there is a problem:
Scenario:
Mod A states in its mods.toml that it is clientside-only, and is thus excluded from the server pack by the new feature.
Mod B in the modpack specifies mod A as a dependency as well as stating in its mods.toml that it is required on both client AND server.
ServerPackCreator thus creates a server pack without mod A, but with mod B, resulting in an unusable server pack, as there are missing dependencies.
I could, of course, add a textfield to the UI and properties to allow the user to configure mods to include in the server pack, even though it might say it's clientside-only, but that would make the whole point of adding automation to ServerPackCreator useless.

Add automation only for the user to need to configure something else anyway.

from serverpackcreator.

I'll give this another try, if that fails ever so slightly, the feature will, unfortunately, get scrapped as I won't be willing to spend any more time on it:

The plan:

1. Make a list of all mods in the modpack allMods
2. Scan all mods.tomls and create a list of all mods which should be on the server
   1. Add all modIds from [[mods]] and [[dependencies.modId]] which specify BOTH or SERVER to a list serverMods
      1. If [[dependency.modId]] is for Forge || Minecraft, add the modId to the list, otherwise add modId specified in [[dependency.modId]]
3. Remove fallbackmodslist from allMods
4. Remove delta of allmods minus serverMods from allMods
5. ???
6. Profit?

from serverpackcreator.

from serverpackcreator.

An SQLite-database mayhaps? Write every mod which remains after the sideness-check into said database, if it is not yet in it.

• Name the database clientsideMods.db
• Check for existence of a clientsideMods.db in the ./addons-directory or maybe ./work-directory upon startup of ServerPackCreator.
  • If a database is found, add all entries missing in the main-database
  • Delete additional database to prevent redundant check the next time SPC is started

How does that sound? A system like that would allow users to share databases around and add entries to their own databases.

from serverpackcreator.

from serverpackcreator.

I won't write a DBMS, sorry.
There are plenty of tools out there that do a way better job at it. There is no benefit from me spending time on writing a tool to edit/change a database when software like DBeaver exists. I don't have the time nor any interest in writing a DBMS or even implementing one in SPC. It's way out of scope. SPC is meant to be a server pack generator, not management software or something. You configure the program according to your modpack, click a button, store the server pack and you're done.

If the automation isn't stored in the database, then storing user input, which is more prone to error, in the database makes even less sense, doesn't it?

The way the autodetection works currently:

• Add modId if side is SERVER|BOTH in either [[mods]] or for Forge|Minecraft in [[dependencies.modid]] (See Additional Colours)
• Add modIds from [[dependencies]] whose modId is neither Forge|Minecraft if side is SERVER|BOTH (See CreatuveCire dependency for AmbientSounds)
• If no side is in [[mods]] or in [[dependencies.modid]] at all, add the mod to be on the safe side. (See YungsAPI, AutoRegLib, Repurposed Structures)
  That way, we add any and all mods which may be ever so slightly possibly mayhaps perchance required on the server. From the list of ALL mods in the modpack, THAT list is then subtracted, leaving only mods of which we can be 99,9% sure they're clientside only.

If a false positive still happens, tell the affected moddev to set up their mods.toml correctly, because what the frakk is the state of some mods.toml-files out there. 😂

from serverpackcreator.

Unfortunately autodetection will not be available for 1.12.2 or older. The fml_cache_annotation.json-file is either not present for many mods, or the information therein is not enough to reliably deduce the sideness for a given mod, thus leading to many false positives, overfilling of mods considered serverside etc. etc.. The data is actually too inconsistent to reliably work with, as much as I hate to say it.

from serverpackcreator.

It doesn't detect everything, but it works. God damn that was a mindfuck and a half.

from serverpackcreator.

from serverpackcreator.

As in sponsors on GitHub? No, you're the only one as of this moment.

from serverpackcreator.

Feature for autodiscovery implemented. Can be deactivated by setting de.griefed.serverpackcreator.serverpack.autodiscoverenabled=true or false respectively.

I'll go ahead an close this ticket now. 🙂
Everything else mentioned herein, like writing mods/modIds or anything else to a database for sharing should be discussed in a separate ticket. Haven't decided yet on how or when to work on a database in any way, shape or form.

from serverpackcreator.