kettingpowered / kettinglauncher Goto Github PK

In the readme's arguments table, the -nogui argument is labeled as "-noui", which did not work for me while "-nogui" did.
Also when running the launcher with -help "-noui" is shown.

Currently the Patcher doesn't check, if re-patching is needed and just ALWAYS patches.
This should be optimized, by checking, if any of the relent files changed.
Relavent files should only be:

• installer.json
• server binary patches
• universalJar?

So I've been trying to set up a server with the 1.3.3 launcher, and uhhh... well, it keeps saying that a trojan virus is detected, and that just deletes it. This doesn't happen with the ketting-1.20.2-48.1.0-5ab73d26-server.jar file, so, this seems pretty exclusive aand, I kinda don't want to have a virus on my old clanker. Hope somebody resolves where this is in the code and yeah, thanks.

I have no damm idea where to go for mods A Link would be nice

KettingFileVersioned is not garuanteed to be initializable at that point

java -jar kettinglauncher-1.0.2.jar --minecraftVersion 1.20.2 should work, but it doesn't

Allow specifying specific Ketting Versions.

Since you did not like the idea of downloading latest, what if we allow subversions of the current version? So for example if we use kc 1.2.3, how about we allow all versions in 1.2?

All other servers I've seen use a special file like "user_jvm_args.txt", but here I'm not sure what to do, couldn't find any documentation on this either. I basically want to limit RAM usage for JVM with a flag like "-Xmx12G". This is what I tried and it didn't work:

java -jar .\kettinglauncher-1.3.8.jar -noui -accepteula -daus -daul -minecraftVersion 1.20.1 -forgeVersion 47.2.20 -Xmx12G

At the moment we manually check for args to be present / display hardcoded values (see #1). It would be a nice addition to put those args in a seperate class and check for them using isPresent or something like that

Would be nice to have someone translate the launcher sysouts into their own language for useability, might be a nice thing to add

I tried launching [kettinglauncher], specifically this version [kettinglauncher-1.3.8.jar], the newest version, with my All the Mods 9 server. It never starts; it runs for about 30 seconds and then crashes. Here are all the logs and crash reports I could find. I didn't know exactly what information you needed to help me or prevent this in the future, so I'm sending everything.

Test.txt
debug.log
latest.log

Here is a link to the complete mod list. https://www.modpackindex.com/modpack/64056/all-the-mods-9-atm9

Add new args here

Make the Log in the GUI COLERFUL!

In Bundled Ketting Dev Jar's the parsing of the -daul arg get's skipped.
This causes the minecraft server to somehow think, that it's in demo mode.
This sometimes causes other issues and is 100% not intended.

We should thus try to always remove all kettinglauncher specific arguments, without exception.

The server eula is potentially checked twice, if the launcher is started from a different directory.
e.g. java -jar ../launcher/kettinglauncher.jar would check for the eula in ../launcher from the launcher side, and in . for the started server.
This could lead to a condition where the eula in ../launcher is accepted, but not in ..

Would require InjectProtect to be put in KettingCommon, not sure if possible

The 1.20.2 launcher currently does not utilize the Forge BootstrapLauncher, which makes it incompatible with the current launcher

For dynamic Versions we have to:

• Download Manifest Hash (if it exists in a repo we directly download the manifest itself)
• Download Dependency Hash (if it exists in a repo we directly download the dep)

And especially the first step will hurt us, since the Manifest is currently not cached.
I would love to also cache the Manifest, but if we release new versions, the manifest necessarily has to change. Then cloudflare sometimes doesn't update the hashes and the manifest itself at the same time, and then the launcher complains.

So sadly this is not a trivial solution.

Maybe we could try to not check the Manifest's hash. Then a hash-mismatch would no longer pose a problem, and I could cache the Manifest again, which would probably improve download times.

Should that still be too slow, we could not check for version updates, if the manifest file has been modified less than a certain time.