This is called from within the main error function :ref:`mju_error`. When installed, this function overrides the default
error processing. Once it prints error messages (or whatever else the user wants to do), it must **exit** the program.
MuJoCo is written with the assumption that mju_error will not return. If it does, the behavior of the software is
undefined.

.. code-block:: C

   extern void (*mju_user_error)(const char*);


.. _mju_user_warning:

mju_user_warning

If this is installed, the MuJoCo runtime will use it to allocate all heap memory it needs (instead of using aligned
malloc). The user allocator must allocate memory aligned on 8-byte boundaries. Note that the parser and compiler are
written in C++ and sometimes allocate memory with the "new" operator which bypasses this mechanism.

.. code-block:: C

   extern void* (*mju_user_malloc)(size_t);


.. _mju_user_free:

mju_user_free
~~~~~~~~~~~~~

If this is installed, MuJoCo will free any heap memory it allocated by calling this function (instead of using aligned
free).

.. code-block:: C

   extern void (*mju_user_free)(void*);


.. _glPhysics:

Physics callbacks
^^^^^^^^^^^^^^^^^

The physics callbacks are the main mechanism for modifying the behavior of the simulator, beyond setting various
options. The options control the operation of the default pipeline, while callbacks extend the pipeline at
well-defined places. This enables advanced users to implement many interesting functions which we have not thought of,
while still taking advantage of the default pipeline. As with all other callbacks, there is no automated error
checking - instead we assume that the authors of callback functions know what they are doing.

Custom physics callbacks will often need parameters that are not standard in MJCF. This is largely why we have
provided custom fields as well as user data arrays in MJCF. The idea is to "instrument" the MJCF model by entering the
necessary user parameters, and then write callbacks that look for those parameters and perform the corresponding
computations. We strongly encourage users to write callbacks that check the model for the presence of user parameters
before accessing them - so that when a regular model is loaded, the callback disables itself automatically instead of
causing the software to crash.

.. _mjcb_passive:

mjcb_passive
~~~~~~~~~~~~

This is used to implement a custom passive force in joint space; if the force is more naturally defined in Cartesian
space, use the end-effector Jacobian to map it to joint space. By "passive" we do not mean a force that does no positive
work (as in physics), but simply a force that depends only on position and velocity but not on control. There are
standard passive forces in MuJoCo arising from springs, dampers, viscosity and density of the medium. They are computed
in ``mjData.qfrc_passive`` before mjcb_passive is called. The user callback should add to this vector instead of
overwriting it (otherwise the standard passive forces will be lost).

.. code-block:: C

   extern mjfGeneric mjcb_passive;


.. _mjcb_control:

mjcb_control
~~~~~~~~~~~~

This is the most commonly used callback. It implements a control law, by writing in the vector of controls
``mjData.ctrl``. It can also write in ``mjData.qfrc_applied`` and ``mjData.xfrc_applied``. The values written in these
vectors can depend on position, velocity and all other quantities derived from them, but cannot depend on contact forces
and other quantities that are computed after the control is specified. If the callback accesses the latter fields, their
values do not correspond to the current time step.

The control callback is called from within :ref:`mj_forward` and :ref:`mj_step`, just before the controls and applied
forces are needed. When using the RK integrator, it will be called 4 times per step. The alternative way of specifying
controls and applied forces is to set them before ``mj_step``, or use ``mj_step1`` and ``mj_step2``. The latter approach
allows setting the controls after the position and velocity computations have been performed by ``mj_step1``, allowing
these results to be utilized in computing the control (similar to using mjcb_control). However, the only way to change
the controls between sub-steps of the RK integrator is to define the control callback.

.. code-block:: C

   extern mjfGeneric mjcb_control;

.. _mjcb_contactfilter:

mjcb_contactfilter

This callback populates fields of ``mjData.sensordata`` corresponding to user-defined sensors. It is called if it is
installed and the model contains user-defined sensors. It is called once per compute stage (mjSTAGE_POS, mjSTAGE_VEL,
mjSTAGE_ACC) and must fill in all user sensor values for that stage. The user-defined sensors have dimensionality and
data types defined in the MJCF model which must be respected by the callback.

.. code-block:: C

   extern mjfSensor mjcb_sensor;

.. _mjcb_time:

mjcb_time
~~~~~~~~~

Installing this callback enables the built-in profiler, and keeps timing statistics in ``mjData.timer``. The return type
is mjtNum, while the time units are up to the user. :ref:`simulate.cc <saSimulate>` assumes the unit is 1 millisecond.
In order to be useful, the callback should use high-resolution timers with at least microsecond precision. This is
because the computations being timed are very fast.

