mirror of
https://github.com/SquidDev-CC/CC-Tweaked
synced 2025-10-26 11:27:38 +00:00
Use standard Markdown link syntax for references
References are now written using normal links: You now use [`print`] or
[print a string][`print`]) instead of @{print} or @{print|print a
string}.
This commit is contained in:
@@ -168,7 +168,7 @@ public class CommandAPI implements ILuaAPI {
|
||||
/**
|
||||
* Get information about a range of blocks.
|
||||
* <p>
|
||||
* This returns the same information as @{getBlockInfo}, just for multiple
|
||||
* This returns the same information as [`getBlockInfo`], just for multiple
|
||||
* blocks at once.
|
||||
* <p>
|
||||
* Blocks are traversed by ascending y level, followed by z and x - the returned
|
||||
@@ -225,7 +225,7 @@ public class CommandAPI implements ILuaAPI {
|
||||
* Get some basic information about a block.
|
||||
* <p>
|
||||
* The returned table contains the current name, metadata and block state (as
|
||||
* with @{turtle.inspect}). If there is a tile entity for that block, its NBT
|
||||
* with [`turtle.inspect`]). If there is a tile entity for that block, its NBT
|
||||
* will also be returned.
|
||||
*
|
||||
* @param x The x position of the block to query.
|
||||
|
||||
@@ -23,7 +23,7 @@ import java.util.Set;
|
||||
* <p>
|
||||
* > [!TIP]
|
||||
* > Modems provide a fairly basic set of methods, which makes them very flexible but often hard to work with. The
|
||||
* > {@literal @}{rednet} API is built on top of modems, and provides a more user-friendly interface.
|
||||
* > [`rednet`] API is built on top of modems, and provides a more user-friendly interface.
|
||||
* <p>
|
||||
* ## Sending and receiving messages
|
||||
* Modems operate on a series of channels, a bit like frequencies on a radio. Any modem can send a message on a
|
||||
@@ -31,11 +31,11 @@ import java.util.Set;
|
||||
* messages.
|
||||
* <p>
|
||||
* Channels are represented as an integer between 0 and 65535 inclusive. These channels don't have any defined meaning,
|
||||
* though some APIs or programs will assign a meaning to them. For instance, the @{gps} module sends all its messages on
|
||||
* channel 65534 (@{gps.CHANNEL_GPS}), while @{rednet} uses channels equal to the computer's ID.
|
||||
* though some APIs or programs will assign a meaning to them. For instance, the [`gps`] module sends all its messages on
|
||||
* channel 65534 ([`gps.CHANNEL_GPS`]), while [`rednet`] uses channels equal to the computer's ID.
|
||||
* <p>
|
||||
* - Sending messages is done with the {@link #transmit(int, int, Object)} message.
|
||||
* - Receiving messages is done by listening to the @{modem_message} event.
|
||||
* - Receiving messages is done by listening to the [`modem_message`] event.
|
||||
* <p>
|
||||
* ## Types of modem
|
||||
* CC: Tweaked comes with three kinds of modem, with different capabilities.
|
||||
|
||||
@@ -18,7 +18,7 @@ import javax.annotation.Nullable;
|
||||
* Monitors are a block which act as a terminal, displaying information on one side. This allows them to be read and
|
||||
* interacted with in-world without opening a GUI.
|
||||
* <p>
|
||||
* Monitors act as @{term.Redirect|terminal redirects} and so expose the same methods, as well as several additional
|
||||
* Monitors act as [terminal redirects][`term.Redirect`] and so expose the same methods, as well as several additional
|
||||
* ones, which are documented below.
|
||||
* <p>
|
||||
* Like computers, monitors come in both normal (no colour) and advanced (colour) varieties.
|
||||
|
||||
@@ -272,7 +272,7 @@ public abstract class SpeakerPeripheral implements IPeripheral {
|
||||
* <p>
|
||||
* This accepts a list of audio samples as amplitudes between -128 and 127. These are stored in an internal buffer
|
||||
* and played back at 48kHz. If this buffer is full, this function will return {@literal false}. You should wait for
|
||||
* a @{speaker_audio_empty} event before trying again.
|
||||
* a [`speaker_audio_empty`] event before trying again.
|
||||
* <p>
|
||||
* > [!NOTE]
|
||||
* > The speaker only buffers a single call to {@link #playAudio} at once. This means if you try to play a small
|
||||
@@ -280,7 +280,7 @@ public abstract class SpeakerPeripheral implements IPeripheral {
|
||||
* > (up to 128×1024), as this reduces the chances of audio stuttering or halting, especially when the server or
|
||||
* > computer is lagging.
|
||||
* <p>
|
||||
* {@literal @}{speaker_audio} provides a more complete guide to using speakers
|
||||
* [`speaker_audio`] provides a more complete guide to using speakers
|
||||
*
|
||||
* @param context The Lua context.
|
||||
* @param audio The audio data to play.
|
||||
@@ -291,7 +291,7 @@ public abstract class SpeakerPeripheral implements IPeripheral {
|
||||
* @cc.tparam [opt] number volume The volume to play this audio at. If not given, defaults to the previous volume
|
||||
* given to {@link #playAudio}.
|
||||
* @cc.since 1.100
|
||||
* @cc.usage Read an audio file, decode it using @{cc.audio.dfpwm}, and play it using the speaker.
|
||||
* @cc.usage Read an audio file, decode it using [`cc.audio.dfpwm`], and play it using the speaker.
|
||||
*
|
||||
* <pre data-peripheral="speaker">{@code
|
||||
* local dfpwm = require("cc.audio.dfpwm")
|
||||
|
||||
@@ -23,38 +23,38 @@ import java.util.Optional;
|
||||
* Turtles are capable of moving through the world. As turtles are blocks themselves, they are confined to Minecraft's
|
||||
* grid, moving a single block at a time.
|
||||
* <p>
|
||||
* {@literal @}{turtle.forward} and @{turtle.back} move the turtle in the direction it is facing, while @{turtle.up} and
|
||||
* {@literal @}{turtle.down} move it up and down (as one might expect!). In order to move left or right, you first need
|
||||
* to turn the turtle using @{turtle.turnLeft}/@{turtle.turnRight} and then move forward or backwards.
|
||||
* [`turtle.forward`] and [`turtle.back`] move the turtle in the direction it is facing, while [`turtle.up`] and
|
||||
* [`turtle.down`] move it up and down (as one might expect!). In order to move left or right, you first need
|
||||
* to turn the turtle using [`turtle.turnLeft`]/[`turtle.turnRight`] and then move forward or backwards.
|
||||
* <p>
|
||||
* > [!INFO]
|
||||
* > The name "turtle" comes from [Turtle graphics], which originated from the Logo programming language. Here you'd
|
||||
* > move a turtle with various commands like "move 10" and "turn left", much like ComputerCraft's turtles!
|
||||
* <p>
|
||||
* Moving a turtle (though not turning it) consumes *fuel*. If a turtle does not have any @{turtle.refuel|fuel}, it
|
||||
* won't move, and the movement functions will return @{false}. If your turtle isn't going anywhere, the first thing to
|
||||
* Moving a turtle (though not turning it) consumes *fuel*. If a turtle does not have any [fuel][`turtle.refuel`], it
|
||||
* won't move, and the movement functions will return [`false`]. If your turtle isn't going anywhere, the first thing to
|
||||
* check is if you've fuelled your turtle.
|
||||
* <p>
|
||||
* > [Handling errors][!TIP]
|
||||
* > Many turtle functions can fail in various ways. For instance, a turtle cannot move forward if there's already a
|
||||
* > block there. Instead of erroring, functions which can fail either return @{true} if they succeed, or @{false} and
|
||||
* > block there. Instead of erroring, functions which can fail either return [`true`] if they succeed, or [`false`] and
|
||||
* > some error message if they fail.
|
||||
* >
|
||||
* > Unexpected failures can often lead to strange behaviour. It's often a good idea to check the return values of these
|
||||
* > functions, or wrap them in @{assert} (for instance, use `assert(turtle.forward())` rather than `turtle.forward()`),
|
||||
* > functions, or wrap them in [`assert`] (for instance, use `assert(turtle.forward())` rather than `turtle.forward()`),
|
||||
* > so the program doesn't misbehave.
|
||||
* <p>
|
||||
* ## Turtle upgrades
|
||||
* While a normal turtle can move about the world and place blocks, its functionality is limited. Thankfully, turtles
|
||||
* can be upgraded with *tools* and @{peripheral|peripherals}. Turtles have two upgrade slots, one on the left and right
|
||||
* sides. Upgrades can be equipped by crafting a turtle with the upgrade, or calling the @{turtle.equipLeft}/@{turtle.equipRight}
|
||||
* can be upgraded with *tools* and [peripherals][`peripheral`]. Turtles have two upgrade slots, one on the left and right
|
||||
* sides. Upgrades can be equipped by crafting a turtle with the upgrade, or calling the [`turtle.equipLeft`]/[`turtle.equipRight`]
|
||||
* functions.
|
||||
* <p>
|
||||
* Turtle tools allow you to break blocks (@{turtle.dig}) and attack entities (@{turtle.attack}). Some tools are more
|
||||
* Turtle tools allow you to break blocks ([`turtle.dig`]) and attack entities ([`turtle.attack`]). Some tools are more
|
||||
* suitable to a task than others. For instance, a diamond pickaxe can break every block, while a sword does more
|
||||
* damage. Other tools have more niche use-cases, for instance hoes can til dirt.
|
||||
* <p>
|
||||
* Peripherals (such as the @{modem|wireless modem} or @{speaker}) can also be equipped as upgrades. These are then
|
||||
* Peripherals (such as the [wireless modem][`modem`] or [`speaker`]) can also be equipped as upgrades. These are then
|
||||
* accessible by accessing the `"left"` or `"right"` peripheral.
|
||||
* <p>
|
||||
* [Turtle Graphics]: https://en.wikipedia.org/wiki/Turtle_graphics "Turtle graphics"
|
||||
|
||||
Reference in New Issue
Block a user