Fix broken link in docs.

PiperOrigin-RevId: 933054777
Change-Id: Ic862992051200bff1b742025926961a7c2087ffa
This commit is contained in:
Yuval Tassa
2026-06-16 06:23:26 -07:00
committed by Copybara-Service
parent 8efb396b26
commit 55d7ff49ec
+3 -3
View File
@@ -986,9 +986,9 @@ architectural distinction in how filtering is applied:
can implement their own filtering logic. can implement their own filtering logic.
* **DEBUG messages**: Designed for tight, high-frequency simulation loops where constructing strings would be a * **DEBUG messages**: Designed for tight, high-frequency simulation loops where constructing strings would be a
performance bottleneck. Therefore, filtering happens on the **producer side** via :ref:`mju_isTopicEnabled`. If a performance bottleneck. Therefore, filtering happens on the **producer side**. If a topic is disabled, the message is
topic is disabled, the message is never constructed or dispatched. Consequently, custom handlers will only receive never constructed or dispatched. Consequently, custom handlers will only receive DEBUG messages if the topic is
DEBUG messages if the topic is explicitly enabled in the active :ref:`mjLogConfig`. explicitly enabled in the active :ref:`mjLogConfig`.
In the default handler, INFO messages are followed by a blank line for readability, whereas high-frequency DEBUG traces In the default handler, INFO messages are followed by a blank line for readability, whereas high-frequency DEBUG traces
are printed compactly without trailing blank lines. are printed compactly without trailing blank lines.