Console commands and variables

Chong Jiang Wei edited this page Sep 23, 2018 · 12 revisions

List of Bunnymod XT’s console commands and variables.

General

bxt_autopause

If set to 1, pauses the game automatically on load. This is useful for segmented speedruns and TASes.

bxt_interprocess_enable

Switch this to 1 only when using TASView.

_bxt_interprocess_reset

Resets the IPC. Use if TASView or BunnySplit integration breaks for some reason (should never happen).

w <number>

Equivalent of wait;wait;...;wait with number of waits. For instance, w 3 is equivalent to wait;wait;wait. Note that a space between w and its argument is mandatory, because w is used like a normal command. If no argument is supplied, then only a single wait will be issued. This command eliminates the need to build and initialize a massive wait table.

Run management

Timing

_bxt_bunnysplit_time_update_frequency

At most, how many times per second to send time updates to BunnySplit. Doesn’t affect autosplits (they are always accurate).

bxt_timer_autostop

If set to 1, the in-game timer started by bxt_timer_start will 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.

bxt_timer_start

Starts the in-game timer. bxt_hud_timer must be enabled for the time display to appear on the screen.

bxt_timer_stop

Stops the in-game timer.

bxt_timer_reset

Stops and resets the in-game timer.

Recording

bxt_record <filename>

Invokes record filename as soon as possible. For example, you can use it like this: map c1a0;bxt_record demo. If you were to use the normal record here it wouldn’t work because the map wouldn’t have been loaded by the time the command is executed.

bxt_autorecord <filename>

Similar to bxt_record, but records filename_1, filename_2, filename_3, and so on, each time a save is loaded. For instance, map c1a0;bxt_autorecord demo will cause demo_1 to begin recording as soon as possible. If you then load up a save, demo_1 will stop and demo_2 will begin.

Cheat commands

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 dx, dy, and dz to 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_velocity is enabled, the XYZ speed should have the same value as magnitude.

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.

bxt_novis

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.

bxt_wallhack

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_additive which may help making some entities more highlighted.

bxt_wallhack_additive

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 alpha level should be between 0 and 1.

Movement

bxt_bhopcap

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.

bxt_bhopcap_prediction

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.

+bxt_tas_autojump

Use this instead of +jump for automatic jumping. This is guaranteed to be legitimate, in contrary to bxt_autojump, and is therefore the preferred way.

+bxt_tas_ducktap

When held, ducks automatically when you’re on ground.

+bxt_tas_jumpbug

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.001 which guarantees that a jumpbug is possible under otherwise default settings.

bxt_autojump

If 1, you jump automatically when holding your jump key.

bxt_autojump_prediction

Should be usually set to the same as bxt_autojump. Controls the autojump clientside prediction.

Visuals

_bxt_min_frametime

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_framerate is 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_framerate is 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 _bxt_norefresh is enabled.

_bxt_norefresh

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 1 even 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.

bxt_cam_clear

Reset the client-side view camera to normal when altered by bxt_cam_fixed or bxt_cam_offset.

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_fixed to point the view at the door when the button is pressed.

bxt_cam_offset <x> <y> <z> <pitch> <yaw> <roll>

Similar to 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 0 causes 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.

bxt_fade_remove

Removes all screen fades. The usefulness of this CVar is obvious: fades are annoying because you cannot see what is happening.

bxt_show_hidden_entities

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.

bxt_show_nodes

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.

bxt_show_triggers

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_legacy.

bxt_show_triggers_legacy

Similar to 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.

bxt_collision_depth_map

Uses collision ray tracing to display the collision depth map. Warning: VERY slow and somewhat skewed.

bxt_collision_depth_map_max_depth

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.

bxt_collision_depth_map_colors

If turned on, visualizes differently angled planes in different colors rather than showing the depth.

bxt_collision_depth_map_hull

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.

HUD

General

The following settings control how certain custom elements are displayed.

bxt_hud

Controls whether the custom HUD elements should be drawn. The default is 1.

bxt_hud_color

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.

bxt_hud_precision

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.

bxt_hud_useables_radius

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.

Custom elements

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.

bxt_hud_distance

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.

bxt_hud_entity_hp

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 103 in 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.

bxt_hud_jumpspeed

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.

bxt_hud_origin

Displays your position in the current map relative to the global origin. While this information can also be obtained by running the status command 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.

bxt_hud_selfgauss

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.

bxt_hud_speedometer

Displays a sprite-based HUD element indicating your horizontal speed. This is useful for human speedrunners because of its large text.

bxt_hud_health

Displays the absolute health without overflowing and can display HP bigger than 255.

bxt_hud_nihilanth

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.

bxt_hud_timer

Displays a sprite-based timer which can be controlled with bxt_timer_* commands.

bxt_hud_useables

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 bxt_hud_useables_radius.

bxt_hud_velocity

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.

bxt_hud_viewangles

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.

bxt_hud_visible_landmarks

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.

Element positioning

For each custom element setting, there are two associated settings used for controlling its position. Their names are the main CVAR name appended with _anchor and _offset respectively. For example, to control the position of the speedometer, you need to adjust the values of bxt_hud_speedometer_anchor and/or bxt_hud_speedometer_offset.

All _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".

TAS

bxt_tas_loadscript <filename>

Loads the specified .hltas script and starts executing it.

_bxt_reset_frametime_remainder

Resets the frametime remainder. Put this in your TAS starting binds to get rid of frametime overflow inconsistencies.

bxt_taslog

Toggles TAS logging.

bxt_taslog_filename <filename>

Sets the output file for bxt_taslog.

_bxt_map

Same as map, but doesn’t get called on stuffcmds if specified in the launch arguments. Useful for running TASes from the launch arguments.

_bxt_load

Same as load, but see _bxt_map.

bxt_tas_exportscript

Converts a .hltas to an "exported" version without any autofuncs: strafing, autojump, etc. are replaced with raw button presses.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.