Coding Tutorial 3: Making Your Own Package - POSTAL 2

Making Your Own Package

Starting with the Cheat Manager

Code Tutorial 3

You must be running the new Share the Pain version of POSTAL 2 for any of this to be relevant. Using these tutorials with older code may cause you problems.

These tutorials were written to be completed in succession with one another. If you jump ahead to a later tutorial, I will be discussing things from earlier tutorials that you may not recognize. Following each one in order should greatly improve your learning experience.

This will teach you how to take that same cheat manager, SuperCheatManager, and pull it out into your own package. The reason this is difficult is because of all the connections each class has to one another. As you saw before, simply making the new cheat manager wasn’t enough. You had to make sure the DudePlayer had it’s CheatClass variable set to your new class name. What we want to do here is to put that same cheat manager class you had before in the GameTypes\Classes folder and expand it out into it’s own package.

First, you probably have the SuperCheatManager.uc file in the GameTypes\Classes directory like before. Good. Back up a notch into the Postal2 folder. Make a new folder named whatever you want your new package to be named. I’m going to call it SuperPack. Open up SuperPack and make another new folder inside that called Classes. Now, cut the SuperCheatManager.uc file from before out of GameTypes\Classes and paste it into SuperPack\Classes. We must first clean up the changes you’ve made from before—don’t worry we’ll get back to that point soon. So open up DudePlayer again and change that line in defaultproperties back to what it was:

CheatClass=Class'GameTypes.P2CheatManager'

Save DudePlayer.uc. Go into your dos window and build GameTypes.u again (with the batch file mentioned in Code Tutorial 1). You may want to run the game just to make sure everything is back to normal (run the game and type your function from before ‘SneakyShoot’, if nothing happens, then it’s been removed properly and everything should be working as before).

Now we’ve basically got the normal game, plus this extra folder group we just added. We know how to make DudePlayer use our new cheat manager, but we really don’t want to simply modify DudePlayer, right? That’s part of the original game too. So it’d be nice to extend that also into our new package. Let’s do that now.

Copy DudePlayer.uc out of GameTypes\Classes and into SuperPack\Classes and call it something like GuyPlayer.uc. Similar to the cheat manager change before, we need to make sure we extend DudePlayer and rip out everything else. This will leave us with a new class that acts identically to the old one—which is what we want for the moment. The new file should look like this in its entirety.

///////////////////////////////////////////////////////////////////////////////
// My new player controller for my great mod
//
// Player controller to use all my new and exciting things like
// the new cheat manager Ive made.
///////////////////////////////////////////////////////////////////////////////
class GuyPlayer extends DudePlayer;

defaultproperties
{
}

Obviously add better comments to help you remember things at the top of the file. But the important this is to make sure you extend DudePlayer and to call the class the same thing as the file name. If you named the file GuyPlayer.uc, then name the class GuyPlayer. If you named it CrotchMonkey.uc, make sure that first line says

class CrotchMonkey extends DudePlayer;

Trust me, if you forget and copy and paste a file and rename the filename, but don’t rename the class on the side, it will be broken and confused. Anyway, we’re still going with GuyPlayer even though CrotchMonkey is much funnier.

Now, let’s add our new cheat manager to our new player controller. Like before, down in the default props, change CheatClass to your SuperCheatManager like this:

CheatClass=class'SuperPack.SuperCheatManager'

The thing to note here is that we had to specify the class was in SuperPack and not in GameTypes. At this point you should have two files in your SuperPack\Classes folder: GuyPlayer.uc and SuperCheatManager.uc. You should not have the SuperCheatManager in your GameTypes\Classes folder anymore. Right? Goodie!

We’re going to keep going even though it might seem pretty crazy, but it’s all just to break off from the real game and start your own. It should be a very exciting prospect and you should be jacked up on adrenaline! If it’s not… well… hit your thumb with a hammer or something to release some endorphins. Excellent—I’m glad to see we’re all filled with fun-loving chemicals… so let’s jump into the next exciting section!

Now that we have our own GuyPlayer, we need to make sure the game uses him. You should always ask yourself questions like that when you make a new class—How does the game know about my new class? Is it a pickup placed in a level? Is linked to by the Postal2.ini or User.ini? Is it connected to through the default props of another class?

