So we want to bring Team Fortress to AvP2. It shouldn't be too difficult, all of the weapons we need are already in AvP2, and configuring armor and run speeds and whatnot isn't too hard. What we need, however, is input on how this should go down, and modders to make the more difficult things happen, like possibly adding new weapons and more importantly, new GAME MODES, like Capture the Flag or Assault, things that teams do that aren't Team Deathmatch. However, this is AvP2 Fortress, so everything should have an AvP2 twist to it. Like Preds and Aliens on the teams realistically, but not whorishly. No Predator rocket-launcher guys, for example, but a Predator as the Spy, a class that's supposed to cloak and primarily use a knife anyway. -- SMID
The third and last part of our series of articles, covering mod launchers and update agents.
Posted by Herr_Alien on Jan 4th, 2010
In this last part of our article we'll cover command line options that need to be passed to the command line to the original game so that a specific mod is launched. We'll also cover some best practices for using the mod launcher.
And if you haven't done it already,
We'll give some concrete examples on how to launch a mod for Quake 3 and Source, but most games (and engines) support (in a form or the other) command line parameters for starting a mod.
Now, each game engine has it's own command line parameter to load up a mod:
Before starting with the examples, it is worth mentioning that a lot of games use the Quake 3 engine, or its derivates. Medal of Honor, Call of Duty, Soldier of Fortune, some of the Star Trek games, some of the Jedi Knight games and the list can go on. It is very likely the mods for those games can benefit from the mod launcher just as well.
The trick for Source mods (and for Quake 3) is that the launcher, ini file, game executable and mod folder must be located in the same folder. This way, the launcher "sees" the game executable, which in turn "sees" the mod folder (esmod in our case).
What makes this mod launcher/updater interesting is that it is an external component. This has the distinct advantage that it does not require any changes in a mod's code base. No recompile, no possibility of screwing things up. It also uses just a web server as an update platform. It glues up the mod and it's website into one steam-like platform.
Now that you turned your mod into your own mini-steam, you might fall in some of it's pitfalls. This section tries to point out some of the most common ones:
Well, yes and no. Technically, yes, you can push updates at any rate you want. But your players might also become furstrated that they have to update each time the fire up the mod. Or worse, you might end up releasing updates faster than the community can adapt to, and you end up with half of the community playing one version of the mod and the other half playing another one.
Ideally, you'll want to bundle up your updates, and release them at a pre-defined schedule. Or use a policy like "each 1st of the month you might get an update".
This is related to the version numbering system, major.minor.micro.
The update mechanism is set so that a change in the major or minor version number will prompt the player with the "mandatory update" pop-up. This should also be consistent with the update itself: if you have an update that beaks compatibility with the previous version, make sure you alter the minor version number, or the major version if the changes are really, really big.
If the patch you created does not break compatibility with the previous version, then change just the micro version.
When you prepare a patch, make sure that the local .ini file is updated to reflect the same version number as the remote .ini file. Otherwise, the players will be stuck in a loop of start the launcher -> detect update -> install update -> start launcher -> detect update ...
This must be done by the patch installer itself.
Some of you might think "Wait! Why don't I code this functionality in the launcher/updater component itself?" Well, there's an easy answer for this: say you have the launcher updating the local .ini file. If the player then decides to cancel the installation of the patch, the local file will suggest the mod was updated, while the real situation is that the patch was not installed.
So, here are some of the methods to update the local .ini file using the patch installer:
Basically pack up the launcher INI file with the SFX archive, or with your patch installer. When the patch is installed, the old .ini file gets replaced with the new one.
This is especially easy when using installers created with NSIS. As an example for Eternal Silence, if the patch installer is supposed to update the local .ini file to version 3.5.2, the code for that would be:
And this pretty much concludes our article/tutorial/thinggie about launchers and update mechanisms for mods.