[FEAT] Mod installer (aka Blue Shift support part 1)

[Alienmario]

In order to support overhaul mods that come with their own game folder + gameinfo.txt (such as Blue Shift) we should devise an automated mod install + launch process for servers.

Mod registry

There should be a central registry file that we can ship, which for each of supported mods includes:

• workshop id
• short name
• sequence of commands needed for installation. These can be generic - create link, copy .. or os specific commands
• first map

Plugin commands

All commands take workshop id or short name for mod resolution.

Install mod

• Adds the specified mod to subscribed_file_ids.txt if missing.
• Prints a message telling the user to restart, so mods can start to download.
• Prints error message for unsupported mods.
• sc_install bshift

Launch mod

This is where it gets tricky since overhaul mods require launching with custom -game parameter, which we have no direct way to affect.

As a workaround we can use a static game name scmodlauncher as a dynamically updating symlink pointing to the active mod directory. We then instruct users to launch with -game scmodlauncher.

We'll most likely need to do the same with the +map parameter, since server won't fully start with launch map missing.
We can ship an empty placeholder map.

The final file structure would look like this:

• Black Mesa Dedicated Server
  • bms
  • bshift [symlink to workshop content (./bms/addons/workshop/content/362890/2424633574/bshift)]
  • scmodlauncher [symlink to active mod (bms, bshift, ..)]

sc_launch would do the following (approximately):

• checks that the mod has downloaded
• runs post-download install commands, creating mod symlink in server root
• creates symlinks for addons, maps, server.cfg and other req files inside the mod folder
• updates scmodlauncher symlink
• configures Sourcemod
  • replacing all "bms" references in gamedata
• kicks clients with instructions
• quits server

After the restart, we can detect our placeholder map and change to the first map of the mod.

Implementation

• Can be a part of srccoop_addon_workshop_manager.sp
• We can use System2 for running commands or archiving functionality.

[Alienmario]

There is a fundamental problem with using a static -game parameter as client will reject mismatches.

The game is passed to clients in CBaseServer::FillServerInfo.
If we do this, we could ultimately stick with bms game folder by rewriting its gameinfo.
wdyt @ampreeT

[ampreeT]

There is a fundamental problem with using a static -game parameter as client will reject mismatches.

The game is passed to clients in CBaseServer::FillServerInfo. If we do this, we could ultimately stick with bms game folder by rewriting its gameinfo. wdyt @ampreeT

Here's what I'm thinking:

• Server hosts will have to duplicate their server installs in order to run Black Mesa and other game mods. Each installation of Black Mesa Dedicated Server is roughly 35 gigabytes without mods. We could symlink to the folder and modify the gameinfo.txt to switch the game mod, but I'm worried about the friction/confusion for people to understand how to switch mods in a straight forward way. Too much CLI :)
• How do we handle listen server support?
  • In the future (within this upcoming release), I think we should think about having a workshop mod with a PowerShell/Batch installation process similar to Black Mesa: Blue Shift. For listen servers, we would only need to worry about how to run a single SourceMod instance for all of the supported game mods.

Other thoughts:

• We may not be able to support sc_install in a generic fashion due to non-standard file paths for game mod installers. With the work we have to put in for supporting coop with the EDT file types, it might be better to automatically detect supported workshop game mods with SourceCoop. Thankfully for us, there are only a few game mods running off bms.

Is the game mismatching even if both the client and the server are running the same mod?

Side note, I have not tested this yet, but it is possible that we may not need to touch the SourceMod GameData files as I see references for #supported engine which suggests it will include bms gamedata even if its running under a mod. If this is true, we could look into just symlinking the game mod folders and just tackling how we would manage SourceMod installations when a server host adds a new workshop game mod.

[Alienmario]

There is a fundamental problem with using a static -game parameter as client will reject mismatches.
The game is passed to clients in CBaseServer::FillServerInfo. If we do this, we could ultimately stick with bms game folder by rewriting its gameinfo. wdyt @ampreeT

Here's what I'm thinking:

• Server hosts will have to duplicate their server installs in order to run Black Mesa and other game mods. Each installation of Black Mesa Dedicated Server is roughly 35 gigabytes without mods. We could symlink to the folder and modify the gameinfo.txt to switch the game mod, but I'm worried about the friction/confusion for people to understand how to switch mods in a straight forward way. Too much CLI :)
• How do we handle listen server support?

This is literally what I'm trying to avoid. It's too much - size, complexity, usability, skill level. We should be able to switch mods with a command, and keep the server the same.
Gameinfo's paths start from server root, there's no need to mount the exact folder it's in (?).

• In the future (within this upcoming release), I think we should think about having a workshop mod with a PowerShell/Batch installation process similar to Black Mesa: Blue Shift. For listen servers, we would only need to worry about how to run a single SourceMod instance for all of the supported game mods.

I think the only worth way going forward (from my experience so far) is a gui launcher. If you think about the complex problem at hand, it needs to install sc, install srcds, install mods, run bms with selected mod, run srcds with selected mod. Players nowadays expect not to have to use cli.

The issue with this is, it does not solve dedicated server mod support. We can't / shouldn't control the launch process of dedicated remote servers, it's too out of scope.

I think it would be best for the launcher to offload mod support to console commands, so we only have to write that part once.

Listen servers suffer from player targeting issues among others and should ideally be only used for mapping.

Other thoughts:

• We may not be able to support sc_install in a generic fashion due to non-standard file paths for game mod installers. With the work we have to put in for supporting coop with the EDT file types, it might be better to automatically detect supported workshop game mods with SourceCoop. Thankfully for us, there are only a few game mods running off bms.

At this point we can't, the WS isn't even being mounted.
There was another issue with mods being mounted into bms, they will sometimes override game content. This would be active even when not playing them. They can also collide with other mods. The game had to mount them all at launch.
Therefore I think it's best to incorporate synthetic game switching for those too and have everything under 1 system.

Is the game mismatching even if both the client and the server are running the same mod?

No, the -game parameter is all that matters.

Side note, I have not tested this yet, but it is possible that we may not need to touch the SourceMod GameData files as I see references for #supported engine which suggests it will include bms gamedata even if its running under a mod. If this is true, we could look into just symlinking the game mod folders and just tackling how we would manage SourceMod installations when a server host adds a new workshop game mod.

It uses both game and engine references. But even if you tackle sourcemod, other plugins will still need to be dealt with.
Therefore I still think it's best to stick with bms if possible.

[ampreeT]

This is literally what I'm trying to avoid. It's too much - size, complexity, usability, skill level. We should be able to switch mods with a command, and keep the server the same. Gameinfo's paths start from server root, there's no need to mount the exact folder it's in (?).

I'm down with this idea. Lets go down the route of using CBaseServer::FillServerInfo and sticking with the bms game type/folder

I think the only worth way going forward (from my experience so far) is a gui launcher. If you think about the complex problem at hand, it needs to install sc, install srcds, install mods, run bms with selected mod, run srcds with selected mod. Players nowadays expect not to have to use cli.

Agreed with this. I've seen people having troubles installing Blue Shift.

Listen servers suffer from player targeting issues among others and should ideally be only used for mapping.

I haven't tried hosting a coop listen server and seeing the associated issues but this would still be good to look into after the mod installer is finished. Before launching the game, server hosts on windows will have to launch srcds first as the srcds instance acts a game instance blocking steam game launches.