Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Console commands and variables
List of Bunnymod XT’s console commands and variables.
If set to 1, pauses the game automatically on load. This is useful for segmented speedruns and TASes.
Switch this to 1 only when using TASView.
Resets the IPC. Use if TASView or BunnySplit integration breaks for some reason (should never happen).
- w <number>
numberof waits. For instance,
w 3is equivalent to
wait;wait;wait. Note that a space between
wand its argument is mandatory, because
wis used like a normal command. If no argument is supplied, then only a single
waitwill be issued. This command eliminates the need to build and initialize a massive wait table.
At most, how many times per second to send time updates to BunnySplit. Doesn’t affect autosplits (they are always accurate).
If set to 1, the in-game timer started by
bxt_timer_startwill stop automatically on game end events as specified by the speedrunning rules (like Nihilanth’s death for Half-Life). Not all games and mods are supported.
Starts the in-game timer.
bxt_hud_timermust be enabled for the time display to appear on the screen.
Stops the in-game timer.
Stops and resets the in-game timer.
- bxt_record <filename>
record filenameas soon as possible. For example, you can use it like this:
map c1a0;bxt_record demo. If you were to use the normal
recordhere it wouldn’t work because the map wouldn’t have been loaded by the time the command is executed.
- bxt_autorecord <filename>
bxt_record, but records
filename_3, and so on, each time a save is loaded. For instance,
map c1a0;bxt_autorecord demowill cause
demo_1to begin recording as soon as possible. If you then load up a save,
demo_1will stop and
These commands require
sv_cheats 1. They are meant to be used for planning purposes only. Using these commands in any real speedrun will result in an instant loss of all respect from everyone.
- bxt_ch_set_armor <armor>
Sets your armor to the specified value. This is useful when trying to clear the armor completely without damaging oneself manually.
- bxt_ch_set_health <health>
Sets your health to the specified value. This is useful for damage boosting where one wishes to observe how the velocity changes as a result of the damage received without worrying about death.
- bxt_ch_set_pos <x> <y> <z>
Sets your position to the specified coordinates.
- bxt_ch_set_pos_offset <dx> <dy> <dz>
Offsets your position by the specified amount. This is equivalent to adding
dzto the current position.
- bxt_ch_set_vel <vx> <vy> <vz>
Sets your velocity components to the specified values. This is useful for simulating damage boosting without doing the actual boost manually and worrying about the health.
- bxt_ch_set_vel_angles <magnitude>
Sets your speed (i.e. the magnitude of velocity) to
magnitude, and sets the direction of your velocity to where you’re currently looking at. If
bxt_hud_velocityis enabled, the XYZ speed should have the same value as
- bxt_ch_set_vel_angles <pitch> <yaw> <magnitude>
Similar to the one argument version of
bxt_ch_set_vel_angles, except the direction of your velocity will be pointing towards the specified angles, independent of your current viewing angles.
Force the game to render the entire map, disregarding the PVS, allowing you to see more entities beyond the obstacles under
bxt_wallhack. With this enabled, the frame rate will likely be affected. The game may also crash due to too many entities being rendered.
Good ol’ wallhack, allowing you to see entities and brushes through walls. This is useful for TASing or planning routes, when you want to observe what is happening behind some obstacles. By default, you cannot see very far behind obstacles due to the game only rendering planes within the PVS. To see the entire map, enable
bxt_novis. You may also turn on
bxt_wallhack_additivewhich may help making some entities more highlighted.
Enable to make scenes render in additive mode under
bxt_wallhack. This may allow easier viewing of some entities or brushes.
- bxt_wallhack_alpha <alpha>
Adjust the alpha transparency level of planes when wallhack is enabled. The
alphalevel should be between 0 and 1.
Controls the bunnyhop speed cap. 1 means it’s enabled, 0 means it’s disabled. You cannot add a bhop cap if it wasn’t already in a mod.
Should be usually set to the same as
bxt_bhopcap. Same as above, but clientside. This especially matters when you’re playing on servers - set accordingly to the presence of the bhop cap on the server in order to eliminate lag.
Use this instead of
+jumpfor automatic jumping. This is guaranteed to be legitimate, in contrary to
bxt_autojump, and is therefore the preferred way.
When held, ducks automatically when you’re on ground.
When held, performs jumpbugs automatically. Note that you still need to get the correct positional alignment for a jumpbug to be possible. You can test this command with
host_framerate 0.001which guarantees that a jumpbug is possible under otherwise default settings.
If 1, you jump automatically when holding your jump key.
Should be usually set to the same as
bxt_autojump. Controls the autojump clientside prediction.
Limits how high the frame rate at which the game can render. This CVar accepts a frametime parameter, which is the inverse of frame rate. For example, if the supplied parameter is 0.01, then the game will not render faster than 100 FPS. If
host_framerateis nonzero, then this does not affect the frame rate at which game physics are run: it merely affects the rendering frame rate. This is useful for TASing, because if
host_framerateis large, the game will appear to speed up. This makes it hard to observe what is happening. By specifying an appropriate limit to how low the frametime can be (i.e. how high the frame rate can be), the game will render at a comfortable speed. This CVar is ignored if
Prevents the game from rendering anything to the screen. This can be considered a stronger version of
r_norefresh. While the latter prevents the screen from refreshing, it still allows the engine to draw on the screen. With
_bxt_norefresh 1even the drawing is disabled, resulting in even higher rendering frame rates when it is enabled. This is useful for speeding up sections when TASing to cut down on iteration times.
Reset the client-side view camera to normal when altered by
- bxt_cam_fixed <x> <y> <z> <pitch> <yaw> <roll>
Fixes the client-side view camera to the specified coordinates and points the camera to the specific viewangles. Once this is done, any player movements or viewangles changes will not affect the camera. This is done purely client-side, so it doesn’t affect the game physics. This is useful in TASing when one wishes to observe a scene that is located a long distance away or is obstructed. For instance, toggling a button may cause a door somewhere to open. To observe the door opening in action, one uses
bxt_cam_fixedto point the view at the door when the button is pressed.
- bxt_cam_offset <x> <y> <z> <pitch> <yaw> <roll>
bxt_cam_fixed, except the client-side view camera is offset from the current player position and viewangles and not fixed. For instance,
bxt_cam_offset 0 0 0 0 180 0causes the camera to always look backwards no matter where the player is located. This is useful for observing what is happening behind one’s back when TASing.
Removes all screen fades. The usefulness of this CVar is obvious: fades are annoying because you cannot see what is happening.
Visualizes non-trigger entities that are invisible during normal gameplay but nevertheless exist. This CVar accepts 0, 1, 2, or 3 as its sole parameter. The default is 0. In general, the higher this the value, the more hidden entities will be made visible. These hidden entities may or may not be solid.
Visualizes AI nodes that are placed in the map by the map designer. These nodes are critical in directing NPC movements. For instance, the path a scientist takes to run away when being attacked by the player is controlled by the AI nodes. Typically, the game would attempt to select a series of nodes so that the NPC takes the hopefully shortest path to some destination. An NPC typically goes from node to node until it reaches the destination.
Visualizes trigger entities without them getting saved in demos. Different trigger types are displayed in different colors. Most triggers pulsate, while inactive triggers do not and will be displayed in dimmer colors. Examples of triggers that could be inactive are push and hurt triggers. If this does not work, try
bxt_show_triggers, except using an older method of displaying triggers. Triggers displayed using this method will get saved in demos, and removing them from demos is non-trivial. In addition, triggers do not look truly translucent when obscuring other triggers. That is, you cannot see triggers through an obstructing trigger in front. Despite these drawbacks, this method should work on a larger array of Half-Life versions.
Uses collision ray tracing to display the collision depth map. Warning: VERY slow and somewhat skewed.
Maximal depth to visualize on the depth map. Anything beyond this will have the same color. Adjusting this value is useful for having more detail close by vs. having a bigger picture across a wide range of depths.
If turned on, visualizes differently angled planes in different colors rather than showing the depth.
The collision hull to visualize:
0: the standing hull (collision for the standing player);
1: the ducked hull (collision for the ducked player);
2: the point hull (this is what bullets and other projectiles use).
The point hull looks the most like the regular map, and the other two hulls have every wall extruded outwards resulting in all holes becoming smaller. Ideally, tracing a point against the standing or the ducked hull gives the same result as tracing a cuboid with the size of a standing or ducked player against the point hull, which is why everything is extruded in the standing and the ducked hulls.
The following settings control how certain custom elements are displayed.
Controls whether the custom HUD elements should be drawn. The default is 1.
Specifies the color in which sprite-based custom HUD elements are drawn. The parameter may be of the format "R G B", including the double quotes, where R, G and B are numbers between 0 and 255. R is the red component, G is the green component, and B is the blue component. For instance, "0 255 128". Alternatively, give an empty parameter or the text auto to specify the default yellowish color.
Specifies how many digits to be printed after the decimal mark. The default is 6. Note that this is not the same as the number of significant figures. While it may make the user feel good, printing more than the default number of digits is most often an exercise in futility even when planning.
The search radius for
bxt_hud_useables. The default is 64, which is the default search radius the game uses to determine if an entity is close enough to be used. Only entities within this radius will be marked when `bxt_hud_useables`Yeah is enabled.
The following settings universally accept either 0 or 1 to control if the associated HUD element should be drawn. By default, they are positioned in sensible locations on the screen deemed by the developers. The positions can be offset from the default as described further down.
Displays the horizontal, vertical, and the 3D distances from your eyes to the point on the surface under the crosshair. This may be used for quick-and-dirty range finding without resorting to map viewers. For instance, knowing the distance from one point to the other can be important in deciding how much health should be devoted to damage boosting for that particular line segment. In practice, precise measurements are very rarely needed.
Displays the health of the entity under the crosshair. Most entities have a health of zero, especially if they are not damageable. The health information can alternatively be obtained by running
impulse 103in the console only on entities with AI. Such entities include the scientists and barney guards. Nevertheless, it is much more convenient to have this information displayed on screen. This HUD element has obvious use for planning.
Displays the speed recorded immediately after the previous jump. Objectively, this is far from being a useful measurement, but many find it psychologically beneficial to enable this HUD element.
Displays your position in the current map relative to the global origin. While this information can also be obtained by running the
statuscommand in the console, it is more convenient to have it displayed on the HUD. In practice, TASers find the z position most useful. The line "Origin:" will be in red if the displayed position is imprecise. This can happen when viewing demos, for example.
Displays the maximum possible damage your gauss can fire in secondary mode in order to trigger a selfgauss on the point under the crosshair. In other words, if the weapon fires a secondary beam with a damage higher than the displayed value, then no selfgauss will occur. In addition, displays which part of your body will the gauss beam hit. By knowing the damage, you can trivially calculate the required charge time using an equation. The body part information is mostly used to check if the beam is going to headshot yourself. This is important because headshots by default deal three times more damage and thus giving you three times more vertical speed after selfgaussing.
Displays a sprite-based HUD element indicating your horizontal speed. This is useful for human speedrunners because of its large text.
Displays the absolute health without overflowing and can display HP bigger than 255.
Displays information about Nihilanth’s current AI state. Health shows the Nihilanth’s health. The lower the health, the higher the animation speed, which in turn causes Level to increment faster.
Level increments after each Nihilanth animation sequence (e.g. attack, turn left, prayer) until it reaches 10, at which point Nihilanth’s head will open.
Irritation can be 0, 1, 2, or 3; if 0, Nihilanth does not attack; if 1, Level will increment from time to time; if 2, Nihilanth’s head is open; if 3, Nihilanth is dead.
Recharger indicates whether Nihilanth has found a health recharger crystal, allowing him to use it.
Spheres shows how many active spheres Nihilanth is currently holding. It goes from 0 to 20. Note that this number may not correspond to the number visual sprites floating around Nihilanth’s head. Spheres is helpful in an optimised run, because if the player saveloads when there are 10 or fewer spheres remaining, the rest of the spheres will be nullified, instantly causing Nihilanth to lose all health spheres. This in turn reduce the amount of damage needed to inflict upon Nihilanth to minimise its health, for reasons explained above.
Displays a sprite-based timer which can be controlled with
Marks all useable entities on the HUD within a radius from the player. The one entity that will actually get used when the use key is pressed is marked in a different color. This HUD element can help in looking for entities that are useable across walls without manually testing them with the use key. The search radius is controlled by
Displays the precise horizontal, vertical, and 3D velocities. Just like the position HUD element, the line "Velocity:" will be in red if the displayed velocities are imprecise.
Displays your yaw and pitch angles in degrees relative to the global axes. This is mostly useful for TASing. The roll angle is not displayed as its effects are usually cosmetic.
Displays a list of landmarks that can "see" you at your current position. Namely, you are contained in the PVS from the point of view of each landmark on the list. These landmarks are responsible for moving entities across levels. This HUD element is thus very useful for determining if you will lose your weapons after doing a changelevel delay and allowing the game to transition at your current position. Suppose some landmark A is associated with a transition into the next map. If A is in the list, then you will not lose your weapons if the game transitions while you are at your current position. On the other hand, if its name is not on the list, then you will lose all your weapons.
For each custom element setting, there are two associated settings used for controlling its position. Their names are the main CVAR name appended with
_offset respectively. For example, to control the position of the speedometer, you need to adjust the values of
_anchor settings accept two floating point numbers enclosed in double quotes. The floating point numbers are usually between 0 and 1. On the other hand, all
_offset settings accept either an empty parameter or two integers, both of which are enclosed in double quotes.
All custom HUD elements are anchored to a point on the screen and offset from that point. The anchor point is the location on the screen as a proportion of the screen width and height. For example, the speedometer by default has an anchor of "0.5 1". This means the element should be anchored to horizontally halfway across the screen, and vertically at the bottom of the screen.
The offset settings are used to offset the associated element from the anchor point. Using the speedometer example again, if the offset specified is "10 -5", then the element will move to the right 10 pixels and up 5 pixels, relative to its anchor point. If the offset setting is empty, then the default offset will be used instead, which may not be "0 0".
- bxt_tas_loadscript <filename>
Loads the specified .hltas script and starts executing it.
Resets the frametime remainder. Put this in your TAS starting binds to get rid of frametime overflow inconsistencies.
Toggles TAS logging.
- bxt_taslog_filename <filename>
Sets the output file for
map, but doesn’t get called on
stuffcmdsif specified in the launch arguments. Useful for running TASes from the launch arguments.
load, but see
Converts a .hltas to an "exported" version without any autofuncs: strafing, autojump, etc. are replaced with raw button presses.