The problem with the popularity of the main assembly

[BiosNod]

Apparently need the main GC better or like current popular servers, some beginners prefer to connect to the custom servers because many different things like:

• cant setup all banners in Banners.json, probably need to search in #resources but... This really complicated for beginners (Even if they find, then Banners.json often don't work properly for them either). I already made pull request https://github.com/Grasscutters/Grasscutter/pull/1905
• can't simply make a letter himself with stuff like on another private server (Just compare the issued stuff here and there, need more stuff by default)
• Lack of very useful commands like enka, this can be found separately, yes, but who wants to look for 10 individual repositories for each commands? Also some repositories with commands can be incompatible with the main GC branch
• Some developers prefer to conduct their repositories instead of merging to the main repository

All these disadvantages from above are solved by programmers who can change this, but not the end users who just want to use and not think about it

Additional problems with public servers:

• In the GC community there are still some craftsmens to make closed code of the: servers, plugins, etc... The community has no rules about the closed code ٩(๑･ิᴗ･ิ)۶٩(･ิᴗ･ิ๑)۶
• big problem with erasing DB by server owners sometimes (probably for the updates)
• a very big problem with launching custom LUA code which the server can come

Should the main GC be better and easier to use it to Localhost instead of custom user servers with more interesting settings??

[Birdulon]

The community has no rules about the closed code ٩(๑･ิᴗ･ิ)۶٩(･ิᴗ･ิ๑)۶

Sure it does, check the license ;)

Some developers prefer to conduct their repositories instead of merging to the main repository

That's up to them, really. Merging to the main repository means bringing the code up to the current quality standards of the project, having a relatively stable interface that won't need breaking changes in the near future, being compatible with the maintainers' vision for the project, and waiting for a maintainer to test everything with the PR. It can be a frustrating experience with many projects, so it's understandable that some developers won't want to deal with it.

[4Benj]

cant setup all banners in Banners.json

You can easily replace what banners that the server uses simply by creating a data folder where the jar is located and putting a banners.json file inside of it, which will tell Grasscutter to load that banners file instead of the one that is located inside the jar. Your pull request was unnecessary imo and probably won't be merged based on discussions that have happened internally.

can't simply make a letter himself with stuff like on another private server

What do you mean by this?

Lack of very useful commands like enka

Grasscutter is still in quite early stages of development (imo) but the main goal of Grasscutter is to try and get as close to the official experience game as possible without putting the project into legal trouble (DMCA takedown) but also allowing server administrators to expand and customize as much as they want through plugins. Commands that may seem useful but may only serve purposes in select circumstances are best to be left implemented by a third-party plugin, not implemented in the main repository to prevent unnecessary bloat. If there is a functionality that you want to customise but are unable to through a plugin, you can either, implement a interface or something plugin developers can extend from like I did with #1282 or #432. Additionally, there is also GrasscutterGameProvider which is a modified version of the Fabric loader that can modify the Grasscutter internals using Mixins.

a very big problem with launching custom Lua code which the server can come

If you're talking about quest issues or something like that, then again, that's because we have to be careful to prevent us from getting a DMCA takedown request. Additional issues with the Lua is that the game Luas require a specific version of Lua that Java has incompatibilities with without platform-specific binaries which can lead to more bloat then we need and can make Grasscutter incompatible with certain platforms that we don't have binaries for.

big problem with erasing DB by server owners sometimes (probably for the updates)

DB erasers by server owners have nothing to do with Grasscutter. I personally have been using the same exact database for Grasscutter since the project started (with little compatibility modifications in the early days of the project).

[Birdulon]

big problem with erasing DB by server owners sometimes (probably for the updates)

Oh yeah that's also often caused by them having development practices that aren't up to the quality and API stability standards of the main repo. Go fast and break things :D

[KiminaNatsuki]

oh god that's literally a wordbomb

[BiosNod]

@4Benj

If you're talking about quest issues or something like that

Not about quests, just any public server can send a code with a custom LUA to the player computer and hack it by perform its code =), therefore, it is not very good when users prefer to connect to someone instead of using a local server due to the complexity of the config, this problem solved only by the client’s patches, the server has nothing to do with it but... Almost no one has yet patched the client and connect to different servers

[4Benj]

@4Benj

If you're talking about quest issues or something like that

Not about quests, just any public server can send a code with a custom LUA to the player computer and hack it by perform its code, therefore, it is not very good when users prefer to connect to someone instead of using a local server due to the complexity of the config

There isn't much we can do to stop that. We've blacklisted the packet from being sent but that is extremely easy to remove on modified versions of GC, or just by going around GC's packet handler. Blame anime game company for this security vulnerability not us.

The only way to stop this from happening completely is for the user of the server to install a proxy that blocks that specific packet or, like you said in your edit, patch the game to remove that feature, but then they may not be able to play custom game modes on that server unless they disable it on that server.

[BiosNod]

to install a proxy that blocks that specific packet or, like you said in your edit, patch the game

Unfortunately, ordinary users are unlikely to read this issue and did it, maybe this is clearly add to Readme.md

Okay, I understand the main repository is very clean, it doesnt swell too much. Is it possible in this case to implement an official manager of third-party plugins with version dependencies? Against loses a little in functionality compared to already raised servers (also servers with a closed code). Even programmers don't want to look for a heap of plugins separately at the first launch, it will be possible to select the necessary plugins in the terminal. Or wait, maybe the in the future plugin manager will be possible to add to the Cultivation, but this is another story in another rep)

[4Benj]

maybe this is clearly added to Readme.md

You assume people read the Readme.md but most don't😆

Is it possible in this case to implement an official manager of third-party plugins with version dependencies?

An official plugin repository similar to CurseForge for Minecraft mods is in the works (although progress is slow), which can provide compatibility, dependencies, and other such information to server administrators. Additionally, you will be able to access this repository and manage plugins from the Cultivation launcher to manage plugins, and possibly a first-party plugin will be developed or integrated directly into GC to interact with the repository API to keep plugins up-to-date etc.

[2y8e9h22]

no have no use for