We must find GuyPlayer’s connection to the game. That would be through GameInfo.uc. This usually defines the game itself (it proves ‘game information’—feel free. In single-player games for us, we use it to store all the days, errands and such—hang on to your pants! We’re not modifying those just yet—maybe in a later write-up. But we are going to make our own game info. The most extended game info for single-player is GameTypes\Classes\GameSinglePlayer.uc. Copy it again to our new SuperPack\Classes folder. Rename it to something like MegaGameSP.uc. Pop it open and delete everything in between the class definition and the default properties. We want to keep the default props around just to make your life simpler later. So your file should look like this now:

///////////////////////////////////////////////////////////////////////////////
// MegaGameSP.uc
///////////////////////////////////////////////////////////////////////////////
class MegaGameSP extends GameSinglePlayer;

defaultproperties
{
          //////////////////////////////////////////////////////////////////////
          //////////////////////////////////////////////////////////////////////
          // Monday errands
          //////////////////////////////////////////////////////////////////////
          //////////////////////////////////////////////////////////////////////

          // Get Paycheck
          Begin Object Class=ErrandGoalGetPickup Name=ErrandGoalGetPickup0
                   PickupTag="PaycheckPickup"
Blah
Blah
Blah
Blah
Blah
          DefaultPlayerName="TheDude"
          GameName="Postal2 Single Player"
}

Two things:

1. Make sure your class definition line near the top is correct (it is the name of your new uc file and it extends GameSinglePlayer).
2. The Blah Blah Blah part is just me saying to keep that huge block of default properties at the bottom—right? Good. So just copy the whole thing over and save all those. But do delete all the code in between. The functions like StorChams and variables named var float NewCatTime and all that. Right? Delete all that stuff.

So you’re new file should be, basically, the class definition at the top, and a huge block of default props.

The one thing we’re going to add to those default properties in MegaGameSP is our new player controller. So add this at the bottom of the default props:

PlayerControllerClassName="<strong>SuperPack.GuyPlayer</strong>"

This sets up the gameinfo to use that controller class. But what makes the game use … the gameinfo we made? To use that we need to modify Postal2.ini.

Side note:

Two things to know about ini files in Unreal games (in case you don’t already know):

DefUser.ini makes User.ini

Default.ini makes Postal2.ini.

When you first get the game, you don’t have a User.ini or Postal2.ini. DefUser.ini gets copied and renamed to User.in and Default gets copied and renamed Postal2.ini. So for any changes you make to User or Postal2, know that you can delete those files and be okay the next time you run the game or run ucc. Just realize that any changes you made of course are now gone. I wouldn’t suggest making changes to your Default/DefUser since you couldn’t recover from anything you break in there (unless you go back to a separate back up of those files).

End side note.

Modifying the INI files

Open Postal2.ini. Do a search to find:

[Engine.Engine]

Under this header several lines down you should see:

DefaultGame=GameTypes.GameSinglePlayer

DefaultGame is your single player game, DefaultServerGame is the multiplayer game you make when starting a ListenServer.

We want to change the single player game so make that line say

DefaultGame=SuperPack.MegaGameSP

Note that I listed the package ‘SuperPack’ and the class ‘MegaGameSP’ (separated by a single period).

That ensures that the game will use our new gameinfo when running a SP game. But how do we get ucc to build our new SuperPack into a *.u file? We need to also add that to our Postal2.ini.

Do a search in Postal2.ini for ‘EditPackages’. It should show you this line:

EditPackages=Core

plus a long line of EditPackages all under the header ‘[Editor.EditorEngine]’. Each name that’s listed is a package name that ucc and the editor use to build when it tries to make *.u files. So all we need to do is add our new package to the end of this list. The order of the packages in this list is very important. If there is anything in your package that something else depends on, then basically, that dependent package must go afterwards. Because your new SuperPack is dependent on everything else and nothing depends on it (nothing extends any of your new classes) we will put it at the end of EditPackages like this:

EditPackages=UTBrowser

EditPackages=UDebugMenu

EditPackages=Shell

EditPackages=SuperPack

So, the last one will be your new SuperPack.

We have to do this one more time for the editor. Do a search again for ‘EditPackages’. In a list near the very end of the file should be more EditPackages under the header [UnrealEd.UnrealEdEngine].

Again, at the bottom of the list add SuperPack like so:

EditPackages=UTBrowser

EditPackages=UDebugMenu

EditPackages=Shell

EditPackages=SuperPack

Save Postal2.ini.

Build your new SuperPack package to make a SuperPack.u file in the System folder. After ‘ucc make’ has run, you should see the SuperPack.u file show up in your System folder. If it’s not there, check for errors in your ‘ucc make’ step (like in the ucc.log).

Run the game.

To verify that it worked, try grabbing a gun again, and typing ‘SneakyShoot’ into the console. If you kept that function your SuperCheatManager that we moved into SuperPack, then the gun should shoot with your new exec command. Another way to verify that it’s using your new MegaGameSP as the gameinfo is to open the System\Postal2.log file. The Log file is extremely useful to finding out what’s going on in the background of your game. If you open Postal2.log and do a search on ‘MegaGameSP’ it should show you this line first, if everything worked out okay:

Log: Game class is ‘MegaGameSP’

Now we didn’t do a lot of new function writing but we have something pretty cool at this point. You have a completely separate package to add to anyone else’s POSTAL 2 game. The only thing they’ll lose is their old copy of Postal2.ini. If you wanted to give someone your new stuff, you’d send them the SuperPack.u and Postal2.ini, both to be put in the System folder. The neat part is, by simply deleting the Postal2.ini you gave them; their game would be back to normal. You’re ready to add a lot of new functionality all within your own separate package so you won’t be screwing up the original .u files anymore. Well… the emphasis is on ‘you’re ready to start doing that’… basically each time you extend a new class you need to first make sure the game will use it like I mentioned earlier:

How does the game know about my new class?

Is it a pickup placed in a level?

Is linked to by the Postal2.ini or User.ini (or an *.int file)?

Is it connected through the default properties of another class? (In which case you’ll need to extend that class into your package and ask the same questions again for that new class)

Once you’ve figured this out, you need to go through whatever steps necessary to make sure your new class is being used by the game and is self-contained in your new package. Hopefully we’ll get to a few more examples in some new tutorials.

Nathan Fouts

h