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

Post feature Report RSS A special gift from AvP2 Team Fortress

Christmass is comming, and to celebrate it in it's true spirit, we're going to give all of you modders out there a gift!

Posted by on

  1. A special gift from AvP2 Team Fortress
  2. A special gift from AvP2 Team Fortress - part 2
  3. A special gift from AvP2 Team Fortress - part 3

Don't hold your breath if you're waiting for some cool T-Shirts or some new games. Instead we decided to share some of the knowledge built while working on our AvP2 Team Fortress mod. The following articles will focus on something most mods would love to have:

A mod launcher that also checks for updates!

You've heared it right, our gift to you consists in a tutorial on how to create your own mod launcher and update uitility! And to sweeten things even more, we're throwing in and an already usable utility. With just a few changes to an .ini file this component can launch UT, Quake and even Source based mods!

The last part of the tutorial (yes, there is more! Plus, we get to pimp out our mod for another day ...) will contain the actual finished product and it will be released shortly after this one, 4-5 days maximum. Meanwhile, here are the feature that the launcher has:

  1. Version checking against a simple text file hosted on a web server. The location of that file is arbitrary. Heck, it can be configured in an .ini file to point to your mod's web server.
  2. The update/patch/installer is downloaded automatically from a web server. Just as above, it can be you mod's web server.
  3. The launcher/updater is a sepparate component. This means ANY mod can use it without having to recompile its code. Further more, because it is an external component, it does not conflict with any other update mechanisms. Basically, if your mod is being handled through Steam, you can add this mechanism without one interfering with the other!
  4. It doesn't chew up resources! This is possible because the program is launched into memory before the mod starts, and it also unloads from memory immediately as the mod fires up. Neat, huh?
  5. Because the component is used for just one mod, there's no need to update the launcher itself. Although you can use the launcher/update component to actually update itself, by preparing a 'patch' for your mod that patches just the launcher.

Because all the key issues of the update mechanism can be set up to use your mod's web site, this tiny (under 100K) component gives you, the modder, full control over the update mechanism of your mod. No third party entities involved, just you and your community.

Components needed

All the examples that will be listed below are based on just one program, called Nullsoft Scriptable Installer System. Go ahead and download it, and while waiting for the download to finish, read on.
Made by the very same people that also made WinAmp, NSIS is a tool that is intended to build installers. However, because of it's plug-in friendly architecture, NSIS aquired new capabilities, including an HTTP client and the possibility to launch external applications. Just what we need.

Now that your download has finished, install it. Sellect 'Full' as install option.


First examples

With the following examples we're hoping that you'll get yourself aquainted with how NSIS is being used. You'll also see bits of scripting that are then re-used in the final product.

Updating mechanisms

Simple, browser-based, update
Without further ado, here's a very, very simple update mechanism. Granted that it just launches your default web browser to the URL of your latest patch, and it doesn't actually starts up the mod, the lesson here is that you can have the user reach the patch very, very easy:

simple_update.nsi

# This example shows how to make a simple update utility.
# It will fire up the default browser on the client side,
# and open the URL for your mod's latest update
Name "Silent Update"
OutFile "Update.exe"
# another value is user, but stick with admin: most people install
# ther games in C:\Program Files, and you will need admin rights
# to perform the install there.
RequestExecutionLevel admin
# Uncomment the icon line to allow customization of the update icon
# This will require you to recompile the .NSI script
# Icon "Update.ico"
SilentInstall silent
Section
AllowSkipFiles off
#open the URL; here's an example for AvP2 Team Fortress
ExecShell "open" "http://avp2fortress.lithfaq.com/update.php"
SectionEnd

Save the text above as "simple_update.nsi", right click on it and select to compile it:



You'll then get a small .exe; in the picture above I used a different name, but yours should be named exactly as stated in the .nsi file, "Update.exe". And now, the magic part: double click the exe.

Wallah! The user is directed to the update page of your mod's web site! Further more, you can set up the update page to automatically redirect you to the latest installer of your mod.

This is the actual mechanism used by AvP2 Team Fortress. We settled for this one because the Master Server Patch (aka Project Savior) for AvP2 has a version detection mechanism incorporated. We only needed a simple yet effective update mechanism.

A stand-alone update mechanism
This one uses the HTTP client that I mentioned a couple of sections ago. It comes in the shape of the "NSISdl::download" plugin. The usage is straight forward:

simple_update2.nsi

Name "Silent Update 2"
OutFile "Update2.exe"

RequestExecutionLevel admin
SilentInstall silent

Section
AllowSkipFiles off
#download the update
NSISdl::download "http://avp2fortress.lithfaq.com/arch/1.1_to_1.1.1.zip" "xx.zip"
#open the zip
ExecShell "open" "xx.zip"
SectionEnd


You'll notice that we didn't set out a path for the local file. In our case, the .zip file gets downloaded to the same folder as the update executable.

There's a reason why I wanted to show the renaming capability: instead of .zip files, you can download self extracting archives, or even better, installers. In this case, the last command (ExecShell) launches the installer, providing a seamless installation of the update.

Because of the seamless transition this is what the launcher&update component will use as update mechanism.

A bit about launching other applications

If the second update example didn't tip you off, here's how you can launch an external application.

minimalisticLauncher.nsi

Name "Silent Update"
OutFile "Launcher.exe"
RequestExecutionLevel admin
SilentInstall silent
Section
AllowSkipFiles off
ExecShell "open" Notepad.exe
SectionEnd

That's it, really. Just that "ExecShell" command again. But that very command is all that we need to launch any game executable with just the right command line parameters. Command line parameters that basically tell "Hey you, game engine! Run this mod for me!".


This concludes the first article. In the following days we'll go even deeper, and we'll build a launcher&update utility that will give you, the modder, a reliable way to launch and patch up your mod. Stay tuned!

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: