From 618492da39e69178ead12acc0c21c48969cf98f4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marcel=20M=C3=A4rtens?= Date: Mon, 8 Jul 2024 09:54:01 +0200 Subject: [PATCH] prepare comments intendation for next toolchain --- client/i18n/src/lib.rs | 14 +- client/src/lib.rs | 1 + common/base/src/userdata_dir.rs | 7 +- common/ecs/src/system.rs | 9 +- common/frontend/src/lib.rs | 1 + common/net/src/msg/world_msg.rs | 30 ++-- common/src/clock.rs | 2 + common/src/comp/fluid_dynamics.rs | 13 +- common/src/comp/inventory/item/mod.rs | 3 +- common/src/terrain/map.rs | 16 +- common/src/typed.rs | 4 +- network/src/participant.rs | 14 +- network/tests/closing.rs | 3 +- server/src/cmd.rs | 6 +- server/src/settings/editable.rs | 11 +- server/src/sys/terrain.rs | 3 +- server/src/terrain_persistence.rs | 17 +- voxygen/src/audio/music.rs | 9 - .../src/audio/sfx/event_mapper/block/mod.rs | 10 +- .../audio/sfx/event_mapper/campfire/mod.rs | 2 +- .../src/audio/sfx/event_mapper/combat/mod.rs | 2 +- .../audio/sfx/event_mapper/movement/mod.rs | 7 +- voxygen/src/mesh/greedy.rs | 2 +- voxygen/src/scene/camera.rs | 166 +++++++++--------- voxygen/src/scene/figure/load.rs | 3 - voxygen/src/scene/particle.rs | 10 +- voxygen/src/session/interactable.rs | 1 + .../src/singleplayer/singleplayer_world.rs | 7 - world/src/layer/spot.rs | 8 +- world/src/sim/erosion.rs | 16 +- 30 files changed, 188 insertions(+), 209 deletions(-) diff --git a/client/i18n/src/lib.rs b/client/i18n/src/lib.rs index 0f5dce1c95..5fef9e6c65 100644 --- a/client/i18n/src/lib.rs +++ b/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. diff --git a/client/src/lib.rs b/client/src/lib.rs index cbe8668eb0..81ac754024 100644 --- a/client/src/lib.rs +++ b/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; diff --git a/common/base/src/userdata_dir.rs b/common/base/src/userdata_dir.rs index 5de4e728a8..952adc090c 100644 --- a/common/base/src/userdata_dir.rs +++ b/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 diff --git a/common/ecs/src/system.rs b/common/ecs/src/system.rs index 48457e992b..c8966c70aa 100644 --- a/common/ecs/src/system.rs +++ b/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)>, } diff --git a/common/frontend/src/lib.rs b/common/frontend/src/lib.rs index a297bc4ecb..79ac46b0f3 100644 --- a/common/frontend/src/lib.rs +++ b/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"` /// diff --git a/common/net/src/msg/world_msg.rs b/common/net/src/msg/world_msg.rs index 3946630fdb..07622a869b 100644 --- a/common/net/src/msg/world_msg.rs +++ b/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, - /// 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 diff --git a/common/src/clock.rs b/common/src/clock.rs index cbc86839ca..d1b16497eb 100644 --- a/common/src/clock.rs +++ b/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. diff --git a/common/src/comp/fluid_dynamics.rs b/common/src/comp/fluid_dynamics.rs index d0a4a6b222..c81f3b1570 100644 --- a/common/src/comp/fluid_dynamics.rs +++ b/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 { // lift slope for a thin aerofoil, given by Thin Aerofoil Theory diff --git a/common/src/comp/inventory/item/mod.rs b/common/src/comp/inventory/item/mod.rs index 95d0951772..1012e05095 100644 --- a/common/src/comp/inventory/item/mod.rs +++ b/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, /// amount is hidden because it needs to maintain the invariant that only /// stackable items can have > 1 amounts. diff --git a/common/src/terrain/map.rs b/common/src/terrain/map.rs index 230d54d392..c023b1562e 100644 --- a/common/src/terrain/map.rs +++ b/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 diff --git a/common/src/typed.rs b/common/src/typed.rs index 29fdd6b0e0..9175268adf 100644 --- a/common/src/typed.rs +++ b/common/src/typed.rs @@ -25,8 +25,8 @@ pub trait Typed { /// - 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 diff --git a/network/src/participant.rs b/network/src/participant.rs index 27c3758f55..1a8eac2712 100644 --- a/network/src/participant.rs +++ b/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 diff --git a/network/tests/closing.rs b/network/tests/closing.rs index c72870b78d..607f1974a9 100644 --- a/network/tests/closing.rs +++ b/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 diff --git a/server/src/cmd.rs b/server/src/cmd.rs index 5850f34a87..b38aa8f296 100644 --- a/server/src/cmd.rs +++ b/server/src/cmd.rs @@ -108,9 +108,9 @@ type CmdResult = Result; /// This differs from the previous argument when using /sudo /// * `Vec` - a `Vec` 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 /// diff --git a/server/src/settings/editable.rs b/server/src/settings/editable.rs index 9edea4f0ed..cc0a217ad2 100644 --- a/server/src/settings/editable.rs +++ b/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( &mut self, diff --git a/server/src/sys/terrain.rs b/server/src/sys/terrain.rs index b32ae4d70c..ae627693a5 100644 --- a/server/src/sys/terrain.rs +++ b/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::>(); diff --git a/server/src/terrain_persistence.rs b/server/src/terrain_persistence.rs index 66c240cab6..96ad0400b3 100644 --- a/server/src/terrain_persistence.rs +++ b/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::*; diff --git a/voxygen/src/audio/music.rs b/voxygen/src/audio/music.rs index 6c5868b4b8..a6ef8ec902 100644 --- a/voxygen/src/audio/music.rs +++ b/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 diff --git a/voxygen/src/audio/sfx/event_mapper/block/mod.rs b/voxygen/src/audio/sfx/event_mapper/block/mod.rs index 0606e2bf0f..5567ef9f51 100644 --- a/voxygen/src/audio/sfx/event_mapper/block/mod.rs +++ b/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)>, diff --git a/voxygen/src/audio/sfx/event_mapper/campfire/mod.rs b/voxygen/src/audio/sfx/event_mapper/campfire/mod.rs index cdd6f9ea68..519518ce29 100644 --- a/voxygen/src/audio/sfx/event_mapper/campfire/mod.rs +++ b/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)>, diff --git a/voxygen/src/audio/sfx/event_mapper/combat/mod.rs b/voxygen/src/audio/sfx/event_mapper/combat/mod.rs index edc86365a8..dd5969fa61 100644 --- a/voxygen/src/audio/sfx/event_mapper/combat/mod.rs +++ b/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)>, diff --git a/voxygen/src/audio/sfx/event_mapper/movement/mod.rs b/voxygen/src/audio/sfx/event_mapper/movement/mod.rs index 7d1875d503..af3dedd3a4 100644 --- a/voxygen/src/audio/sfx/event_mapper/movement/mod.rs +++ b/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)>, diff --git a/voxygen/src/mesh/greedy.rs b/voxygen/src/mesh/greedy.rs index 5adf48927f..9e311385d6 100644 --- a/voxygen/src/mesh/greedy.rs +++ b/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. diff --git a/voxygen/src/scene/camera.rs b/voxygen/src/scene/camera.rs index f90bc04a54..79dc9790b5 100644 --- a/voxygen/src/scene/camera.rs +++ b/voxygen/src/scene/camera.rs @@ -81,7 +81,7 @@ fn clamp_and_modulate(ori: Vec3) -> Vec3 { /// /// 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) -> Vec3 { /// 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) -> Vec3 { /// 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) -> Vec3 { /// /// 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 diff --git a/voxygen/src/scene/figure/load.rs b/voxygen/src/scene/figure/load.rs index a0e6fe70e7..3a2339a206 100644 --- a/voxygen/src/scene/figure/load.rs +++ b/voxygen/src/scene/figure/load.rs @@ -423,9 +423,6 @@ impl_concatenate_for_wrapper!(HumArmorFootSpec); struct HumMainWeaponSpec(HashMap); impl_concatenate_for_wrapper!(HumMainWeaponSpec); #[derive(Deserialize)] -struct HumModularComponentSpec(HashMap); -impl_concatenate_for_wrapper!(HumModularComponentSpec); -#[derive(Deserialize)] struct HumArmorLanternSpec(ArmorVoxSpecMap); impl_concatenate_for_wrapper!(HumArmorLanternSpec); #[derive(Deserialize)] diff --git a/voxygen/src/scene/particle.rs b/voxygen/src/scene/particle.rs index b50aeee38b..81bbaed133 100644 --- a/voxygen/src/scene/particle.rs +++ b/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, 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; diff --git a/voxygen/src/session/interactable.rs b/voxygen/src/session/interactable.rs index b494cefb73..7cad865754 100644 --- a/voxygen/src/session/interactable.rs +++ b/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( diff --git a/voxygen/src/singleplayer/singleplayer_world.rs b/voxygen/src/singleplayer/singleplayer_world.rs index de37ae3dd3..c22746f8b7 100644 --- a/voxygen/src/singleplayer/singleplayer_world.rs +++ b/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, - seed: u32, -} - pub struct SingleplayerWorld { pub name: String, pub gen_opts: Option, diff --git a/world/src/layer/spot.rs b/world/src/layer/spot.rs index aaaaa331f3..eaa90443b6 100644 --- a/world/src/layer/spot.rs +++ b/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 diff --git a/world/src/sim/erosion.rs b/world/src/sim/erosion.rs index 4844861e8a..510999c01d 100644 --- a/world/src/sim/erosion.rs +++ b/world/src/sim/erosion.rs @@ -629,8 +629,8 @@ type M32 = std::simd::Mask; /// /// 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; /// 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; /// 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; /// /// 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; /// 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