A Sonic Object Configuration, abbreviated as SOC, is a type of text file for SRB2 that allows users to change several game settings in the source code without any programming knowledge. It can be created with the SRB2 SOC Editor. This allows for easy modification of the game and makes it flexible for the use of addon files.
There are three basic groups of SOC files that serve different purposes: Hence the name, the main feature of SOCs is the ability to control all Objects in the game, including their interaction with the environment and the sprites they display. With the use of a SOC file, new Objects can be created, and the behavior and appearance of existing Objects can be changed. The second group modifies several global settings that have to do with the appearance of the game, such as the unlockables system, cutscenes and level headers. These SOCs are generally found in level packs. The third group applies to character WADs, whose properties are defined through SOCs as well.
Contents |
SOCs are structured as simple text files in which any changes from or additions to the default game settings are specified as raw text. The text must follow a specific formatting, but its structure is rather simple: Each section has a header that defines what it does, and then each property is listed in its own line (sometimes written out in capitalized letters, but the values are not case-sensitive), followed by an equal sign and a variable (i.e., MusicSlot = 0 or MAPTHINGNUM = 100).
SOCs can be created with a text editor like Notepad, and are saved with the extension .soc. Alternatively, the SRB2 SOC Editor can be used, which provides a Graphical User Interface and supplies additional information on how to use many settings as well as their standard values in the source code.
One common method to load SOCs is to use the commands ADDFILE or RUNSOC in the console once SRB2 has been started. Another method is to add the SOC using the SRB2 Launcher. When loading a SOC file, the values found in the source code are overwritten with the custom ones, and the changes take effect as long as it is loaded. SOC files can also be integrated into WAD files as lumps, in which case they are automatically loaded with the WAD file. This allows for modifications with custom unlockable systems and global game settings. For more information on this method, see the MAINCFG section below.
The Object configuration system is one of the three main parts of the SOC format. All Objects in the game can be controlled and modified with simple text files due this feature. This allows, within limitations, to alter the gameplay mechanics of SRB2 and to create new custom scenery and enemy Objects. However, many mechanics found in SRB2's default Objects cannot be replicated with SOCs, due to the rather inflexible implementation of the Object system, which relies heavily on hard-coded features that only work in the situation they were made for.
The structure of the Object configuration system is best illustrated through a hierarchy. It consists of several distinct elements that build on top of each other to control the behavior of in-game Objects:
Thing 1 MAPTHINGNUM = 100 SPAWNSTATE = 63 SPAWNHEALTH = 1 SEESTATE = 65 SEESOUND = 0 REACTIONTIME = 32 ATTACKSOUND = 0 PAINSTATE = 0 PAINCHANCE = 200 PAINSOUND = 0 MELEESTATE = 0 MISSILESTATE = 0 DEATHSTATE = 1641 DEATHSOUND = 119 XDEATHSTATE = 0 SPEED = 3 RADIUS = 1572864 HEIGHT = 2097152 MASS = 100 DAMAGE = 0 ACTIVESOUND = 0 RAISESTATE = 0 FLAGS = 16777221
This is a sample of an Object block that can be found inside a SOC. In consists of a header which assigns an identification number to the Object, and a list of values that define its properties. The list of properties must be in this order, although values with zero can be left out. As can be seen here, Objects, States, Sprites and Sounds are all given identification numbers for easy reference. While they all have regular names, the identification numbers must be listed in SOC files, and either the SRB2 SOC Editor or the corresponding list articles must be used to assign one to the other. The flags value is calculated by combining the individual values of each chosen flag. Again, the SOC Editor provides a Graphical Interface for easier reference. The other values in this block are purely mathematical and are not identification or reference numbers.
FRAME 65 SPRITENUMBER = 1 SPRITESUBNUMBER = 0 DURATION = 3 NEXT = 66 ACTION A_Chase VAR1 = 0 VAR2 = 0
This is a corresponding sample of a State block that can be found inside a SOC. State and Object blocks are the two most commonly used blocks for SOC files, although in some cases Sound blocks might also be used. These two, however, are enough to create fully working Objects or modify the behavior of existing ones. This is the SeeState used by the Object referenced above. The sprite number is, again, an identification value that substitutes the real name of the sprite. The NEXT value references which state follows next. The action is the only part of a SOC that is actually referenced by name and not by an identification number. Var1 and Var2, which are not used here, as well as the duration, are numerical values.
These articles list the available Objects, States, Sprites and Sounds in SRB2, for easy reference. These tables include the identification numbers, the real names, and descriptions for each elements.
The MAINCFG is a WAD file lump that contains SOCs. The MAINCFG is essentially the second big element of the SOC format, and is separate in purpose and function from the Object configuration. It serves as the control lump for the global game settings for any modification, and changes certain aspects of the game to better suit the addition of custom WAD files. This allows level packs in particular to work in their own environment and essentially as whole different game.
The MAINCFG is put into WAD files and once those WADs are loaded, the SOCs inside this lump are automatically run. You can import a SOC file using a lump editor like XWE. Once you import the SOC, you would rename the imported lump into MAINCFG. If the lump doesn't look right, you can rename the MAINCFG SOC to MAINCFG.TXT.
There are five big categories that the MAINCFG can be divided into:
MAINCFG. Here, global game settings are specified, such as the timers of various power-ups, the location of the Special Stages and the first Single Player stage, the name of the gamedata and save files, and the number and locations of emblems. This section must be part of the MAINCFG, and is required for modifications with custom save files and unlockables.
MAINCFG.
MAINCFG, but can also be supplied in separate lumps.
While playable character addons mainly consist of custom sprites, their functionality is controlled with two SOC lumps. The OBJCTCFG serves as a properties lump for them, defining their name and description in the character select menu. The abilities and stats of the character are defined in a different SOC lump called S_SKIN1. With this system, custom characters with different abilities and physics that the three main characters can be created. Apart from the abilities supplied in the main game, it is possible to create new abilities with the use of Object configurations. For a guide on this method, see the Custom Ability Tutorial.