Tutorial originally released on Running With Scissor's Postal website. Was taken down more than 10 years ago. Mirrored here for archival purposes.
Code Tutorials using Unreal Script for POSTAL 2
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.
If you don’t have the full Unreal Script source code for POSTAL 2 STP, download it here:
Postal2vr1407uc.exe
Unzip these files to your POSTAL 2 directory (not the system directory).
These tutorials were written assuming you already know how to program somewhat. They also assume a good knowledge of events in POSTAL 2 the game, and general terms used in Unreal-based games. There’s lots of information on using working in games if you want to brush up on that first. Don’t worry though—these tutorials start very slowly. They don't have flashy pictures though, so if you need visuals... look on the internet or something. These are straight instructions on how to code in POSTAL 2.
Tutorials:
Writing Script for POSTAL 2
From an end user’s standpoint
Code Tutorial 1
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.
Congratulations to you, proud owner of POSTAL 2! That is... if you paid for it. If you pirated it—consider your right to read this revoked! So…just stop reading this. And go pay for it. We like money.
Now… on to the show!
There’re lots of docs on how to use the Unreal Warfare editor... or some I’m told. Go find some of those. And while you’re at it—read about how to program games. I’m not going to explain that crap here.
The following is our official page for lots of other docs and our own tutorials so start here if you don’t know how to use the editor. Or you can wade into the mod forums on our site.
I guess what I’m going to explain here is how to get to the point of programming just like your favorite, star programmers here at RWS.
First, open the editor, PostEd.
Secondly, open the Actor class browser (the little chess pawn icon).
Now go to File: Export All Scripts. It will ask you if you really want to do this. It will take a while.. a minute or so on newer machines (1.5GHz+) and possibly much longer on slower machines.
You are now the proud owner of nearly our entire game code library, you little bastard! Yeah… If had that back in my day! Man! Anyway… open up the POSTAL 2 folder. Inside you should find all kinds of folders such as FX, which weren’t previously there. Click FX open. Inside will be the Classes folder. Click that open. Inside that folder is the raw, tantalizing game code complete with default properties inside.
Close the PostEd editor running in the background… you’re flying on your now.
The uc files (Unreal code? Not sure) are the script files we use to make all the things in the game. We don’t program through the editor because it’s a scary, crash prone environment. We associate uc files with Visual Studio. For the sake of experimentation, I’d say associate them with your favorite text editor—like Notepad.
Open the file ‘PistolBulletSplat.uc’. Inside should be some comments like this:
///////////////////////////////////////////////////////////////////////////////
// PistolBulletSplat.
// Bullet hole
///////////////////////////////////////////////////////////////////////////////
The class header showing what class it extends (derives from)
class PistolBulletSplat extends Splat;
Below that is a block of code you won’t see exactly in the editor. Those are the default properties.
defaultproperties
{
MaterialBlendingOp=PB_Modulate
FrameBufferBlendingOp=PB_AlphaBlend
ProjTexture=Material'nathans.skins.pistolhitblend'
DrawScale=0.15
}The default properties are the starting values for various variables in that class. In Unreal Script, when a variable is made it starts at 0, or an equivalent. Unlike C, which could have an integer start at a random number after you make it, in uc, you don’t have to worry about initializing it. (Okay, so I lied, I guess I am going to mention some programming things and uc things… oh well).
With the default props, you can decide for the variable to start at something other than 0.
For instance the drawscale starts at 0.15. That’s pretty small. PistolBulletSplat by the way is the tiny texture used to make a bullet hole on things when you shoot something (at least, for non-moving things like the ground).
For our example, how about you change this line:
DrawScale=0.15
To this line:
DrawScale=5.0
That should make the bullet holes ridiculously big and easy to recognize a change.
Save that file.
Sure you can edit those values in the editor too, but not all of them. Lots of secret, sneaky values aren’t changeable through the editor. Basically, at the top of a script file, if it’s defined like this:
var ()float HealthReduction;
instead of this
var float HealthReduction;
With the () after the var, it’ll show up in the editor. If not, you can only edit it through the actual uc file. (Whatever word is in those parentheses will be the category it shows up under in the editor actor class window. For instance, if you put
var (Health) float HealthReduction
Then that value would show up in the editor and it would be under a new category called ‘Health’.
Sorry.. detour.. but just wanted to explain why we’re going outside of the editor. Basically, with uc files we have full power. It’s a little restrictive in the editor. Anyway,… back to the bullet splats.
Now you’ve cranked them up to 5.0 in scale. We want to see the change it the game. How? We need to rebuild the package they were in. For that, we need the ucc.exe.
This builds uc files. It sure seems like it stands for ‘Unreal Code Compiler’ but hey… it probably doesn’t. No one ever told me what it means. But here’s how we use it.
We need to build the FX package. That’s the package that contains the PistolBulletSplat.uc file we modified.
Before you start firin’ you’re six-shooter all over the Creation, I’d say backup your System folder for POSTAL 2 because that’s what we’re about to starting messin’ in.
Open the Postal2/System folder. In the folder change the View to Details and make sure you can see file extensions. Now, sort by Type. This will put all the exe’s at the top and the ‘.u’ files at the very bottom. Very handy. (Obviously, this is just my convention, but it made it easier for me to manage things).
Next is not an arbitrary convention—this how to actually build the file.
Packages go into ‘.u’ files. Fx.u is the file we’re concerned with. Delete that file.
Open a dos window.
Navigate to your postal2/System folder in the dos window. That’s where the ucc.exe file is.
Type:
ucc make
in the dos window.
It should scroll by with something like this:
--------------------Core - Debug--------------------
--------------------Engine - Debug--------------------
--------------------Fire - Debug--------------------
--------------------Editor - Debug--------------------
--------------------UWindow - Debug--------------------
--------------------UnrealEd - Debug--------------------
--------------------IpDrv - Debug--------------------
--------------------UWeb - Debug--------------------
--------------------FPSGame - Debug--------------------
--------------------BaseFX - Debug--------------------
--------------------Postal2Game - Debug--------------------
--------------------MultiBase - Debug--------------------
--------------------MoreGame - Debug--------------------
--------------------FX - Debug--------------------
Analyzing...
Parsing Wind
Parsing UrineBucket
Parsing MachineGunBulletSplat
Parsing PistolBulletSplat
Parsing ShockerBurnSplat
Parsing ShotGunBulletSplat
Parsing GasBodyDrip
Parsing GasHeadDrip
Parsing GasSmallBodyDrip
Blah
Blah
Blah
blah, etc.
It first parses the files, then compiles them. Ucc only makes new .u files that are not there but are supposed to be there. For instance, if the FX.u file is missing, it builds it. You must delete it each time you want to build a change. The files listed like this:
--------------------Postal2Game - Debug--------------------
are the ones it expects to be there. Again, only if they’re deleted will the ‘ucc make’ line recreate them.
Now that you’ve run it, assuming you didn’t create a type-o in the file when changing the drawscale, Fx.u should be rebuilt.
Now, run the game and see if the bullet holes a way too big!
This next section turned out to be a lot longer than I expected—it is just a sidebar, but I think it’s useful and deserves some attention:
(For testing purposes, I’d suggest making a ‘test box’ with the editor. We make lots of them as programmers. They’re really ugly, but they use few resources and load much faster than normal. So make something like a box 5000x5000x5000, put a PlayerStart in the middle and name it. Now, on the command line in your dos window, all you’ll have to do is type ‘postal2 textbox.fuk’, and it will run your tiny little test level. Of course if you’re testing weapons or something, put weapon pickups in there, or just give yourself weapons each time with the ‘iamsolame’ cheat. The point is, between using a small test level and by skipping the intro menu (which is a level itself that needs to load) you can save a lot of time testing your work. Read this very carefully: You must make sure though, that the pawn class you’re using is the correct one. What does this mean? It means the character that you play as can change. How? If you’ve been playing a MultiPlayer game, and then decided to work on some code of your own—your player class will be wrong. That is, it will be wrong only if you decide to use my new-fangled console command method of running a level. If you open the menu and open a custom level and run—that’s fine. You’re player class will be set correctly. But it won’t necessarily if you have run a MP game since the last time you coded. There’s a simple and easy way to fix it and you might as well get used to knowing about this sort of thing. Open your User.ini file (use notepad or your editor). At the very top are three lines looking something like this:
[DefaultPlayer]
Name=Player
Class=People.PostalDude
team=0
At least that’s what it should look like out of the box. And that’s the way to make it look if you’re doing any coding but have played MP games prior! So if you played an MP game it would probably look something like this:
[DefaultPlayer]
Name=PH34rMeHaXX0rz
Class=MultiStuff.MpGary
team=0
See how it doesn’t say People.PostalDude? Yeah, well, make it say that instead of MultiStuff.MpGary (that means you simply picked to play as gary in a MP game). That’s the important part if you’re running the game from the command line. I don’t care about whatever user names you kids come up with.
Oh, and we’ve tried to fix this before, and as of this tutorial writing—it hasn’t been fixed yet, so I’m just letting you know what we do here.)
Crazy sidebar has ended—back to the tutorial!
Okay, so you grabbed a pistol, shot at the ground—and holy shit—the bullet holes are way too big!! Kickass!
Yup, you now have god-like powers.
Where to go from here? Hmm… not sure… really anywhere. I would suggest making subtle changes to different weapons/items/things in the game to see what happens. Of course, only make a change or two at a time to not screw up too much.
Oh, speaking of which, the ucc compiler is pretty shitty giving you feedback. If you mistype something in a default property for a uc file, you probably won’t be told about it. So you just have to guess about why things are wrong… that even means if you do something silly like put a letter when it expects a number.
Of course if you screw something up in the actual code above (not in the default properties) it will usually tell you something, which is nice.
For instance, I just randomly stuck an ‘s’ under the class header in PistolBulletSplat.uc. This is what it says after I did a ‘ucc make’.
Log: Parsing Wind
Log: Parsing UrineBucket
Log: Parsing MachineGunBulletSplat
Log: Parsing PistolBulletSplat
Error: C:\projects\Postal2\prog\WARFARE\FX\Classes\PistolBulletSplat.uc(6) : Error: Unexpected 's'
So… it noticed it. The weird thing is, the output to the dos window is actually not all the output data. Once ucc is finished, you can open a file in your System folder called ucc.log. This gets made each time you run the ucc program. In there will potentionally be more errors… things like missing textures and such. It’s not great… but if things aren’t working and you don’t know why, you may open that too and see.
Also with ucc, if you modified a uc file in the Fx.u package and you changed a file in the Weapon.u package then you can build several at once. All you have to do is delete them both. Then type ‘ucc make’ again and it will build them all. Just be very careful with Core and Engine files. In fact, here is a list of all packages that are important POSTAL 2 packages (.u files):
AIPack.u
BaseFx.u
BasePeople.u
FPSGame.u
GameTypes.u
Inventory.u
MoreGame.u
MultiBase.u
MultiGame.u
MultiStuff.u
People.u
Postal2Game.u
Shell.u
Any and all of those you can usually modify without many problems. I would suggest not modifying any engine packages. Especially not Core and Engine. You can basically paint yourself into a corner—you’ve been warned.
One more note about your ‘programming environment’. That would be Visual Studio, notepad, word, some html program… whatever you want to use to edit uc files. The real use of Visual Studio (Microsoft editor we originally used with C/C++) to us here at work is that it helps us keep all those uc files organized. The other huge help is that you can do lots of searches on all the uc files. Being able to search through all uc files in the game for a keyword like ‘bGodMode’ is critical—at least when you to programming a lot of stuff. Starting out it may not be. Now, obviously you can do this with windows—search for a keyword through a lot of files, it just is a little more cumbersome and doesn’t display the results as nicely. Trust me, if you’re really getting into this and then you should look around for a free program that let’s you edit text and let’s you search through lots of files at once somehow displaying the results inside the program. I know there are lots of free programming environments out there for Turbo Pascal and the like. You may try some of those. Please confer amongst yourselves on the message boards for what works best! Working in PostEd is not the way to go. Trust me… you’ll have much more control, power, and speed working with the direct uc files that you’ve exported from PostEd. If you end up getting some other programming language’s editor as you programming environment for uc files just realize—that’s perfectly fine. While that editor may come with it’s own compiler for Pascal or something your compiler is the ucc program. So all you need is the text editing side of things.
Once you have a good text editor all you need to do is write the code in your editor, alt-tab to the System folder to delete the .u file for the package you’re working in (like the Fx.u package) then alt-tab to the dos window to type ‘ucc make’.
You may even find it useful to write a little batch program for each package that goes with POSTAL 2 (the thirteen packages I mentioned above). Something like this should do the trick:
del %1.u
ucc make
Put that in a batch file called something like ‘MakeIt.bat’. Then all you have to is type ‘makeit fx’ in the dos window. You can now skip the ‘delete the file in the System folder’ step!
Now you’re ready to program just about whatever you want for POSTAL 2. You’re best bet is probably lots of experimentation.
(Don’t forget to change your bullet splats scale back to 0.15!)
Nathan Fouts
nice ez tutorial for beginners