.. code-block:: C

   extern mjfTime mjcb_time;


.. _mjcb_act_dyn:

mjcb_act_dyn

This callback implements custom actuator gains: it must return the gain for the specified actuator with
``mjModel.actuator_gaintype`` set to mjGAIN_USER. If such actuators exist in the model and this callback is not
installed, their gains are set to 1.

.. code-block:: C

   extern mjfAct mjcb_act_gain;


.. _mjcb_act_bias:

mjcb_act_bias

Table of pairwise collision functions indexed by geom types. Only the upper-right triangle is used. The user can replace
these function pointers with custom routines, replacing MuJoCo's collision mechanism. If a given entry is NULL, the
corresponding pair of geom types cannot be collided. Note that these functions apply only to near-phase collisions. The
broadphase mechanism is built-in and cannot be modified.

.. code-block:: C

   extern mjfCollision mjCOLLISIONFUNC[mjNGEOMTYPES][mjNGEOMTYPES];


.. _glString:

String constants
^^^^^^^^^^^^^^^^

The string constants described here are provided for user convenience. They correspond to the English names of lists of
options, and can be displayed in menus or dialogs in a GUI. The code sample :ref:`simulate.cc <saSimulate>` illustrates
how they can be used.


.. _mjDISABLESTRING:

mjDISABLESTRING

Names of the enable bits defined by :ref:`mjtEnableBit`.

.. code-block:: C

   extern const char* mjENABLESTRING[mjNENABLE];


.. _mjTIMERSTRING:

mjTIMERSTRING
~~~~~~~~~~~~~

Names of the mjData timers defined by :ref:`mjtTimer`.

.. code-block:: C

   extern const char* mjTIMERSTRING[mjNTIMER];


.. _mjLABELSTRING:

mjLABELSTRING
~~~~~~~~~~~~~

Names of the visual labeling modes defined by :ref:`mjtLabel`.

.. code-block:: C

   extern const char* mjLABELSTRING[mjNLABEL];


.. _mjFRAMESTRING:

mjFRAMESTRING
~~~~~~~~~~~~~

Names of the frame visualization modes defined by :ref:`mjtFrame`.

.. code-block:: C

   extern const char* mjFRAMESTRING[mjNFRAME];


.. _mjVISSTRING:

mjVISSTRING
~~~~~~~~~~~

Descriptions of the abstract visualization flags defined by :ref:`mjtVisFlag`. For each flag there are three strings,

with the following meaning:

[0]: flag name;

[1]: the string "0" or "1" indicating if the flag is on or off by default, as set by
:ref:`mjv_defaultOption`;

[2]: one-character string with a suggested keyboard shortcut, used in :ref:`simulate.cc <saSimulate>`.

.. code-block:: C

   extern const char* mjVISSTRING[mjNVISFLAG][3];


.. _mjRNDSTRING:

mjRNDSTRING
~~~~~~~~~~~

Descriptions of the OpenGL rendering flags defined by :ref:`mjtRndFlag`. The three strings for each flag have the same
format as above, except the defaults here are set by :ref:`mjv_makeScene`.

.. code-block:: C

   extern const char* mjRNDSTRING[mjNRNDFLAG][3];



.. _glNumeric:

Numeric constants
^^^^^^^^^^^^^^^^^

Many integer constants were already documented in the primitive types above. In addition, the header files define
several other constants documented here. Note that some extended key codes are defined in
`mjui.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjui.h>`_ which are not shown below. Their
names are in the format ``mjKEY_XXX``. They correspond to GLFW key codes.


.. _glNumericVersion:

Version
~~~~~~~

Defined in `mujoco.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mujoco.h>`_.

.. list-table::
   :widths: 2 1 8
   :header-rows: 1

   * - symbol
     - value
     - description
   * - ``mjVERSION_HEADER``
     - 3008000
     - The version of the MuJoCo headers. This is an integer calculated from the version string "S.M.P"
       using the formula ``(S * 1e6) + (M * 1e3) + P``. For example, version 4.2.1 is represented as 4002001.
       The API function :ref:`mj_version` returns a number with the same meaning
       but for the compiled library. See
       `VERSIONING.md <https://github.com/google-deepmind/mujoco/blob/main/VERSIONING.md>`__ for details.


.. _glNumericEngine:

Engine constants

