prepare comments intendation for next toolchain

client/i18n/src/lib.rs

@@ -422,14 +422,12 @@ impl LocalizationGuard {
     /// ```
     ///
     /// 1) Because content we want is localized itself and has arguments, we
-    /// iterate over them and localize, recursively. Having that, we localize
-    /// our content.
-    ///
-    /// 2) Now there is a chance that some of args have missing
-    /// internalization. In that case, we insert arg name as placeholder and
-    /// mark it as broken. Then we repeat *whole* procedure on fallback
-    /// language if we have it.
-    ///
+    ///    iterate over them and localize, recursively. Having that, we localize
+    ///    our content.
+    /// 2) Now there is a chance that some of args have missing internalization.
+    ///    In that case, we insert arg name as placeholder and mark it as
+    ///    broken. Then we repeat *whole* procedure on fallback language if we
+    ///    have it.
     /// 3) Otherwise, return result from (1).
     // NOTE: it's important that we only use one language at the time, because
     // otherwise we will get partially-translated message.

client/src/lib.rs

@@ -3331,6 +3331,7 @@ mod tests {
     /// CHANGING IT WILL BREAK 3rd PARTY APPLICATIONS (please extend) which
     /// needs to be informed (or fixed)
     ///  - torvus: https://gitlab.com/veloren/torvus
+    ///
     /// CONTACT @Core Developer BEFORE MERGING CHANGES TO THIS TEST
     fn constant_api_test() {
         use common::clock::Clock;

common/base/src/userdata_dir.rs

@@ -17,9 +17,10 @@ const VELOREN_USERDATA_ENV: &str = "VELOREN_USERDATA";
 
 /// Determines common user data directory used by veloren frontends
 /// The first specified in this list is used
-/// 1. The VELOREN_USERDATA environment variable
-/// 2. The VELOREN_USERDATA_STRATEGY environment variable
-/// 3. The CARGO_MANIFEST_DIR/userdata or CARGO_MANIFEST_DIR/../userdata
+///   1. The VELOREN_USERDATA environment variable
+///   2. The VELOREN_USERDATA_STRATEGY environment variable
+///   3. The CARGO_MANIFEST_DIR/userdata or CARGO_MANIFEST_DIR/../userdata
+///
 /// depending on if a    workspace if being used
 pub fn userdata_dir(workspace: bool, strategy: Option<&str>, manifest_dir: &str) -> PathBuf {
     // 1. The VELOREN_USERDATA environment variable

common/ecs/src/system.rs

@@ -45,12 +45,11 @@ impl Origin {
 pub struct CpuTimeline {
     /// measurements for a System
     /// - The first entry will always be ParMode::Single, as when the
-    ///   System::run is executed, we run
-    /// single threaded until we start a Rayon::ParIter or similar
+    ///   System::run is executed, we run single threaded until we start a
+    ///   Rayon::ParIter or similar
     /// - The last entry will contain the end time of the System. To mark the
-    ///   End it will always contain
-    /// ParMode::None, which means from that point on 0 CPU threads work in this
-    /// system
+    ///   End it will always contain ParMode::None, which means from that point
+    ///   on 0 CPU threads work in this system
     measures: Vec<(Instant, ParMode)>,
 }
 

common/frontend/src/lib.rs

@@ -27,6 +27,7 @@ const RUST_LOG_ENV: &str = "RUST_LOG";
 ///  - warn for `prometheus_hyper`, `dot_vox`, `gfx_device_gl::factory,
 ///    `gfx_device_gl::shade` trace for `veloren_voxygen`, info for everything
 ///    else
+///
 /// `RUST_LOG="prometheus_hyper=warn,dot_vox::parser=warn,gfx_device_gl::
 /// factory=warn,gfx_device_gl::shade=warn,veloren_voxygen=trace,info"`
 ///

common/net/src/msg/world_msg.rs

@@ -36,22 +36,22 @@ pub struct WorldMapMsg {
     /// use 7 bits for water depth (using an integer f7 encoding), and we
     /// will find other uses for the remaining 12 bits.
     pub alt: Grid<u32>,
-    /// Horizon mapping.  This is a variant of shadow mapping that is
+    /// Horizon mapping. This is a variant of shadow mapping that is
     /// specifically designed for height maps; it takes advantage of their
     /// regular structure (e.g. no holes) to compress all information needed
     /// to decide when to cast a sharp shadow into a single nagle, the "horizon
-    /// angle."  This is the smallest angle with the ground at which light can
+    /// angle." This is the smallest angle with the ground at which light can
     /// pass through any occluders to reach the chunk, in some chosen
-    /// horizontal direction.  This would not be sufficient for a more
+    /// horizontal direction. This would not be sufficient for a more
     /// complicated 3D structure, but it works for height maps since:
     ///
     /// 1. they have no gaps, so as soon as light can shine through it will
-    /// always be able to do    so, and
+    ///    always be able to do so, and
     /// 2. we only care about lighting from the top, and only from the east and
-    /// west    (since at a large scale like this we mostly just want to
-    /// handle variable sunlight;    moonlight would present more challenges
-    /// but we currently have no plans to try to cast    accurate shadows in
-    /// moonlight).
+    ///    west (since at a large scale like this we mostly just want to handle
+    ///    variable sunlight; moonlight would present more challenges but we
+    ///    currently have no plans to try to cast accurate shadows in
+    ///    moonlight).
     ///
     /// Our chosen format is two pairs of vectors,
     /// with the first pair representing west-facing light (casting shadows on
@@ -67,11 +67,11 @@ pub struct WorldMapMsg {
     /// * Approximate (floor) height of maximal occluder. We currently use this
     ///   to try to deliver some approximation of soft shadows, which isn't that
     ///   big a deal on the world map but is probably needed in order to ensure
-    ///   smooth transitions between chunks in LoD view.  Additionally, when we
+    ///   smooth transitions between chunks in LoD view. Additionally, when we
     ///   start using the shadow information to do local lighting on the world
     ///   map, we'll want a quick way to test where we can go out of shadow at
     ///   arbitrary heights (since the player and other entities cajn find
-    ///   themselves far from the ground at times).  While this is only an
+    ///   themselves far from the ground at times). While this is only an
     ///   approximation to a proper distance map, hopefully it will give us
     ///   something  that feels reasonable enough for Veloren's style.
     ///
@@ -80,7 +80,7 @@ pub struct WorldMapMsg {
     /// Horizon mapping has a lot of advantages for height maps (simple, easy to
     /// understand, doesn't require any fancy math or approximation beyond
     /// precision loss), though it loses a few of them by having to store
-    /// distance to occluder as well.  However, just storing tons
+    /// distance to occluder as well. However, just storing tons
     /// and tons of regular shadow maps (153 for a full day cycle, stored at
     /// irregular intervals) combined with clever explicit compression and
     /// avoiding recording sharp local shadows (preferring retracing for
@@ -89,7 +89,7 @@ pub struct WorldMapMsg {
     /// want, we'd still need to store *some* extra information to create
     /// soft shadows, but it would still be nice to try to drive down our
     /// size as much as possible given how compressible shadows of height
-    /// maps seem to be in practice.  Therefore, we try to take advantage of the
+    /// maps seem to be in practice. Therefore, we try to take advantage of the
     /// way existing compression algorithms tend to work to see if we can
     /// achieve significant gains without doing a lot of custom work.
     ///
@@ -97,7 +97,7 @@ pub struct WorldMapMsg {
     /// row, the horizon angles in each direction should be sequences of
     /// monotonically increasing values (as chunks approach a tall
     /// occluder), followed by sequences of no shadow, repeated
-    /// until the end of the map.  Monotonic sequences and same-byte sequences
+    /// until the end of the map. Monotonic sequences and same-byte sequences
     /// are usually easy to compress and existing algorithms are more likely
     /// to be able to deal with them than jumbled data.  If we were to keep
     /// both directions in the same vector, off-the-shelf compression would
@@ -106,7 +106,7 @@ pub struct WorldMapMsg {
     /// For related reasons, rather than storing distances as in a standard
     /// distance map (which would lead to monotonically *decreasing* values
     /// as we approached the occluder from a given direction), we store the
-    /// estimated *occluder height.*  The idea here is that we replace the
+    /// estimated *occluder height.* The idea here is that we replace the
     /// monotonic sequences with constant sequences, which are extremely
     /// straightforward to compress and mostly handled automatically by anything
     /// that does run-length encoding (i.e. most off-the-shelf compression
@@ -114,7 +114,7 @@ pub struct WorldMapMsg {
     ///
     /// We still need to benchmark this properly, as there's no guarantee our
     /// current compression algorithms will actually work well on this data
-    /// in practice.  It's possible that some other permutation (e.g. more
+    /// in practice. It's possible that some other permutation (e.g. more
     /// bits reserved for "distance to occluder" in exchange for an even
     /// more predictible sequence) would end up compressing better than storing
     /// angles, or that we don't need as much precision as we currently have

common/src/clock.rs

@@ -10,11 +10,13 @@ use std::{
 /// - if we actually took less time than we planned: sleep and return planned
 ///   time
 /// - if we ran behind: don't sleep and return actual time
+///
 /// We DON'T do any fancy averaging of the deltas for tick for 2 reasons:
 ///  - all Systems have to work based on `dt` and we cannot assume that this is
 ///    const through all ticks
 ///  - when we have a slow tick, a lag, it doesn't help that we have 10 fast
 ///    ticks directly afterwards
+///
 /// We return a smoothed version for display only!
 pub struct Clock {
     /// This is the dt that the Clock tries to archive with each call of tick.

common/src/comp/fluid_dynamics.rs

@@ -387,13 +387,12 @@ pub fn zero_lift_drag_coefficient() -> f32 { 0.026 }
 /// Does not apply to twisted, cambered or delta wings. (It still gives a
 /// reasonably accurate approximation if the wing shape is not truly
 /// elliptical.)
-/// 1. geometric angle of attack, i.e. the pitch angle relative to
-/// freestream flow
-/// 2. up to around ~18°, at which point maximum lift has been achieved and
-/// thereafter falls precipitously, causing a stall (this is the stall
-/// angle)
-/// 3. effective aoa, i.e. geometric aoa - induced aoa; assumes
-/// no sideslip
+///   1. geometric angle of attack, i.e. the pitch angle relative to freestream
+///      flow
+///   2. up to around ~18°, at which point maximum lift has been achieved and
+///      thereafter falls precipitously, causing a stall (this is the stall
+///      angle)
+///   3. effective aoa, i.e. geometric aoa - induced aoa; assumes no sideslip
 // TODO: Look into handling tapered wings
 fn lift_slope(aspect_ratio: f32, sweep_angle: Option<f32>) -> f32 {
     // lift slope for a thin aerofoil, given by Thin Aerofoil Theory

common/src/comp/inventory/item/mod.rs

@@ -468,8 +468,7 @@ pub struct Item {
     ///   slot shapes
     /// - Modular components should agree with the tool kind
     /// - There should be exactly one damage component and exactly one held
-    ///   component for modular
-    /// weapons
+    ///   component for modular weapons
     components: Vec<Item>,
     /// amount is hidden because it needs to maintain the invariant that only
     /// stackable items can have > 1 amounts.

common/src/terrain/map.rs

@@ -51,7 +51,7 @@ use vek::*;
 ///   minimize distance traveled) across the whole map, and we assume there are
 ///   no obstacles or slopes.
 ///
-///   In example 1, a human is walking at the (real-time) speed of the fastest
+/// In example 1, a human is walking at the (real-time) speed of the fastest
 /// marathon runners   (around 6 blocks / real-time s).  We assume the human can
 /// maintain this pace indefinitely   without stopping.  Then crossing the map
 /// will take about:
@@ -60,20 +60,20 @@ use vek::*;
 /// * 1 real-time hr / 60 real-time min * 1 real-time days / 24 hr = 2^19 / 6 /
 ///   60 / 60 / 24 real-time days ≌ 1 real-time day.
 ///
-///   That's right--it will take a full day of *real* time to cross the map at
+/// That's right--it will take a full day of *real* time to cross the map at
 /// an apparent speed of   6 m / s.  Moreover, since in-game time passes at a
 /// rate of 1 in-game min / 1 in-game s, this   would also take *60 days* of
 /// in-game time.
 ///
-///   Still though, this is the rate of an ordinary human.  And besides that, if
+/// Still though, this is the rate of an ordinary human.  And besides that, if
 /// we instead had a   marathon runner traveling at 6 m / in-game s, it would
 /// take just 1 day of in-game time for   the runner to cross the map, or a mere
 /// 0.4 hr of real time.   To show that this rate of travel is unrealistic (and
 /// perhaps make an eventual argument for   a slower real-time to in-game time
 /// conversion rate), our second example will consist of a   high-speed train
 /// running at 300 km / real-time h (the fastest real-world high speed train
-///   averages under 270 k m / h, with 300 km / h as the designed top speed).
-/// For a train   traveling at this apparent speed (in real time), crossing the
+///  averages under 270 k m / h, with 300 km / h as the designed top speed).
+/// For a train traveling at this apparent speed (in real time), crossing the
 /// map would take:
 ///
 ///   2^19 blocks * 1 km / 1000 blocks * 1 real-time hr / 300 km
@@ -85,15 +85,15 @@ use vek::*;
 ///   = 2^19 / 1000 / 300 * 60 / 24 in-game days
 ///   ≌ 4.37 in-game days
 ///
-///   In other words, something faster in real-time than any existing high-speed
+/// In other words, something faster in real-time than any existing high-speed
 /// train would be   over 4 times slower (in real-time) than our hypothetical
 /// top marathon runner running at 6 m /   s in in-game speed.  This suggests
 /// that the gap between in-game time and real-time is   probably much too large
 /// for most purposes; however, what it definitely shows is that even
-///   extremely fast in-game transport across the world will not trivialize its
+/// extremely fast in-game transport across the world will not trivialize its
 /// size.
 ///
-///   It follows that cities or towns of realistic scale, player housing,
+/// It follows that cities or towns of realistic scale, player housing,
 /// fields, and so on, will   all fit comfortably on a map of this size, while
 /// at the same time still being reachable by   non-warping, in-game mechanisms
 /// (such as high-speed transit).  It also provides plenty of   room for mounts

common/src/typed.rs

@@ -25,8 +25,8 @@ pub trait Typed<Context, Type, S> {
 /// - For enums, we synthesize a match on the current head.  For each match arm,
 ///   we then repeat this process on the constructor arguments; if there are no
 ///   constructor arguments, we synthesize a literal (Pure term). (TODO: Handle
-///   > 1 tuple properly--for now we just synthesize a Pure term for these
-///   cases).
+///   larger than 1 tuple properly--for now we just synthesize a Pure term for
+///   these cases).
 ///
 /// - For structs, we synthesize a projection on the current head.  For each
 ///   projection, we then repeat this process on the type of the projected

network/src/participant.rs

@@ -638,14 +638,12 @@ impl BParticipant {
     /// on the remote, we have a timeout to also force close AR.
     ///
     /// This fn will:
-    ///  - 1. stop api to interact with bparticipant by closing sendmsg and
-    /// openstream
-    ///  - 2. stop the send_mgr (it will take care of clearing the
-    /// queue and finish with a Shutdown)
-    ///  - (3). force stop recv after 60
-    /// seconds
-    ///  - (4). this fn finishes last and afterwards BParticipant
-    /// drops
+    ///   1. stop api to interact with bparticipant by closing sendmsg and
+    ///      openstream
+    ///   2. stop the send_mgr (it will take care of clearing the queue and
+    ///      finish with a Shutdown)
+    ///   3. force stop recv after 60 seconds
+    ///   4. this fn finishes last and afterwards BParticipant drops
     ///
     /// before calling this fn, make sure `s2b_create_channel` is closed!
     /// If BParticipant kills itself managers stay active till this function is

network/tests/closing.rs

@@ -9,9 +9,10 @@
 //!      - 2 networks
 //!      - 2 participants
 //!      - 2 streams
+//!
 //!    each one `linked` to their counterpart.
 //!    You see a cryptic use of rust `_` this is because we are testing the
-//! `drop` behavior here.
+//!    `drop` behavior here.
 //!      - A `_` means this is directly dropped after the line executes, thus
 //!        immediately executing its `Drop` impl.
 //!      - A `_p1_a` e.g. means we don't use that Participant yet, but we must

server/src/cmd.rs

@@ -108,9 +108,9 @@ type CmdResult<T> = Result<T, Content>;
 ///   This differs from the previous argument when using /sudo
 /// * `Vec<String>` - a `Vec<String>` containing the arguments of the command
 ///   after the keyword.
-/// * `&ChatCommand` - the command to execute with the above arguments.
-/// Handler functions must parse arguments from the the given `String`
-/// (`parse_args!` exists for this purpose).
+/// * `&ChatCommand` - the command to execute with the above arguments --
+///   Handler functions must parse arguments from the the given `String`
+///   (`parse_args!` exists for this purpose).
 ///
 /// # Returns
 ///

server/src/settings/editable.rs

@@ -180,12 +180,11 @@ pub trait EditableSetting: Clone + Default {
     /// * If e is Integrity, validation failed and the settings were not
     ///   updated.
     /// * If e is Io, validation succeeded and the settings were updated in
-    ///   memory, but they
-    /// could not be saved to storage (and a warning was logged).  The reason we
-    /// return an error even though the operation was partially successful
-    /// is so we can alert the player who ran the command about the failure,
-    /// as they will often be an administrator who can usefully act upon that
-    /// information.
+    ///   memory, but they could not be saved to storage (and a warning was
+    ///   logged). The reason we return an error even though the operation was
+    ///   partially successful is so we can alert the player who ran the command
+    ///   about the failure, as they will often be an administrator who can
+    ///   usefully act upon that information.
     #[must_use]
     fn edit<R>(
         &mut self,

server/src/sys/terrain.rs

@@ -360,9 +360,8 @@ impl<'a> System<'a> for Sys {
                 // using eg. /reload_chunks
 
                 // TODO: code duplication for chunk insertion between here and state.rs
-                data.terrain.remove(key).map(|chunk| {
+                data.terrain.remove(key).inspect(|_| {
                     data.terrain_changes.removed_chunks.insert(key);
-                    chunk
                 })
             })
             .collect::<Vec<_>>();

server/src/terrain_persistence.rs

@@ -329,22 +329,23 @@ impl ByBlockLimiter {
 /// The steps for doing this are as follows:
 ///
 /// 1. Create a new 'raw format' type that implements [`Serialize`] and
-/// `Deserialize`]. Make sure to add a version field. If in doubt, copy the last
-/// raw format and increment the version number wherever it appears. Don't
-/// forget to increment the version number in the `serde(deserialize_with =
-/// ...}` attribute! Conventionally, these types are named `V{N}` where `{N}` is
-/// the number succeeding the previous raw format type.
+///    `Deserialize`]. Make sure to add a version field. If in doubt, copy the
+///    last raw format and increment the version number wherever it appears.
+///    Don't forget to increment the version number in the
+///    `serde(deserialize_with = ...}` attribute! Conventionally, these types
+///    are named `V{N}` where `{N}` is the number succeeding the previous raw
+///    format type.
 ///
 /// 2. Add an implementation of `From<{YourRawFormat}>` for `Chunk`. As before,
-/// see previous versions if in doubt.
+///    see previous versions if in doubt.
 ///
 /// 3. Change the type of [`version::Current`] to your new raw format type.
 ///
 /// 4. Add an entry for your raw format at the top of the array in
-/// [`version::loaders`].
+///    [`version::loaders`].
 ///
 /// 5. Remove the `Serialize` implementation from the previous raw format type:
-/// we don't need it any longer!
+///    we don't need it any longer!
 mod version {
     use super::*;
 

voxygen/src/audio/music.rs

@@ -139,15 +139,6 @@ enum DayPeriod {
     Night,
 }
 
-/// Determines whether the sound is stopped, playing, or fading
-#[derive(Debug, Deserialize, PartialEq)]
-enum PlayState {
-    Playing,
-    Stopped,
-    FadingOut,
-    FadingIn,
-}
-
 /// Provides methods to control music playback
 pub struct MusicMgr {
     /// Collection of all the tracks

voxygen/src/audio/sfx/event_mapper/block/mod.rs

@@ -283,11 +283,11 @@ impl BlockEventMapper {
     /// Ensures that:
     /// 1. An sfx.ron entry exists for an SFX event
     /// 2. The sfx has not been played since it's timeout threshold has elapsed,
-    /// which prevents firing every tick
-    /// Note that with so many blocks to choose from and different blocks being
-    /// selected each time, this is not perfect, but does reduce the number of
-    /// plays from blocks that have already emitted sfx and are stored in the
-    /// BlockEventMapper history.
+    ///    which prevents firing every tick. Note that with so many blocks to
+    ///    choose from and different blocks being selected each time, this is
+    ///    not perfect, but does reduce the number of plays from blocks that
+    ///    have already emitted sfx and are stored in the BlockEventMapper
+    ///    history.
     fn should_emit(
         previous_state: &PreviousBlockState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/audio/sfx/event_mapper/campfire/mod.rs

@@ -111,7 +111,7 @@ impl CampfireEventMapper {
     /// Ensures that:
     /// 1. An sfx.ron entry exists for an SFX event
     /// 2. The sfx has not been played since it's timeout threshold has elapsed,
-    /// which prevents firing every tick
+    ///    which prevents firing every tick
     fn should_emit(
         previous_state: &PreviousEntityState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/audio/sfx/event_mapper/combat/mod.rs

@@ -124,7 +124,7 @@ impl CombatEventMapper {
     /// Ensures that:
     /// 1. An sfx.ron entry exists for an SFX event
     /// 2. The sfx has not been played since it's timeout threshold has elapsed,
-    /// which prevents firing every tick
+    ///    which prevents firing every tick
     fn should_emit(
         previous_state: &PreviousEntityState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/audio/sfx/event_mapper/movement/mod.rs

@@ -159,9 +159,10 @@ impl MovementEventMapper {
     /// When specific entity movements are detected, the associated sound (if
     /// any) needs to satisfy two conditions to be allowed to play:
     /// 1. An sfx.ron entry exists for the movement (we need to know which sound
-    /// file(s) to play) 2. The sfx has not been played since it's timeout
-    /// threshold has elapsed, which prevents firing every tick. For movement,
-    /// threshold is not a time, but a distance.
+    ///    file(s) to play)
+    /// 2. The sfx has not been played since it's timeout threshold has elapsed,
+    ///    which prevents firing every tick. For movement, threshold is not a
+    ///    time, but a distance.
     fn should_emit(
         previous_state: &PreviousEntityState,
         sfx_trigger_item: Option<(&SfxEvent, &SfxTriggerItem)>,

voxygen/src/mesh/greedy.rs

@@ -286,7 +286,7 @@ impl AtlasAllocator for GuillotiereTiled {
             tracing::trace!("Packing ratio: {}", total_area as f32 / total_used as f32);
         }
 
-        let diff = (new_size - self.size()).map(|e| e.max(0));
+        let diff = new_size.map2(self.size(), |n, s| n.saturating_sub(s));
         // NOTE: Growing only occurs in increments of TILE_SIZE so any remaining size is
         // ignored. Max size is not known here so this must truncate instead of rounding
         // up.

voxygen/src/scene/camera.rs

@@ -81,7 +81,7 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 ///
 /// This ensures that the near and far plane are not identical (or else your
 /// projection would not cover any distance), and that they have the same sign
-/// (or else we cannot rely on clipping to properly fix your scene).  This also
+/// (or else we cannot rely on clipping to properly fix your scene). This also
 /// ensures that at least one of 1/n and 1/f is not 0, and by construction it
 /// guarantees that neither n nor f are 0; these are required in order to make
 /// sense of the definition of near and far planes, and avoid collapsing all
@@ -95,71 +95,71 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 ///   depth planes go from 1 to 0, meaning f = near and n = far, aka "reverse
 ///   depth").
 ///
-///     This is by far the most
-///     likely thing to want to change; inverted depth coordinates have *far*
-/// better accuracy for     DirectX / Metal / WGPU-like APIs, when using
-/// floating point depth, while not being *worse*     than the alternative
-/// (OpenGL-like depth, or when using fixed-point / integer depth).  For
-///     maximum benefit, make sure you are using Depth32F, as on most platforms
-/// this is the only     depth buffer size where floating point can be used.
+/// This is by far the most likely thing to want to change; inverted depth
+/// coordinates have *far* better accuracy for DirectX / Metal / WGPU-like
+/// APIs, when using floating point depth, while not being *worse* than the
+/// alternative (OpenGL-like depth, or when using fixed-point / integer depth).
+/// For maximum benefit, make sure you are using Depth32F, as on most
+/// platforms this is the only depth buffer size where floating point can be
+/// used.
 ///
-///     It is a bit unintuitive to prove this, but it turns out that when using
-/// 1 to 0 depth planes,     the point where the depth buffer has its worst
-/// precision is not at the far plane (as with 0     to 1 depth planes) nor at
+/// It is a bit unintuitive to prove this, but it turns out that when using
+/// 1 to 0 depth planes, the point where the depth buffer has its worst
+/// precision is not at the far plane (as with 0 to 1 depth planes) nor at
 /// the near plane, as you might expect, but exactly at far/2 (the
-///     near plane setting does not affect the point of minimum accuracy at
-/// all!).  However, don't     let this fool you into believing the point of
-/// worst precision has simply been moved     around--for *any* fixed Δz that is
-/// the minimum amount of depth precision you want over the     whole range, and
+/// near plane setting does not affect the point of minimum accuracy at
+/// all!).  However, don't let this fool you into believing the point of
+/// worst precision has simply been moved around--for *any* fixed Δz that is
+/// the minimum amount of depth precision you want over the whole range, and
 /// any near plane, you can set the far plane farther (generally much much
-///     farther!) with reversed clip space than you can with standard clip space
-/// while still     getting at least that much depth precision in the worst
-/// case.  Nor is this a small     worst-case; for many desirable near and far
-/// plane combinations, more than half the visible     space will have
+/// farther!) with reversed clip space than you can with standard clip space
+/// while still getting at least that much depth precision in the worst
+/// case.  Nor is this a small worst-case; for many desirable near and far
+/// plane combinations, more than half the visible space will have
 /// completely unusable precision under 0 to 1 depth, while having much better
-///     than needed precision under 1 to 0 depth.
+/// than needed precision under 1 to 0 depth.
 ///
-///     To compute the exact (at least "roughly exact") worst-case accuracy for
-/// floating     point depth and a given precision target Δz, for reverse clip
-/// planes (this can be computed     for the non-reversed case too, but it's
-/// painful and the values are horrible, so don't     bother), we compute
+/// To compute the exact (at least "roughly exact") worst-case accuracy for
+/// floating point depth and a given precision target Δz, for reverse clip
+/// planes (this can be computed for the non-reversed case too, but it's
+/// painful and the values are horrible, so don't bother), we compute
 /// (assuming a finite far plane--see below for details on the infinite
-///     case) the change in the integer representation of the mantissa at z=n/2:
+/// case) the change in the integer representation of the mantissa at z=n/2:
 ///
-///     ```ignore
-///     e = floor(ln(near/(far - near))/ln(2))
-///     db/dz = 2^(2-e) / ((1 / far - 1 / near) * (far)^2)
-///     ```
+/// ```ignore
+/// e = floor(ln(near/(far - near))/ln(2))
+/// db/dz = 2^(2-e) / ((1 / far - 1 / near) * (far)^2)
+/// ```
 ///
-///     Then the maximum precision you can safely use to get a change in the
-/// integer representation     of the mantissa (assuming 32-bit floating points)
+/// Then the maximum precision you can safely use to get a change in the
+/// integer representation of the mantissa (assuming 32-bit floating points)
 /// is around:
 ///
-///     ```ignore
-///     abs(2^(-23) / (db/dz)).
-///     ```
+/// ```ignore
+/// abs(2^(-23) / (db/dz)).
+/// ```
 ///
-///     In particular, if your worst-case target accuracy over the depth range
-/// is Δz, you should     be okay if:
+/// In particular, if your worst-case target accuracy over the depth range
+/// is Δz, you should be okay if:
 ///
-///     ```ignore
-///     abs(Δz * (db/dz)) * 2^(23) ≥ 1.
-///     ```
+/// ```ignore
+/// abs(Δz * (db/dz)) * 2^(23) ≥ 1.
+/// ```
 ///
-///     This only accounts for precision of the final floating-point value, so
-/// it's     possible that artifacts may be introduced elsewhere during the
-/// computation that reduce     precision further; the most famous example of
-/// this is that OpenGL wipes out most of the     precision gains by going from
+/// This only accounts for precision of the final floating-point value, so
+/// it's possible that artifacts may be introduced elsewhere during the
+/// computation that reduce precision further; the most famous example of
+/// this is that OpenGL wipes out most of the precision gains by going from
 /// [-1,1] to [0,1] by letting
 ///
-///     ```ignore
-///     clip space depth = depth * 0.5 + 0.5
-///     ```
+/// ```ignore
+/// clip space depth = depth * 0.5 + 0.5
+/// ```
 ///
-///     which results in huge precision errors by removing nearly all the
-/// floating point values     with the most precision (those close to 0).
-/// Fortunately, most such artifacts are absent     under the wgpu/DirectX/Metal
-/// depth clip space model, so with any luck remaining depth     errors due to
+/// which results in huge precision errors by removing nearly all the
+/// floating point values with the most precision (those close to 0).
+/// Fortunately, most such artifacts are absent under the wgpu/DirectX/Metal
+/// depth clip space model, so with any luck remaining depth errors due to
 /// the perspective warp itself should be minimal.
 ///
 /// * 0 ≠ 1/far (finite far plane).  When this is false, the far plane is at
@@ -170,48 +170,48 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 ///   should be using reversed depth planes, and if you are then there is a
 ///   quite natural accuracy vs. distance tradeoff in the infinite case.
 ///
-///     When using an infinite far plane, the worst-case accuracy is *always* at
-/// infinity, and gets     progressively worse as you get farther away from the
-/// near plane.  However, there is a     second advantage that may not be
-/// immediately apparent: the perspective warp becomes much     simpler,
+/// When using an infinite far plane, the worst-case accuracy is *always* at
+/// infinity, and gets progressively worse as you get farther away from the
+/// near plane.  However, there is a second advantage that may not be
+/// immediately apparent: the perspective warp becomes much simpler,
 /// potentially removing artifacts!  Specifically, in the 0 to 1 depth plane
-/// case, the     assigned depth value (after perspective division) becomes:
+/// case, the assigned depth value (after perspective division) becomes:
 ///
-///     ```ignore
-///     depth = 1 - near/z
-///     ```
+/// ```ignore
+/// depth = 1 - near/z
+/// ```
 ///
-///     while in the 1 to 0 depth plane case (which you should be using), the
-/// equation is even     simpler:
+/// while in the 1 to 0 depth plane case (which you should be using), the
+/// equation is even simpler:
 ///
-///     ```ignore
-///     depth = near/z
-///     ```
+/// ```ignore
+/// depth = near/z
+/// ```
 ///
-///     In the 1 to 0 case, in particular, you can see that the depth value is
-/// *linear in z in     log space.*  This lets us compute, for any given target
-/// precision, a *very* simple     worst-case upper bound on the maximum
-/// absolute z value for which that precision can     be achieved (the upper
+/// In the 1 to 0 case, in particular, you can see that the depth value is
+/// *linear in z in log space.*  This lets us compute, for any given target
+/// precision, a *very* simple worst-case upper bound on the maximum
+/// absolute z value for which that precision can be achieved (the upper
 /// bound is tight in some cases, but in others may be conservative):
 ///
-///     ```ignore
-///     db/dz ≥ 1/z
-///     ```
+/// ```ignore
+/// db/dz ≥ 1/z
+/// ```
 ///
-///     Plugging that into our old formula, we find that we attain the required
-/// precision at least     in the range (again, this is for the 1 to 0 infinite
+/// Plugging that into our old formula, we find that we attain the required
+/// precision at least in the range (again, this is for the 1 to 0 infinite
 /// case only!):
 ///
-///     ```ignore
-///     abs(z) ≤ Δz * 2^23
-///     ```
+/// ```ignore
+/// abs(z) ≤ Δz * 2^23
+/// ```
 ///
-///     One thing you may notice is that this worst-case bound *does not depend
-/// on the near plane.*     This means that (within reason) you can put the near
-/// plane as close as you like and still     attain this bound.  Of course, the
-/// bound is not completely tight, but it should not be off     by more than a
+/// One thing you may notice is that this worst-case bound *does not depend
+/// on the near plane.*This means that (within reason) you can put the near
+/// plane as close as you like and still attain this bound.  Of course, the
+/// bound is not completely tight, but it should not be off by more than a
 /// factor of 2 or so (informally proven, not made rigorous yet), so for most
-///     practical purposes you can set the near plane as low as you like in this
+/// practical purposes you can set the near plane as low as you like in this
 /// case.
 ///
 /// * 0 < 1/near (positive near plane--best used when moving *to* left-handed
@@ -226,12 +226,12 @@ fn clamp_and_modulate(ori: Vec3<f32>) -> Vec3<f32> {
 ///
 /// Note that there is one final, very important thing that affects possible
 /// precision--the actual underlying precision of the floating point format at a
-/// particular value!  As your z values go up, their precision will shrink, so
+/// particular value! As your z values go up, their precision will shrink, so
 /// if at all possible try to shrink your z values down to the lowest range in
-/// which they can be.  Unfortunately, this cannot be part of the perspective
+/// which they can be. Unfortunately, this cannot be part of the perspective
 /// projection itself, because by the time z gets to the projection it is
 /// usually too late for values to still be integers (or coarse-grained powers
-/// of 2).  Instead, try to scale down x, y, and z as soon as possible before
+/// of 2). Instead, try to scale down x, y, and z as soon as possible before
 /// submitting them to the GPU, ideally by as large as possible of a power of 2
 /// that works for your use case.  Not only will this improve depth precision
 /// and recall, it will also help address other artifacts caused by values far

voxygen/src/scene/figure/load.rs

@@ -423,9 +423,6 @@ impl_concatenate_for_wrapper!(HumArmorFootSpec);
 struct HumMainWeaponSpec(HashMap<ToolKey, ArmorVoxSpec>);
 impl_concatenate_for_wrapper!(HumMainWeaponSpec);
 #[derive(Deserialize)]
-struct HumModularComponentSpec(HashMap<String, ModularComponentSpec>);
-impl_concatenate_for_wrapper!(HumModularComponentSpec);
-#[derive(Deserialize)]
 struct HumArmorLanternSpec(ArmorVoxSpecMap<String, ArmorVoxSpec>);
 impl_concatenate_for_wrapper!(HumArmorLanternSpec);
 #[derive(Deserialize)]

voxygen/src/scene/particle.rs

@@ -3014,7 +3014,7 @@ struct HeartbeatScheduler {
     /// - if it's more frequent then tick rate, it could be 1 or more.
     /// - if it's less frequent then tick rate, it could be 1 or 0.
     /// - if it's equal to the tick rate, it could be between 2 and 0, due to
-    /// delta time variance etc.
+    ///   delta time variance etc.
     timers: HashMap<Duration, (f64, u8)>,
 
     last_known_time: f64,
@@ -3058,10 +3058,10 @@ impl HeartbeatScheduler {
 
     /// returns the number of times this duration has elapsed since the last
     /// tick:
-    /// - if it's more frequent then tick rate, it could be 1 or more.
-    /// - if it's less frequent then tick rate, it could be 1 or 0.
-    /// - if it's equal to the tick rate, it could be between 2 and 0, due to
-    /// delta time variance.
+    ///   - if it's more frequent then tick rate, it could be 1 or more.
+    ///   - if it's less frequent then tick rate, it could be 1 or 0.
+    ///   - if it's equal to the tick rate, it could be between 2 and 0, due to
+    ///     delta time variance.
     pub fn heartbeats(&mut self, frequency: Duration) -> u8 {
         span!(_guard, "HeartbeatScheduler::heartbeats");
         let last_known_time = self.last_known_time;

voxygen/src/session/interactable.rs

@@ -119,6 +119,7 @@ impl Interactable {
 ///   a) entity (if within range)
 ///   b) collectable
 ///   c) can be mined, and is a mine sprite (Air) not a weak rock.
+///
 /// 2) outside of targeted cam ray
 ///   -> closest of nearest interactable entity/block
 pub(super) fn select_interactable(

voxygen/src/singleplayer/singleplayer_world.rs

@@ -9,13 +9,6 @@ use serde::{Deserialize, Serialize};
 use server::{FileOpts, GenOpts, DEFAULT_WORLD_MAP, DEFAULT_WORLD_SEED};
 use tracing::error;
 
-#[derive(Clone, Deserialize, Serialize)]
-struct World0 {
-    name: String,
-    gen_opts: Option<GenOpts>,
-    seed: u32,
-}
-
 pub struct SingleplayerWorld {
     pub name: String,
     pub gen_opts: Option<GenOpts>,

world/src/layer/spot.rs

@@ -24,13 +24,11 @@ use vek::*;
 /// To add a new spot, one must:
 ///
 /// 1. Add a new variant to the [`Spot`] enum.
-///
 /// 2. Add a new entry to [`Spot::generate`] that tells the system where to
-/// generate your new spot.
-///
+///    generate your new spot.
 /// 3. Add a new arm to the `match` expression in [`Spot::apply_spots_to`] that
-/// tells the generator how to generate a spot, including the base structure
-/// that composes the spot and the entities that should be spawned there.
+///    tells the generator how to generate a spot, including the base structure
+///    that composes the spot and the entities that should be spawned there.
 ///
 /// Only add spots with randomly spawned NPCs here. Spots that only use
 /// EntitySpawner blocks can be added in assets/world/manifests/spots.ron

world/src/sim/erosion.rs

@@ -629,8 +629,8 @@ type M32 = std::simd::Mask<i32, 1>;
 ///
 ///   k = 2.244 * uplift.max() / (desired_max_height)
 ///
-///   since this tends to produce mountains of max height desired_max_height;
-/// and we set   desired_max_height = 1.0 to reflect limitations of mountain
+/// since this tends to produce mountains of max height desired_max_height;
+/// and we set desired_max_height = 1.0 to reflect limitations of mountain
 /// scale.
 ///
 /// This algorithm does this in four steps:
@@ -639,7 +639,7 @@ type M32 = std::simd::Mask<i32, 1>;
 ///    the list, and the highest node by altitude is last).
 /// 2. Iterate through the list in *reverse.*  For each node, we compute its
 ///    drainage area as the sum of the drainage areas of its "children" nodes
-///    (i.e. the nodes with directed edges to this node).  To do this
+///    (i.e. the nodes with directed edges to this node). To do this
 ///    efficiently, we start with the "leaves" (the highest nodes), which have
 ///    no neighbors higher than them, hence no directed edges to them. We add
 ///    their area to themselves, and then to all neighbors that they flow into
@@ -662,9 +662,9 @@ type M32 = std::simd::Mask<i32, 1>;
 ///    A[i]^m / ((p(i) - p(j)).magnitude()), and δt = 1):
 ///
 ///    h[i](t + dt) = h[i](t) + δt * (uplift[i] + flux(i) * h[j](t + δt)) / (1 +
-/// flux(i) * δt).
+///    flux(i) * δt).
 ///
-///    Since we compute heights in ascending order by height, and j is downhill
+/// Since we compute heights in ascending order by height, and j is downhill
 /// from i, h[j] will    always be the *new* h[j](t + δt), while h[i] will still
 /// not have been computed yet, so we    only need to visit each node once.
 ///
@@ -677,9 +677,9 @@ type M32 = std::simd::Mask<i32, 1>;
 ///
 /// https://github.com/fastscape-lem/fastscapelib-fortran/blob/master/src/StreamPowerLaw.f90
 ///
-/// The  approximate equation for soil production function (predicting the rate
+/// The approximate equation for soil production function (predicting the rate
 /// at which bedrock turns into soil, increasing the distance between the
-/// basement and altitude) is taken from equation (11) from [2].  This (among
+/// basement and altitude) is taken from equation (11) from [2]. This (among
 /// numerous other sources) also includes at least one prediction that hillslope
 /// diffusion should be nonlinear, which we sort of attempt to approximate.
 ///
@@ -687,7 +687,7 @@ type M32 = std::simd::Mask<i32, 1>;
 ///     Bedrich Benes, Eric Galin, et al..
 ///     Large Scale Terrain Generation from Tectonic Uplift and Fluvial Erosion.
 ///     Computer Graphics Forum, Wiley, 2016, Proc. EUROGRAPHICS 2016, 35 (2),
-/// pp.165-175.     ⟨10.1111/cgf.12820⟩. ⟨hal-01262376⟩
+///     pp.165-175.     ⟨10.1111/cgf.12820⟩. ⟨hal-01262376⟩
 ///
 /// [2] William E. Dietrich, Dino G. Bellugi, Leonard S. Sklar,
 ///     Jonathan D. Stock