vbsp_config

Overview

vbsp_config is the main config file for the compiler. It defines all the transformations which occur, and all the options set in items. The final file is produced by joining together all the sub-files in each item, style, and other object as appropriate. There are many top-level blocks, all with different purposes.

Special Filenames

In many vbsp_config values, special names can be used to refer to instances set in editoritems, so the same config can apply to multiple styles and prevent duplicating long strings. This takes the form: <ITEM_ID:1,2>, <ITEM_ID_2:standard> The numbers match the number set in the Instances section of editoritems. Leave out the numbers and colon to refer to all of a certain ID. In a value, multiple item IDs can also be given. Depending on the function, some options may accept only one instance filename (if setting a value) or multiple (if filtering/searching for things). For some item types, certain keywords can be used instead of (or in conjunction with) subtype indexes:

• Cube:
  • standard: Normal cube.
  • companion, comp: Companion cube.
  • reflect, redirect, reflection, redirection, laser: Laser cube.
  • sphere, edgeless, ball: Edgeless Safety Cube.
  • franken, monster: FrankenTurret.
• Floor Button:
  • weighted_, floor_, cube_, sphere_, ball_, edgeless_ + white or black: A specific button instance.
  • btn_weighted, etc: Both colours.
  • btn_black, btn_white: A button of that colour, of any type.
• Track platforms:
  • track_bottom_grate: Grating at the base of enclosed platforms.
  • track_bottom, track_middle, track_top: Three parts of the track.
  • track_single: 1-large track.
  • track_plat, track_platform: Non-oscillating platform.
  • track_platform_oscillate, track_plat_oscil: Oscillating platform.
  • track_plats or track_platforms Both platform types.
  • track_rail: Bottom, middle, top and single track components.
• Funnels:
  • fun_emitter: The functional emitter part.
  • fun_white: White frame.
  • fun_black: Black frame.
  • fun_frame: Frame in either colour.
• Fizzlers:
  • fizz_base: Base logic.
  • fizz_mdl, fizz_model: Emitter model.

In addition, there are a number of special predefined name lists (delimited by [square brackets] instead of angled brackets). These are used to identify things like the elevators, instead of remembering the specific indexes and item IDs. For corridors, add a number to choose a specific version instead of all of that type.

• [glass_128]: Glass/grating clips section.

• [glass_left_corner]

• [glass_left_short]

• [glass_left_straight]

• [glass_left_convex_corner]

• (Also glass_right_ and glass_ versions of the above)

• [coopExit]: Coop Disassembly Room

• [coopEntry]: Coop Spawn Room (inside the main map)

• [elevatorEntry], [spEntry]: Entry Elevator

• [elevatorExit], [spExit]: Exit Elevator

• [spExitCorr], [spEntryCorr]: SP entry or exit corridors.

• [coopCorr]: Coop exit corridors.

• [indToggle]: Antline toggle instance.

• [indPanCheck], [indPanTimer]: Different indicator panel types. Default PeTI doesn't do this, but these can be different instances.

• [indPan]: Both indicator panel types.

• [transitionEnts] : Transition instances for map start and stop, plus some essential globals.

• [laserEmitter], [laserCatcher], [laserRelay]: Both the center and offset instance for those items.

• [door_frame_sp]: SP door frames.

• [door_frame_coop]: Coop door frames.

• [white_frame_sp], [black_frame_coop], etc: Black/White SP/Coop door frames.

• [door_frame]: Any entry/exit door frame.

• [white_frames]: White frames only

• [black_frames]: Black frames only

Replacements

Often, different styles or other variations require only slight changes to be made to config files. The replacement variables system allows this to be done. For any value that needs to be changed, replace it with a %REPLACEMENT_VAR% in names or values (other text can be before or after to concatenate values together). Then add a Replacements block, which has variable as keys, and defaults as values:

"Replacements"
	{
	"%REP_VAR1%" "False"
	"%ANOTHER_VAR%" "instances/BEE2/generic.vmf"
	}

To override, simply arrange in configs to append an additional Replacements block with different values. The last occurrence overrides previous values, so they will not be used.

General style options

This sets many style-specific options, which changes how the compiler behaves for each style. This is generally only set in each style, but can be also set in items. All options either have a default value or are optional.

The format is very simple:

"Options"
	{
	"Option Name" "Value"
	}

List of all options

Conditions

Conditions are the primary means of modifying items and instances. Conditions effectively work like basic IF statements, where Flags refer to the various conditions required to succeed, and Results define the outcome. The syntax is:

"Conditions"
	{
	"Condition"  
		{
		"Priority" "0" 
		"flag1"	"value"  
		"flag2"	"value"  
		"result"  
			{  
			"Result1"	"value"
			"Result2"
				{
				...
				}
			} 
		"else"
			{
			"Result1"	"value"
			"Result2"
				{
				...
				}
			}
		} 
	"Condition"
		{
		...
		}
	}

All of the toplevel Flags must evaluate to true for the condition to be executed. Every instance in the map has each condition evaluated on it. Some results will be removed if they can only be executed once. If no results are left, the condition itself is deleted. If no flags exist, the condition always executes. If the condition has an else block, that section will be executed instead if the condition flags fail.

Two special results are the Condition and Switch results. Condition tests a sub-condition after the parent succeeds. This allows for trees of decisions to be performed. Switch tests a single flag with multiple configurations, and exectutes different results for each. As a special case, Condition, ElseCondition, Switch and ElseSwitch can be placed on the same level as a Result block to reduce excessive indentation in files. The Else form triggers if the condition fails instead.

See the list of all Conditions for config options.

Metaconditions

"Metaconditions" are additional conditions automatically run in the compiler. These are not directly configurable, but do have a priority value. This allows running other conditions before or after the specific event.