Apply prefixes to veloren source, espacially comments, so that reformating wont make it unreadable,

especially enumerations and other source code in errosions file

client/src/lib.rs

@@ -36,8 +36,9 @@ use std::{
 use uvth::{ThreadPool, ThreadPoolBuilder};
 use vek::*;
 
-// The duration of network inactivity until the player is kicked to the main menu
-// @TODO in the future, this should be configurable on the server, and be provided to the client
+// The duration of network inactivity until the player is kicked
+// @TODO: in the future, this should be configurable on the server
+// and be provided to the client
 const SERVER_TIMEOUT: Duration = Duration::from_secs(20);
 
 // After this duration has elapsed, the user will begin getting kick warnings in their chat window
@@ -330,14 +331,18 @@ impl Client {
         // the core developers before making significant changes to this code. Here is the
         // approximate order of things. Please update it as this code changes.
         //
-        // 1) Collect input from the frontend, apply input effects to the state of the game
+        // 1) Collect input from the frontend, apply input effects to the state
+        //    of the game
         // 2) Handle messages from the server
-        // 3) Go through any events (timer-driven or otherwise) that need handling and apply them
-        //    to the state of the game
-        // 4) Perform a single LocalState tick (i.e: update the world and entities in the world)
-        // 5) Go through the terrain update queue and apply all changes to the terrain
+        // 3) Go through any events (timer-driven or otherwise) that need handling
+        //    and apply them to the state of the game
+        // 4) Perform a single LocalState tick (i.e: update the world and entities
+        //    in the world)
+        // 5) Go through the terrain update queue and apply all changes
+        //    to the terrain
         // 6) Sync information to the server
-        // 7) Finish the tick, passing actions of the main thread back to the frontend
+        // 7) Finish the tick, passing actions of the main thread back
+        //    to the frontend
 
         // 1) Handle input from frontend.
         // Pass character actions from frontend input to the player's entity.
@@ -422,7 +427,8 @@ impl Client {
                 // -0.5 for being able to move to the corner of the current chunk
                 // -1 because chunks are not meshed if they don't have all their neighbors
                 //     (notice also that view_distance is decreased by 1)
-                //     (this subtraction on vd is ommitted elsewhere in order to provide a buffer layer of loaded chunks)
+                //     (this subtraction on vd is ommitted elsewhere in order to provide
+                //     a buffer layer of loaded chunks)
                 let top = if 2 * (dist - 2).max(0).pow(2) > (view_distance - 1).pow(2) as i32 {
                     ((view_distance - 1).pow(2) as f32 - (dist - 2).pow(2) as f32)
                         .sqrt()

common/src/comp/inventory/mod.rs

@@ -59,7 +59,8 @@ impl Inventory {
         }
     }
 
-    /// Add a series of items to an inventory without giving duplicates. (n * m complexity)
+    /// Add a series of items to an inventory without giving duplicates.
+    /// (n * m complexity)
     ///
     /// Error if inventory cannot contain the items (is full), returning the un-added items.
     /// This is a lazy inefficient implementation, as it iterates over the inventory more times

server/src/lib.rs

@@ -985,15 +985,20 @@ impl Server {
         // the core developers before making significant changes to this code. Here is the
         // approximate order of things. Please update it as this code changes.
         //
-        // 1) Collect input from the frontend, apply input effects to the state of the game
-        // 2) Go through any events (timer-driven or otherwise) that need handling and apply them
-        //    to the state of the game
-        // 3) Go through all incoming client network communications, apply them to the game state
-        // 4) Perform a single LocalState tick (i.e: update the world and entities in the world)
-        // 5) Go through the terrain update queue and apply all changes to the terrain
+        // 1) Collect input from the frontend, apply input effects to the
+        //    state of the game
+        // 2) Go through any events (timer-driven or otherwise) that need handling
+        //    and apply them to the state of the game
+        // 3) Go through all incoming client network communications, apply them to
+        //    the game state
+        // 4) Perform a single LocalState tick (i.e: update the world and entities
+        //    in the world)
+        // 5) Go through the terrain update queue and apply all changes to
+        //    the terrain
         // 6) Send relevant state updates to all clients
         // 7) Update Metrics with current data
-        // 8) Finish the tick, passing control of the main thread back to the frontend
+        // 8) Finish the tick, passing control of the main thread back
+        //    to the frontend
 
         let before_tick_1 = Instant::now();
         // 1) Build up a list of events for this frame, to be passed to the frontend.

server/src/sys/terrain.rs

@@ -15,7 +15,8 @@ use specs::{Join, Read, ReadStorage, System, Write, WriteExpect, WriteStorage};
 use std::sync::Arc;
 use vek::*;
 
-/// This system will handle loading generated chunks and unloading uneeded chunks.
+/// This system will handle loading generated chunks and unloading
+/// uneeded chunks.
 ///     1. Inserts newly generated chunks into the TerrainGrid
 ///     2. Sends new chunks to neaby clients
 ///     3. Handles the chunk's supplement (e.g. npcs)

server/src/sys/terrain_sync.rs

@@ -8,7 +8,8 @@ use common::{
 };
 use specs::{Join, Read, ReadExpect, ReadStorage, System, Write, WriteStorage};
 
-/// This system will handle loading generated chunks and unloading uneeded chunks.
+/// This system will handle loading generated chunks and unloading
+/// uneeded chunks.
 ///     1. Inserts newly generated chunks into the TerrainGrid
 ///     2. Sends new chunks to neaby clients
 ///     3. Handles the chunk's supplement (e.g. npcs)

voxygen/src/hud/settings_window.rs

@@ -1288,6 +1288,7 @@ impl<'a> Widget for SettingsWindow<'a> {
                 .font_size(18)
                 .set(state.ids.controls_text, ui);
             // TODO: Replace with buttons that show actual keybinds and allow the user to change them.
+            #[rustfmt::skip]
             Text::new(&format!(
                 "{}\n\
                  {}\n\

voxygen/src/ui/graphic/pixel_art.rs

@@ -13,11 +13,12 @@ const EPSILON: f32 = 0.0001;
 // averaged
 // Say we have two areas that we are combining to form a single pixel
 // A1 and A2 where these are the fraction of the area of the pixel each color contributes to
-// Then if the colors were opaque we would say that the final color ouput color o3 is
+// Then if the colors were opaque we would say that the final color
+// ouput color o3 is
 //     E1: o3 = A1 * o1 + A2 * o2
 // where o1 and o2 are the opaque colors of the two areas
-// now say the areas are actually translucent and these opaque colors are derived by blending with a
-// common backgound color b
+// now say the areas are actually translucent and these opaque colors are
+// derived by blending with a common backgound color b
 //     E2: o1 = c1 * a1 + b * (1 - a1)
 //     E3: o2 = c2 * a2 + b * (1 - a2)
 // we want to find the combined color (c3) and combined alpha (a3) such that

world/src/sim/erosion.rs

@@ -368,12 +368,12 @@ pub fn get_rivers<F: fmt::Debug + Float + Into<f64>, G: Float + Into<f64>>(
         // Now, we know we are a river *candidate*.  We still don't know whether we are actually a
         // river, though.  There are two ways for that to happen:
         // (i) We are already a river.
-        // (ii) Using the Gauckler–Manning–Strickler formula for cross-sectional average velocity
-        //      of water, we establish that the river can be "big enough" to appear on the Veloren
-        //      map.
+        // (ii) Using the Gauckler–Manning–Strickler formula for cross-sectional
+        //      average velocity of water, we establish that the river can be
+        //      "big enough" to appear on the Veloren map.
         //
-        // This is very imprecise, of course, and (ii) may (and almost certainly will) change over
-        // time.
+        // This is very imprecise, of course, and (ii) may (and almost certainly will)
+        // change over time.
         //
         // In both cases, we preemptively set our child to be a river, to make sure we have an
         // unbroken stream.  Also in both cases, we go to the effort of computing an effective
@@ -573,24 +573,30 @@ fn get_max_slope(
 ///
 /// This algorithm does this in four steps:
 ///
-/// 1. Sort the nodes in h by height (so the lowest node by altitude is first in 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 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 (their "ancestors" in the flow
-///    graph); currently, this just means the node immediately downhill of this node.
-///    As we go lower, we know that all our "children" already had their areas computed, which
-///    means that we can repeat the process in order to derive all the final areas.
-/// 3. Now, iterate through the list in *order.*  Whether we used the filling method to compute a
-///    "filled" version of each depression, or used the lake connection algoirthm described in [1],
-///    each node is guaranteed to have zero or one drainage edges out, representing the direction
-///    of water flow for that node.  For nodes i with zero drainage edges out (boundary nodes and
-///    lake bottoms) we set the slope to 0 (so the change in altitude is uplift(i))
-///    For nodes with at least one drainage edge out, we take advantage of the fact that we are
-///    computing new heights in order and rewrite our equation as (letting j = downhill[i], A[i]
-///    be the computed area of point i, p(i) be the x-y position of point i,
+/// 1. Sort the nodes in h by height (so the lowest node by altitude is first
+///    in 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
+///    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 (their "ancestors" in the flow graph); currently, this just
+///    means the node immediately downhill of this node. As we go lower, we
+///    know that all our "children" already had their areas computed, which
+///    means that we can repeat the process in order to derive all the final
+///    areas.
+/// 3. Now, iterate through the list in *order.*  Whether we used the filling
+///    method to compute a "filled" version of each depression, or used the lake
+///    connection algoirthm described in [1], each node is guaranteed to have
+///    zero or one drainage edges out, representing the direction of water flow
+///    for that node. For nodes i with zero drainage edges out (boundary nodes
+///    and lake bottoms) we set the slope to 0 (so the change in altitude is
+///    uplift(i))
+///    For nodes with at least one drainage edge out, we take advantage of the
+///    fact that we are computing new heights in order and rewrite our equation
+///    as (letting j = downhill[i], A[i] be the computed area of point i,
+///    p(i) be the x-y position of point i,
 ///    flux(i) = k * 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).
@@ -614,12 +620,14 @@ fn get_max_slope(
 /// prediction that hillslope diffusion should be nonlinear, which we sort of attempt to
 /// approximate.
 ///
-/// [1] Guillaume Cordonnier, Jean Braun, Marie-Paule Cani, Bedrich Benes, Eric Galin, et al..
+/// [1] Guillaume Cordonnier, Jean Braun, Marie-Paule Cani,
+///     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⟩
 ///
-/// [2] William E. Dietrich, Dino G. Bellugi, Leonard S. Sklar, Jonathan D. Stock
+/// [2] William E. Dietrich, Dino G. Bellugi, Leonard S. Sklar,
+///     Jonathan D. Stock
 ///     Geomorphic Transport Laws for Predicting Landscape Form and Dynamics.
 ///     Prediction in Geomorphology, Geophysical Monograph 135.
 ///     Copyright 2003 by the American Geophysical Union
@@ -678,6 +686,7 @@ fn erode(
     let dx = TerrainChunkSize::RECT_SIZE.x as f64;
     let dy = TerrainChunkSize::RECT_SIZE.y as f64;
 
+    #[rustfmt::skip]
     // ε₀ and α are part of the soil production approximate
     // equation:
     //
@@ -860,6 +869,7 @@ fn erode(
                         mrec_downhill(&mrec, posi).for_each(|(kk, posj)| {
                             let mwrec_kk = mwrec_i[kk] as f64;
 
+                            #[rustfmt::skip]
                             // Working equation:
                             //   U = uplift per time
                             //   D = sediment deposition per time
@@ -1031,6 +1041,7 @@ fn erode(
             "(Done precomputation, time={:?}ms).",
             start_time.elapsed().as_millis()
         );
+        #[rustfmt::skip]
         // sum the erosion in stack order
         //
         // After:
@@ -1065,6 +1076,7 @@ fn erode(
             "(Done sediment transport computation, time={:?}ms).",
             start_time.elapsed().as_millis()
         );
+        #[rustfmt::skip]
         // do ij=nn,1,-1
         //   ijk=stack(ij)
         //   ijr=rec(ijk)
@@ -1122,11 +1134,14 @@ fn erode(
                         let g_i_ratio = g_i / (p * area_i);
                         // One side of nonlinear equation (23):
                         //
-                        // h_i(t) + U_i * Δt + G / (p̃ * Ã_i) * Σ{j ∈ upstream_i(t)}(h_j(t, FINAL) + U_j * Δt - h_j(t + Δt, k))
+                        // h_i(t) + U_i * Δt + G / (p̃ * Ã_i) * Σ
+                        // {j ∈ upstream_i(t)}(h_j(t, FINAL)
+                        // + U_j * Δt - h_j(t + Δt, k))
                         //
                         // where
                         //
-                        // Ã_i = A_i / (∆x∆y) = N_i, number of cells upstream of cell i.
+                        // Ã_i = A_i / (∆x∆y) = N_i,
+                        // number of cells upstream of cell i.
                         *elev = old_h_after_uplift_i + uphill_silt_i * g_i_ratio;
                     }
                 },