From 9ffa5846709cee2f79788f8a7edbfab68b534500 Mon Sep 17 00:00:00 2001 From: Rob Parrett Date: Mon, 26 Aug 2024 06:08:37 -0700 Subject: [PATCH] Fix duplicate words (#1619) --- content/learn/book/ecs/_index.md | 2 +- content/learn/contribute/helping-out/how-you-can-help.md | 4 ++-- .../learn/contribute/project-information/release-process.md | 2 +- content/learn/migration-guides/0.11-to-0.12.md | 4 ++-- content/learn/migration-guides/0.7-to-0.8.md | 2 +- content/learn/migration-guides/0.9-to-0.10.md | 2 +- content/news/2020-08-10-introducing-bevy/index.md | 2 +- generate-assets/src/lib.rs | 2 +- .../release-notes/12792_Implement_Auto_Exposure_plugin.md | 2 +- 9 files changed, 11 insertions(+), 11 deletions(-) diff --git a/content/learn/book/ecs/_index.md b/content/learn/book/ecs/_index.md index b926df7fb6..da0b58fa72 100644 --- a/content/learn/book/ecs/_index.md +++ b/content/learn/book/ecs/_index.md @@ -9,7 +9,7 @@ status = 'hidden' In Bevy, game objects are stored as **entities**, whose data is stored as **components**. **Systems** operate on this data, modifying the **world** to carry out the behavior that brings your game to life. -Together, these these form the basis of Bevy's **ECS**, which unsurprisingly stands for ["Entity-Component-System"](https://en.wikipedia.org/wiki/Entity_component_system). +Together, these form the basis of Bevy's **ECS**, which unsurprisingly stands for ["Entity-Component-System"](https://en.wikipedia.org/wiki/Entity_component_system). Let's go over the most important definitions: - **World:** A unifying collection of all of the data stored in the ECS. diff --git a/content/learn/contribute/helping-out/how-you-can-help.md b/content/learn/contribute/helping-out/how-you-can-help.md index 708ee7d3ae..561cbcaec6 100644 --- a/content/learn/contribute/helping-out/how-you-can-help.md +++ b/content/learn/contribute/helping-out/how-you-can-help.md @@ -29,7 +29,7 @@ Think you've found a bug, missing documentation, or a feature that would help yo **One of the most valuable things you can do is review other people's work.** Bevy relies on community code review to keep the code quality high and the maintenance burden low. Absolutely anyone is welcome to leave reviews, and all reviews are treated with equal weight. -You don't need to be an Elder Rustacean to be useful here: anyone can catch missing tests, unclear docs, logic errors, and so on. If you're new to Rust or Bevy, submitting reviews is great way to learn things and acquaint yourself with the internals of the engine. +You don't need to be an Elder Rustacean to be useful here: anyone can catch missing tests, unclear docs, logic errors, and so on. If you're new to Rust or Bevy, submitting reviews is a great way to learn things and acquaint yourself with the internals of the engine. If you do have specific skills (e.g. advanced familiarity with `unsafe` code, rendering knowledge, or web development experience) or experience with a specific problem, that's fantastic! We suggest trying to prioritize those areas to ensure we get appropriate expertise where we need it. @@ -58,7 +58,7 @@ We love getting code contributions from the community, and there's plenty of wor If you already know what you want to work on, all you have to do is make your changes and submit a pull request! The page on [Opening Pull Requests](@/learn/contribute/helping-out/opening-pull-requests.md) is there to help if you get stuck. {% callout() %} -When working on the engine's code, it's a good idea to introduce yourself in the `#engine-dev` channel on [Discord](https://discord.gg/bevy) and tell people about your plans. Communicating your progress early and often can help you avoid avoid headaches and disagreements during code review. +When working on the engine's code, it's a good idea to introduce yourself in the `#engine-dev` channel on [Discord](https://discord.gg/bevy) and tell people about your plans. Communicating your progress early and often can help you avoid headaches and disagreements during code review. {% end %} ## Writing docs and examples diff --git a/content/learn/contribute/project-information/release-process.md b/content/learn/contribute/project-information/release-process.md index 33db38f71b..cfa1a90c5d 100644 --- a/content/learn/contribute/project-information/release-process.md +++ b/content/learn/contribute/project-information/release-process.md @@ -13,7 +13,7 @@ This means that Bevy releases a new version roughly once every three to four mon During a three-month development cycle, Maintainers collect important PRs and issues into a GitHub Milestone. Issues included in the milestone are given priority, and the community generally makes a best-effort attempt to merge as many of these as possible over the duration of the cycle. -In the lead-up to a release (generally about about two and a half months after the previous) we begin to aggressively purge the milestone of things that seem unlikely to be ready in time. The main things that tend to remain are: +In the lead-up to a release (generally about two and a half months after the previous) we begin to aggressively purge the milestone of things that seem unlikely to be ready in time. The main things that tend to remain are: - Quick and easy features under active development. - Fixes for important regressions or crashes. diff --git a/content/learn/migration-guides/0.11-to-0.12.md b/content/learn/migration-guides/0.11-to-0.12.md index 01bc95e684..be9e50592a 100644 --- a/content/learn/migration-guides/0.11-to-0.12.md +++ b/content/learn/migration-guides/0.11-to-0.12.md @@ -676,7 +676,7 @@ app.configure_schedules(build_settings);
App
-`Events::update_system` has been split off from the the type and can be found at `bevy_ecs::event::event_update_system`. +`Events::update_system` has been split off from the type and can be found at `bevy_ecs::event::event_update_system`. ### [Allow disjoint mutable world access via `EntityMut`](https://github.com/bevyengine/bevy/pull/9419) @@ -717,7 +717,7 @@ let scene = DynamicSceneBuilder::from_world(&world)
Input
-The default live zone bounds have been changed from `-0.95..=0.95` to `-1.0..=1.0` to align with more common usage. If you were relying on the old default, you can change change this by modifying [`GamepadSettings::default_axis_settings`](https://docs.rs/bevy/0.12.0/bevy/input/gamepad/struct.GamepadSettings.html#structfield.default_axis_settings). +The default live zone bounds have been changed from `-0.95..=0.95` to `-1.0..=1.0` to align with more common usage. If you were relying on the old default, you can change this by modifying [`GamepadSettings::default_axis_settings`](https://docs.rs/bevy/0.12.0/bevy/input/gamepad/struct.GamepadSettings.html#structfield.default_axis_settings). ### [Rename bevy_math::rects conversion methods](https://github.com/bevyengine/bevy/pull/9159) diff --git a/content/learn/migration-guides/0.7-to-0.8.md b/content/learn/migration-guides/0.7-to-0.8.md index bdae214473..0715337314 100644 --- a/content/learn/migration-guides/0.7-to-0.8.md +++ b/content/learn/migration-guides/0.7-to-0.8.md @@ -356,7 +356,7 @@ Please [file an issue](https://github.com/bevyengine/bevy/issues) to help detail * a `HandleId`, use `&Handle::weak(id)` instead, to create a weak handle. You may have been able to store a type safe `Handle` instead. * a `HandleUntyped`, use `&handle_untyped.typed_weak()` to create a weak handle of the specified type. This is most likely to be the useful when using [load_folder](https://docs.rs/bevy_asset/latest/bevy_asset/struct.AssetServer.html#method.load_folder) * a `&str` or anything not previously mentioned: `assets.get(&assets.get_handle("asset/path.ron"))` -* a `Handle` of of a different type, consider whether this is the correct handle type to store. If it is (i.e. the same handle id is used for multiple different Asset types) use `Handle::weak(handle.id)` to cast to a different type. +* a `Handle` of a different type, consider whether this is the correct handle type to store. If it is (i.e. the same handle id is used for multiple different Asset types) use `Handle::weak(handle.id)` to cast to a different type. ### [Allow higher order systems](https://github.com/bevyengine/bevy/pull/4833) diff --git a/content/learn/migration-guides/0.9-to-0.10.md b/content/learn/migration-guides/0.9-to-0.10.md index 1b4b925d30..f496eca915 100644 --- a/content/learn/migration-guides/0.9-to-0.10.md +++ b/content/learn/migration-guides/0.9-to-0.10.md @@ -242,7 +242,7 @@ enum AppState { `App::add_state` no longer takes an argument: the starting state is now controlled via the `Default` impl for your state type. -To access the current state of the the `States` type above, use `Res`, and access the tuple field via `.0`. +To access the current state of the `States` type above, use `Res`, and access the tuple field via `.0`. To queue up a state transition, use `ResMut>` and call [`.set(AppState::Menu)`](https://docs.rs/bevy/latest/bevy/ecs/schedule/struct.NextState.html#method.set). State transitions are now applied via the `apply_state_transitions` exclusive system, a copy of which is added [`CoreSet::StateTransitions`](https://docs.rs/bevy/latest/bevy/app/enum.CoreSet.html) when you call `App::add_state`. You can add more copies as needed, specific to the state being applied. diff --git a/content/news/2020-08-10-introducing-bevy/index.md b/content/news/2020-08-10-introducing-bevy/index.md index 7b6a551cf9..16dedda3a6 100644 --- a/content/news/2020-08-10-introducing-bevy/index.md +++ b/content/news/2020-08-10-introducing-bevy/index.md @@ -105,7 +105,7 @@ And of course you can also create your own plugins. In fact, all engine and game ## Bevy ECS -All Bevy engine and game logic is built on top of a custom [Entity Component System](https://en.wikipedia.org/wiki/Entity_component_system) (or ECS for short). Entity Component Systems are a software paradigm that involves breaking data up into Components. Entities are unique ids assigned to groups of Components. For example, one entity might might have a `Position` and `Velocity` component, whereas another entity might have a `Position` and `UI` component. Systems are logic that runs on a specific set of component types. You might have a `movement` system that runs on all entities with a `Position` and `Velocity` component. +All Bevy engine and game logic is built on top of a custom [Entity Component System](https://en.wikipedia.org/wiki/Entity_component_system) (or ECS for short). Entity Component Systems are a software paradigm that involves breaking data up into Components. Entities are unique ids assigned to groups of Components. For example, one entity might have a `Position` and `Velocity` component, whereas another entity might have a `Position` and `UI` component. Systems are logic that runs on a specific set of component types. You might have a `movement` system that runs on all entities with a `Position` and `Velocity` component. The ECS pattern encourages clean, decoupled designs by forcing you to break up your app data and logic into its core components. diff --git a/generate-assets/src/lib.rs b/generate-assets/src/lib.rs index cb45d58329..effb9fd1a9 100644 --- a/generate-assets/src/lib.rs +++ b/generate-assets/src/lib.rs @@ -556,7 +556,7 @@ fn search_bevy_in_manifest_dependencies( /// Gets the bevy version from the `Cargo.toml` bevy dependency provided. /// /// Returns the version number if available. -/// If is is a git dependency, return either "main" or "git" for anything that isn't "main". +/// If is a git dependency, return either "main" or "git" for anything that isn't "main". fn get_bevy_manifest_dependency_version(dep: &cargo_toml::Dependency) -> Option { match dep { cargo_toml::Dependency::Simple(version) => Some(version.to_string()), diff --git a/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md b/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md index 7d5d40bf04..2fd1fb1973 100644 --- a/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md +++ b/release-content/0.14/release-notes/12792_Implement_Auto_Exposure_plugin.md @@ -1,4 +1,4 @@ -Since **Bevy 0.13**, you can [configure the the EV100 of a camera](/news/bevy-0-13/#camera-exposure), which allows you to adjust the exposure of the camera in a physically based way. This also allows you to dynamically change the exposure values for various effects. However, this is a manual process and requires you to adjust the exposure values yourself. +Since **Bevy 0.13**, you can [configure the EV100 of a camera](/news/bevy-0-13/#camera-exposure), which allows you to adjust the exposure of the camera in a physically based way. This also allows you to dynamically change the exposure values for various effects. However, this is a manual process and requires you to adjust the exposure values yourself. **Bevy 0.14** introduces **Auto Exposure**, which automatically adjusts the exposure of your camera based on the brightness of the scene. This can be useful when you want to create the feeling of a very high dynamic range, since your eyes also adjust to large changes in brightness. Note that this is not a replacement for hand-tuning the exposure values, rather an additional tool that you can use to create dramatic effects when brightness changes rapidly. Check out this video recorded from the [example](https://github.com/bevyengine/bevy/tree/v0.14.0/examples/3d/auto_exposure.rs) to see it in action!