Defined in `mjmodel.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjmodel.h>`_. These constants
correspond to array sizes which we have not fully settled. There may be reasons to increase them in the future, so as to
accommodate extra parameters needed for more elaborate computations. This is why we maintain them as symbolic constants
that can be easily changed, as opposed to the array size for representing quaternions for example -- which has no reason
to change.

.. list-table::
   :widths: 2 1 8
   :header-rows: 1

   * - symbol
     - value
     - description
   * - ``mjNEQDATA``
     - 11
     - The maximal number of real-valued parameters used to define each equality constraint. Determines the size of
       ``mjModel.eq_data``.
   * - ``mjNDYN``
     - 10
     - The maximal number of real-valued parameters used to define the activation dynamics of each actuator.
       Determines the size of ``mjModel.actuator_dynprm``.
   * - ``mjNGAIN``
     - 10
     - The maximal number of real-valued parameters used to define the gain of each actuator.
       Determines the size of ``mjModel.actuator_gainprm``.
   * - ``mjNBIAS``
     - 10
     - The maximal number of real-valued parameters used to define the bias of each actuator.
       Determines the size of ``mjModel.actuator_biasprm``.
   * - ``mjNPOLY``
     - 2
     - The number of nonlinear polynomial coefficients for joint and tendon stiffness and damping.
       Determines the size of ``mjModel.{jnt,tendon}_{stiffness,damping}poly``. See
       :ref:`polynomial forces<gePolynomial>`.
   * - ``mjNFLUID``
     - 12
     - The number of per-geom fluid interaction parameters required by the ellipsoidal model.
   * - ``mjNREF``
     - 2
     - The maximal number of real-valued parameters used to define the reference acceleration of each scalar constraint.
       Determines the size of all ``mjModel.XXX_solref`` fields.
   * - ``mjNIMP``
     - 5
     - The maximal number of real-valued parameters used to define the impedance of each scalar constraint.
       Determines the size of all ``mjModel.XXX_solimp`` fields.
   * - ``mjNSENS``
     - 3
     - The number of sensor parameters.
       Determines the size of ``mjModel.sensor_intprm``.
   * - ``mjNSOLVER``
     - 200
     - The number of iterations where solver statistics can be stored in ``mjData.solver``. This array is used
       to store diagnostic information about each iteration of the constraint solver.
       The actual number of iterations is given by ``mjData.solver_niter``.
   * - ``mjNISLAND``
     - 20
     - The number of islands for which solver statistics can be stored in ``mjData.solver``. This array is
       used to store diagnostic information about each iteration of the constraint solver.
       The actual number of islands for which the solver was run is given by ``mjData.nsolver_island``.


.. _glNumericVisualization:

Visualization

Defined in `mjrender.h <https://github.com/google-deepmind/mujoco/blob/main/include/mujoco/mjrender.h>`_.

.. list-table::
   :widths: 2 1 8
   :header-rows: 1

   * - symbol
     - value
     - description
   * - ``mjNAUX``
     - 10
     - Number of auxiliary buffers that can be allocated in mjrContext.
   * - ``mjMAXTEXTURE``
     - 1000
     - Maximum number of textures allowed.
   * - ``mjMAXMATERIAL``
     - 1000
     - Maximum number of materials with textures.


.. _glNumericUI:

UI constants

Compile-time flag, see :ref:`mjtNum`.

.. _mjDISABLED:

mjDISABLED
~~~~~~~~~~

.. code-block:: C

   #define mjDISABLED(x) (m->opt.disableflags & (x))

Check if a given standard feature has been disabled via the physics options, assuming mjModel\* m is defined. x is of
type :ref:`mjtDisableBit`.


.. _mjENABLED:

mjENABLED
~~~~~~~~~

.. code-block:: C

   #define mjENABLED(x) (m->opt.enableflags & (x))

Check if a given optional feature has been enabled via the physics options, assuming mjModel\* m is defined. x is of
type :ref:`mjtEnableBit`.


.. _mjMAX:

mjMAX
~~~~~

.. code-block:: C

   #define mjMAX(a,b) (((a) > (b)) ? (a) : (b))

Return maximum value. To avoid repeated evaluation with mjtNum types, use the function :ref:`mju_max`.


.. _mjMIN:

mjMIN
~~~~~

.. code-block:: C

   #define mjMIN(a,b) (((a) < (b)) ? (a) : (b))

Return minimum value. To avoid repeated evaluation with mjtNum types, use the function :ref:`mju_min`.


.. _mjPLUGIN_LIB_INIT:

mjPLUGIN_LIB_INIT