Writing CFG Mods Tutorial 1 - Getting Started

Getting Started

 

A CFG, or configuration file, is a file that the game makes and reads from to store information. It is merely a text file with an extension of (.cfg).  Call of Duty savegames (SVG) and gameplay data files (GPD) are the equivalent of the PC versions config files, but hold MUCH less space. I highly recommend getting the PC version of the game by any means, as it will be much easier to test things with actual config files and the PC’s console than to keep moving your save device between your xbox and computer to test. If you are going to download it, you should start the download now so it downloads as you read.

 

As complicated as config files may become, they are comprised of only two things: commands and dvars. As with any other command, a command here will tell the game what to do. For example, the command god will tell the game to switch, or toggle, godmode. If it is off, the game will turn it on. If it is on, the game will turn it off. A developer variable, or dvar, is a setting that the game responds to. For example, the dvar player_sustainammo will tell the game whether or not shooting will cause the player to lose ammo. If its value is “1”, then shooting will not decrease ammo. If its value is “0”, then you will lose a bullet every time you shoot.

 

There are different types of dvars and different domains for each. A domain is the different values that something can have. For example, if we tried to give player_sustainammo a value of “2”, a number of things might happen. The game might do nothing and not change player_sustainammo, or it might try to find a value in the domain of player_sustainammo that is the equivalent of what we wanted. DO NOT try to set a dvar to a value outside its domain. It will result in “undefined behavior”, or, in other words, we can’t be sure of the result. Player_sustainammo is a boolean, which means it has only two values in its domain; 0 or 1. Some dvars might also accept on and off or true and false as values in the domain of a boolean, but to be on the safe side, we’ll stick with 1 and 0. Other domains include text strings, integer ranges, and color codes. We’ll talk more about this later.

So, how exactly do we set player_sustainammo? Simple, with the set command:

set player_sustainammo “1”


You could put that in a text file, save it as config.cfg, load World at War, and it would work. It’s that simple. As you can see, to set a dvar, we first type set, then the dvar, and then we put its value in quotes. The quotes aren’t an absolute necessity at this point, but they are very important in helping the game distinguish the values of something from other aspects of the code.

Set is the command being used in the example, but that entire line, set player_sustainammo “1”, is also a command. This might seem a bit confusing, as we have a command in a command – I can hear the inception music already – but it will make sense, trust me. Just as dvars have different domains, commands have different usage. As mentioned before, the command god will toggle godmode. God will work by itself; that is the entire command. Set, on the other hand, requires a dvar and a value. If you put just “set” on its own, nothing will happen. Thus, we consider the entire line set player_sustainammo “1” to be the command and not just set.

Very similar to set is bind. Bind is the command used to tell the game what we want to happen when we press a certain button. It is used in the same way as set, except that instead of a dvar we have a button, and the value is a command.

bind button_start “god”


That should be pretty self-explanatory. Button_start is the name of the start button. That command will make button_start toggle godmode. Wait a second… We said that the value of a button bind can be any command right? And we also said that set player_sustainammo “1” is a command right? So what if we did:

bind button_start “set player_sustainammo 1”


Well, we can and we do. That will the start button set player_sustainammo to 1. Uh oh… We said the command was set player_sustainammo “1” . WITH the quotes, and that they were important. Well, I wasn’t lying, they are. But here we have a problem. If we did:

bind button_start “set player_sustainammo “1


When we opened the quote for the value of the button_start bind, it told the game to make everything between the first quote and the second to be the value of the start bind. When we put the second quote, to open the value of player_sustainammo, the game will think that we’re closing the quote for the value of the button_start bind, instead of opening a second value quote. Yes this is a drawback, and yes there is a way around it, but for now just don’t use quotes inside quotes. The best way to write this is the same as before:

Bind button_start “set player_sustainammo 1”


And guess what. Remember what we talked about with set? How set by itself isn’t the command, but set along with the dvar and its value is the actual command? Well, same thing here with bind. Bind button_start “set player_sustainammo 1” is a command. Uh oh, here we go again. We could actually do:

Bind button_back “bind button_start set player_sustainammo 1”

 

Yo dawg, I heard you like commands… Yo dawg...

.

 

 

 

Congratulations, you can now set dvars and bind buttons!!


Click here to move on to the next tutorial, command strings.