Closed TehGimp closed 10 years ago
Been talking about this with WetMelon. Instead of the server giving the client the mods directly, it should give clients the URL on SpacePort to download and install the mod automatically. Only SpacePort URLs would be accepted.
Additionally, any mods that required plugins (DLLs) or otherwise contained executable code would be rejected by the client.
This means you couldn't require the client to have something like MechJeb, but you could require something like B9 which is purely parts.
Given the popularity of mods like MechJeb, it may be worthwhile to offer server users two package types: part-only mods that can be auto-downloaded, and "not just parts" mods for which we can provide the user a SpacePort link for manual installation (therefore ensuring that the user is aware of and takes responsibility for any risks involved). While an enterprising hacker could still easily use a custom client to avoid them, any "good" mod-support solution should at least make a cursory attempt at enforcing which assemblies are loaded anyway (to prevent HyperEdit type cheating etc where it is not desired).
That implies that we may need to do some of the mod management outside KSP via an external launcher, as while I can think of ways to check on loaded assemblies, it is not so easy to interfere with them--we'd more or less be limited to not allowing the user to connect if they have invalid assemblies loaded.
Do we all agree that the partslist needs to be server sided and send to client during the handshake?
@ryannathans I have trouble envisioning a solution that doesn't include this--no matter what the in-game client needs to check at launch time for disapproved parts.
Alright, I'll have a peak and see what I can come up with. Hopefully won't take too long.
See if you can get md5 hashes for version control while you're at it.
md5 transmission of partslist to prevent retransmission if up to date?
no, we're going to need md5 comparison for every part in the mod.
Oh, I see what you mean. Okay, will have a look. Do we only support mods that go in GameData or all if possible?
You might also need to check the full install of a mod (with dlls) when a client try to take control of a vessel
I'm doing it when they connect to the server.
There is a few different problems here: We need an approach that bans all mods, except those allowed. The suggestion is to run an md5sum on every single file in GameData, however remember that "KMPPlayerToken.txt" will be unique on every computer. If ommiting the entry allows it to match any md5sum, then how do ban other mods (or do you only catch new .dlls?)
To avoid issues we should have an "allowedCheats" flag, default set to true on the server.
EDIT: also how do you list a mod as optional? Or do you force everyone to install mechjeb?
I'll implement multi-stage mod checking. Firstly there's the parts synchronization, we ensure everyone has the same parts list, this avoids crashes when loading ships you don't have parts for. This is managed by the server admins and transferred in handshakes. This is currently client-sided.
Secondly, there's the md5 verification. This is for tamper and version control. Every single file in GameData has a computed md5. The server sends a list of files and their md5s. If the clients file's md5 does not match that on the list (or clients file doesn't exist), they will be notified and refused entry to the server. If the server doesn't list a file, it's not checked. This is so that the server operators can specify a version of a mod to use.
Thirdly, the resource verification. We check loaded resources, primarily dlls. If there's a dll that is not on the server controlled whitelist, the user is refused entry just like an md5 mismatch.
I have already started writing the md5 verification.
Optional mods shouldn't be an option (yet?). If one user has mechjeb2 for example, and someone else in the server flies by a ship that has a mechjeb part, they will crash.
I now realise this is going to take at least a few days. 0.1.4.0? No. 0.1.5.0? Maybe.
There is a mod that puts the mechjeb functionality in the normal crew parts without using a mechjeb dovamahicky on your ship, That most likely loads an assembly (unsure), but it does not affect other players in any way.
Kerbal alarm clock is similar, doesn't add parts and it's not cheaty.
The mod for mechjeb that puts functionality into normal crew parts simply edits the config of the original parts. With my server-mod-control implementation server admins can specify the md5s of the files they want controlled. If the specify that the stock files are md5 controlled, then this mod will not be allowed. Otherwise it's perfectly fine by default.
@TehGimp assign me to this :+1:
@ryannathans the server-side parts list and validation are all yours =)
@TehGimp have a look at the changes in the branch I've started in my fork. Will probably take me a few days to finish.
It just occurred to me that module manager is used heavily to modify parts. However I don't know if the game would complain
@WetMelon the only time it'll interfere with my upcoming patches is IF a server admin requires all STOCK stock parts. If you know what I mean, matching md5s of all stock parts.
By default (no configuration) the modulemanager will work.
This is the new server sided configuration file (which has replaced KMPPartList.txt) and includes lots of new features. I fixed the typos.
My work so far: https://github.com/ryannathans/KerbalMultiPlayer/compare/server-sided-modcheck
Update is all ready. More details in #452 I'm still adding features like server commands but the fundamentals are ready and seem to work.
Sorry, how are people getting the mods? Downloading manually?
How ever they were before
Potentially edge case, but may be worth discussing:
What happens if a user frequents a server that requires a mod, as well as a server that does not allow it? Like assume a server that allows B9 (and so requires it to ensure everyone can at least view the parts without issues), and one that insists that all parts are stock. Would the user have to manually remove or add B9 from their installation and restart their client every time they want to switch servers?
Could there be any way for KMP to hot-swap/disable installed mods when the user tries to log in?
If not, what about when a user connects to a server that does not allow a mod that the user has installed, give the user the option to automatically put the offending mods into a KMP_Disabled_Mods
folder in the KSP directory? user would (I think) still have to restart their client, but at least they wouldn't have to fiddle with the files. conversely the server that requires the mods could look for them in KMP_Disabled_Mods
and if it finds them give the user the option to move them back for them.
Hot swapping mods, from what I've seen, can't be done. The restart is required for the game to read them. This PR is an improvement over what currently exists. Eventually I hope for an in game mod manager, but that's not coming soon.
I had an idea about this:
I was going to look into making a mod manager that connects to a KMP server, figures out what mods it needs and puts everything in the correct place, then starts KSP.
There might be some type of licencing problem with spaceport. It's unclear whether the mods that are GPL (Mechjeb for example) can be redistributed from the spaceport downloads. If it's permissible, I'll also come up with a way to automatically download the mods from servers (Will require setting up of rsyncd however).
Haven't had a chance to test it myself, but it might be a good idea to get in touch with whoever made this KMP parts manager: http://forum.kerbalspaceprogram.com/threads/57284-All-OS-Java-MultiPlayer-Part-Manager-V2-2-25-nov-2013
Seems like that could be extended to work for what you have planned.
I already have weeks ago, look in the thread.
I've opened a thread on the KSP forum discussing the use of modpacks for servers and players: http://forum.kerbalspaceprogram.com/threads/62432-KMP-modpacks-and-eventually-stock-multiplayer
ryannathans' work is now merged into master--after a round of testing we'll see if we can find a sufficiently elegant solution for mod management
I would suggest an agreement between server and clientside mods by allow clients only to use the mods they have installed by agreeing using a set of modpacks for ease of installation
A minor issue to take into consideration is that currently there is no way to hot-swap or dynamically disable mods without an external mod manager that has to be run before booting KSP (I'm hoping that this is something that Squad will implement for when they add proper multiplayer)
Well, right now let's say that the best solution is to have one copy of ksp per server. Also, admin should be able to add an url in config file to link when client is unable to connect because of addons incompatibility. Admin will create a webpage with a list of mods and link on spaceport. Remember that modpack are not possible without authorisation from the license owner of each addons.
Yeah, too bad you can't disable mods at loadup, despite the fact that there are mod managers available. I wished they worked together with KMP so that it will autoble/disable mods before load up
I would suggest only to share the plugin and gamedata files if they are being used as a modpack. but then you have to figure out how to set it back when you are playing in singleplayer.
The core server side mod-control problem in this issue is now addressed. Closing this issue and we'll track "mod manager" concerns in #498.
Clients should be able to download missing mods directly from the server during the log in