Mod management in KMP is a chore for end-users who play on more than one server

[TehGimp]

We need to look into finding a good solution for getting mod control information from a server before KSP is even started, enable/disable those mods as required (and ideally also direct the user to where they can find missing mods), and then launch KSP to start a session for that server.

[godarklight]

This requires a separate program to connect to the server, pull the kmpModControl file out of the handshake, parse it (have a folder for potentially required mods), shift things around in gamedata and then (hopefully) connect straight into the server.

I believe rsync is a bad choice for this, having a folder for a mod manager to pick from is safer.

Spaceport guys never got back to me about redistributing mods either.

My chat client would be a pretty logical place to start, I forgot to include the GPL licence, but it is GPL.

[TehGimp]

Basing this on the chat client makes sense to me. Given previously discussed requirements & redistribution issues, I think that leaves us with this basic flow:

• Mod-checker client connects to server, gets mod information
• Mod-checker verifies if client has mods available (stored somewhere separate from KSP install of course). If not, mod-checker alerts user and provides appropriate link (if available) to SpacePort.
  • For previously discussed reasons we only want to allow links to SpacePort, otherwise we'll just display the "package name" for a group of mod parts/etc.
  • I don't think the existing design for the mod checker includes this element (correct me if I'm wrong), so we'll have to add the ability to group and label/link mods on the server and include those groupings in the data sent to clients.
• If the user has all required mods, the files are copied into the KSP directory and the mod-checker starts KSP
• We'll probably want the mod-checker to set a configuration file value that KMP can detect so that it auto-connects from there.

Ideally the mod-checker should have a friendly GUI for favouriting servers (and should probably use the same config file as the in-game KMP server list), etc, but whatever the solution it needs to readily support all KSP platforms. This design means the in-game launcher would still be available for people that primarily play on vanilla servers (or just a few servers that all have the same mods), and use of the mod-checker would be optional even though it duplicates the server list aspect of KMP.

[godarklight]

I had a crack at this, it's sitting at https://github.com/godarklight/KMPModClient

I didn't really use much of the KMPChatClient code because that's designed to stay connected to the server, seeing as the server instantly sends the handshake that's all I need for a mod check.

I did have to steal the Decompress method out of KMP though - I didn't realize messages were sent from the server compressed (and that brings up the question how my chat client even worked in the first place - I'm fairly confident I don't decompress messages).

EDIT - I have a build up here. People probably shouldn't be using this: http://chrisand.no-ip.info:82/kmp/testing/modcontrol/KMPModClient.zip

[ArtificialOwl]

Might be needed to check the integrity of the GameData/Squad directory to avoid any modification of part files and others .cfg

[godarklight]

At the moment KMPModClient only goes off the required list. It still builds the MD5 list, but doesn't actually use it.

If a user goes changing things in GameData/Squad the user will already know, and during a connection the server will still kick them out and tell them what failed.

The other problem is my KMPModClient has no real direction at the moment. There's a few design questions that need to be asked.

1. How should the KMPModClient handle mods that are allowed on the server but not required? A user may have mods they don't want to use normally, but one server requires it so it stays in the GameData-KMPModControl folder (Good example may be MechJeb in the required list).
2. How should KMPModClient handle the same mods with different MD5 hashes (at the moment it can't). There is no way to tell which mod is the newest mod so it can't automatically chose.
3. How should KMPModClient handle MD5 failures?
4. How do we handle multiple mod versions?
5. What should the GUI look like?
6. What options should be configurable for the user?
7. How should we handle autostarting KSP/KMP?
8. Again, There may be optional mods that can be used. Same as Q1 really.

Also, I don't think I'll be making a GUI for this program. I'm pretty bad with UI design - I aim for functionality.

EDIT: Markdown, why do you annoy me :(

[godarklight]

I've got a solution for different required mod versions, I'll stuff them in a folder and just name them their SHA hash.

Either way, I still haven't even thought about a GUI or autostarting KSP into a server from the command line :(