Better patches ci #20
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Objective Fix Pr CI failing over dead code in tests and main branch CI failing over a missing semicolon. Fixes bevyengine#12620. ## Solution Add dead_code annotations and a semicolon.
…engine#12605) # Objective Lets say I have the following `.meta` file: ```RON ( meta_format_version: "1.0", asset: Ignore, ) ``` When a file is inside the `assets` directory and processing is enabled, the processor will copy the file into `imported_assets` although it should be ignored and therefore not copied. ## Solution - I added a simple check that does not copy the assets if the AssetAction is `Ignore`. ## Migration Guide - The public `ProcessResult` enum now has a `ProcessResult::Ignore` variant that must be handled.
# Objective - Have even fewer typos. ## Solution - Fix typos found. In this case, `plateform`. Co-authored-by: François Mockers <[email protected]>
…ne#12630) # Objective - A new example `rounded_borders` was introduced in bevyengine#12500, similar to the `borders` example, but containing labels to describe each border, leaving inconsistency between the examples. ## Solution - Update the `borders` example to be consistent with `rounded_borders`. Co-authored-by: François Mockers <[email protected]>
# Objective - Fixes bevyengine#12570 ## Solution Previously, cardinal splines constructed by `CubicCardinalSpline` would leave out their endpoints when constructing the cubic curve segments connecting their points. (See the linked issue for details.) Now, cardinal splines include the endpoints. For instance, the provided usage example ```rust let points = [ vec2(-1.0, -20.0), vec2(3.0, 2.0), vec2(5.0, 3.0), vec2(9.0, 8.0), ]; let cardinal = CubicCardinalSpline::new(0.3, points).to_curve(); let positions: Vec<_> = cardinal.iter_positions(100).collect(); ``` will actually produce a spline that connects all four of these points instead of just the middle two "interior" points. Internally, this is achieved by duplicating the endpoints of the vector of control points before performing the construction of the associated `CubicCurve`. This amounts to specifying that the tangents at the endpoints `P_0` and `P_n` (say) should be parallel to `P_1 - P_0` and `P_n - P_{n-1}`. --- ## Migration Guide Any users relying on the old behavior of `CubicCardinalSpline` will have to truncate any parametrizations they used in order to access a curve identical to the one they had previously. This would be done by chopping off a unit-distance segment from each end of the parametrizing interval. For instance, if a user's existing code looks as follows ```rust fn interpolate(t: f32) -> Vec2 { let points = [ vec2(-1.0, -20.0), vec2(3.0, 2.0), vec2(5.0, 3.0), vec2(9.0, 8.0), ]; let my_curve = CubicCardinalSpline::new(0.3, points).to_curve(); my_curve.position(t) } ``` then in order to obtain similar behavior, `t` will need to be shifted up by 1, since the output of `CubicCardinalSpline::to_curve` has introduced a new segment in the interval [0,1], displacing the old segment from [0,1] to [1,2]: ```rust fn interpolate(t: f32) -> Vec2 { let points = [ vec2(-1.0, -20.0), vec2(3.0, 2.0), vec2(5.0, 3.0), vec2(9.0, 8.0), ]; let my_curve = CubicCardinalSpline::new(0.3, points).to_curve(); my_curve.position(t+1) } ``` (Note that this does not provide identical output for values of `t` outside of the interval [0,1].) On the other hand, any user who was specifying additional endpoint tangents simply to get the curve to pass through the right points (i.e. not requiring exactly the same output) can simply omit the endpoints that were being supplied only for control purposes. --- ## Discussion ### Design considerations This is one of the two approaches outlined in bevyengine#12570 — in this PR, we are basically declaring that the docs are right and the implementation was flawed. One semi-interesting question is how the endpoint tangents actually ought to be defined when we include them, and another option considered was mirroring the control points adjacent to the endpoints instead of duplicating them, which would have had the advantage that the expected length of the corresponding difference should be more similar to that of the other difference-tangents, provided that the points are equally spaced. In this PR, the duplication method (which produces smaller tangents) was chosen for a couple reasons: - It seems to be more standard - It is exceptionally simple to implement - I was a little concerned that the aforementioned alternative would result in some over-extrapolation ### An annoyance If you look at the code, you'll see I was unable to find a satisfactory way of doing this without allocating a new vector. This doesn't seem like a big problem given the context, but it does bother me. In particular, if there is some easy parallel to `slice::windows` for iterators that doesn't pull in an external dependency, I would love to know about it.
# Objective - bevyengine#12500 added dead code to the ui shader ## Solution - Remove it
# Objective Fixes bevyengine#12628. ## Solution Added several check for NaN values in `add_measurement`.
rparrett
force-pushed
the
better-patches-ci
branch
from
ce40f25
to
e2fba47
Compare
# Objective - It can be useful to have access to the path of the current asset being processed, for example if you want to need a second file that is relative to the current file being processed. ## Solution - I added a `path()` function to the `ProcessContext`
# Objective - Fixes bevyengine#12202 ## Solution - Implements `Animatable` for all color types implementing arithmetic operations. - the colors returned by `Animatable`s methods are already clamped. - Adds a `color_animation.rs` example. - Implements the `*Assign` operators for color types that already had the corresponding operators. This is just a 'nice to have' and I am happy to remove this if it's not wanted. --- ## Changelog - `bevy_animation` now depends on `bevy_color`. - `LinearRgba`, `Laba`, `Oklaba` and `Xyza` implement `Animatable`. --------- Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: Zachary Harrold <[email protected]>
# Objective Fixes bevyengine#12200 . ## Solution I added a Hue Trait with the rotate_hue method to enable hue rotation. Additionally, I modified the implementation of animations in the animated_material sample. --- ## Changelog - Added a `Hue` trait to `bevy_color/src/color_ops.rs`. - Added the `Hue` trait implementation to `Hsla`, `Hsva`, `Hwba`, `Lcha`, and `Oklcha`. - Updated animated_material sample. ## Migration Guide Users of Oklcha need to change their usage to use the with_hue method instead of the with_h method. --------- Co-authored-by: Pablo Reinhardt <[email protected]> Co-authored-by: Alice Cecile <[email protected]>
# Objective - went through bounding_2d example with a fine-toothed comb and found two small issues ## Solution - pulled "draw a small filled-in circle" logic into a function - removed impotent addition of aabb / circle origin (identically `Vec2(0.0, 0.0)`)
# Objective I'm reading through the ecs query code for the first time, and updating the docs: - fixed some typos - added some docs about things I was confused about (in particular what the difference between `matches_component_set` and `update_component_access` was)
# Context [GitHub Discussion Link](bevyengine#12506) # Objective - **Clarity:** More explicit representation of a common geometric primitive. - **Convenience:** Provide methods tailored to 3D triangles (area, perimeters, etc.). ## Solution - Adding the `Triangle3d` primitive into the `bevy_math` crate. --- ## Changelog ### Added - `Triangle3d` primitive to the `bevy_math` crate ### Changed - `Triangle2d::reverse`: the first and last vertices are swapped instead of the second and third. --------- Co-authored-by: Miles Silberling-Cook <[email protected]> Co-authored-by: Joona Aalto <[email protected]>
# Objective
- Allow registering of systems from Commands with
`Commands::register_one_shot_system`
- Make registering of one shot systems more easy
## Solution
- Add the Command `RegisterSystem` for Commands use.
- Creation of SystemId based on lazy insertion of the System
- Changed the privacy of the fields in SystemId so Commands can return
the SystemId
---
## Changelog
### Added
- Added command `RegisterSystem`
- Added function `Commands::register_one_shot_system`
- Added function `App::register_one_shot_system`
### Changed
- Changed the privacy and the type of struct tuple to regular struct of
SystemId
## Migration Guide
- Changed SystemId fields from tuple struct to a normal struct
If you want to access the entity field, you should use
`SystemId::entity` instead of `SystemId::0`
## Showcase
> Before, if you wanted to register a system with `Commands`, you would
need to do:
```rust
commands.add(|world: &mut World| {
let id = world.register_system(your_system);
// You would need to insert the SystemId inside an entity or similar
})
```
> Now, you can:
```rust
let id = commands.register_one_shot_system(your_system);
// Do what you want with the Id
```
---------
Co-authored-by: Alice Cecile <[email protected]>
Co-authored-by: Pablo Reinhardt <[email protected]>
# Objective - Implements maths and `Animatable` for `Srgba` as suggested [here](bevyengine#12617 (comment)). ## Solution - Implements `Animatable` and maths for `Srgba` just like their implemented for other colors. --- ## Changelog - Updated the example to mention `Srgba`. ## Migration Guide - The previously existing implementation of mul/div for `Srgba` did not modify `alpha` but these operations do modify `alpha` now. Users need to be aware of this change.
Also, added additional tests for the hue interpolation. Fixes bevyengine#12632 Fixes bevyengine#12631
# Objective Fixes issue bevyengine#12613 - the RNG used in examples is _deterministic_, but its implementation is not _portable_ across platforms. We want to switch to using a portable RNG that does not vary across platforms, to ensure certain examples play out the same way every time. ## Solution Replace all occurences of `rand::rngs::StdRng` with `rand_chacha::ChaCha8Rng`, as recommended in issue bevyengine#12613 --- ## Changelog - Add `rand_chacha` as a new dependency (controversial?) - Replace all occurences of `rand::rngs::StdRng` with `rand_chacha::ChaCha8Rng`
… (bevyengine#12655) Fixes bevyengine#12600 ## Solution Removed Into<AssetId<T>> for Handle<T> as proposed in Issue conversation, fixed dependent code ## Migration guide If you use passing Handle by value as AssetId, you should pass reference or call .id() method on it Before (0.13): `assets.insert(handle, value);` After (0.14): `assets.insert(&handle, value);` or `assets.insert(handle.id(), value);`
…bevyengine#12661) # Objective - Clarify that `ButtonInput::just_release` and `ButtonInput::just_pressed` don't imply information about the state of `ButtonInput::pressed` or their counterparts.
…bevyengine#12596) # Objective * Adopted bevyengine#12025 to fix merge conflicts * In some cases we used manual impls for certain types, though they are (at least, now) unnecessary. ## Solution * Use macros and reflecting-by-value to avoid this clutter. * Though there were linker issues with Reflect and the CowArc in AssetPath (see bevyengine#9747), I checked these are resolved by using #[reflect_value]. --------- Co-authored-by: soqb <[email protected]> Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: James Liu <[email protected]>
# Objective I was reading some of the Archetype and Bundle code and was getting confused a little bit in some places (is the `archetype_id` in `AddBundle` the source or the target archetype id?). Small PR that adds some docstrings to make it easier for first-time readers.
…12559) # Objective Remove color specialization from `SpritePipeline` after it became useless in bevyengine#9597 ## Solution Removed the `COLORED` flag from the pipeline key and removed the specializing the pipeline over it. --- ## Changelog ### Removed - `SpritePipelineKey` no longer contains the `COLORED` flag. The flag has had no effect on how the pipeline operates for a while. ## Migration Guide - The raw values for the `HDR`, `TONEMAP_IN_SHADER` and `DEBAND_DITHER` flags have changed, so if you were constructing the pipeline key from raw `u32`s you'll have to account for that.
…ht/mod.rs (bevyengine#12656) # Objective Follow up from PR bevyengine#12369 to extract lighting structs from light/mod.rs into their own file. Part of the Purdue Refactoring Team's goals issue bevyengine#12349 ## Solution - Moved PointLight from light/mod.rs to light/point_light.rs - Moved SpotLight from light/mod.rs to light/spot_light.rs - Moved DirectionalLight from light/mod.rs to light/directional_light.rs
# Objective - In bevyengine#12366 `![cfg_attr(docsrs, feature(doc_auto_cfg))] `was added. But to apply it it needs `--cfg=docsrs` in rustdoc-args. ## Solution - Apply `--cfg=docsrs` to all crates and CI. I also added `[package.metadata.docs.rs]` to all crates to avoid adding code behind a feature and forget adding the metadata. Before:  After: 
…async functions) (bevyengine#12638) # Objective get_asset_paths tries to check whether a folder is empty, and if so delete it. However rather than checking whether any subfolder contains files it checks whether _all_ subfolders have files. Also cleanup various BoxedFutures in async recursive functions like these, rust 1.77 now allows recursive async functions (albeit still by boxing), hurray! This is a followup to bevyengine#12550 (sorta). More BoxedFuture stuff can be removed now that rust 1.77 is out, which can use async recursive functions! This is mainly just cleaner code wise - the recursion still boxes the future so not much to win there. PR is mainly whitespace changes so do disable whitespace diffs for easier review.
# Objective We already collect a lot of system information on startup when possible but we don't make this information available. With the upcoming work on a diagnostic overlay it would be useful to be able to display this information. ## Solution Make the already existing SystemInfo a Resource --- ## Changelog Added `SystemInfo` Resource --------- Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: Afonso Lage <[email protected]>
# Objective Missing docs ## Solution Add docs paraphrased from the Cart's mouth: https://discord.com/channels/691052431525675048/691052431974465548/1172305792154738759 > It follows the natural "results" of right handed y-up. The default camera will face "forward" in -Z, with +X being "right". The RH y-up setup is reasonably common. Thats why I asked for existing examples.I think we should appeal to the masses here / see how other RH Y-up 3D packages / engines handle this --------- Co-authored-by: Robert Swain <[email protected]>
# Objective Fixes bevyengine#12388 ## Solution - Removing the plane3d and adding rect3d primitive mesh
bevyengine#12962) # Objective Make visibility system ordering explicit. Fixes bevyengine#12953. ## Solution Specify `CheckVisibility` happens after all other `VisibilitySystems` sets have happened. --------- Co-authored-by: Elabajaba <[email protected]>
# Objective - General clenup of the primitives in `bevy_math` - Add `eccentricity()` to `Ellipse` ## Solution - Moved `Bounded3d` implementation for `Triangle3d` to the `bounded` module - Added `eccentricity()` to `Ellipse` - `Ellipse::semi_major()` and `::semi_minor()` now accept `&self` instead of `self` - `Triangle3d::is_degenerate()` actually uses `f32::EPSILON` as documented - Added tests for `Triangle3d`-maths --------- Co-authored-by: Joona Aalto <[email protected]> Co-authored-by: Miles Silberling-Cook <[email protected]>
…en despawning ui nodes (bevyengine#13000) # Objective Sometimes when despawning a ui node in the PostUpdate schedule it panics. This is because both a despawn command and insert command are being run on the same entity. See this example code: ```rs use bevy::{prelude::*, ui::UiSystem}; #[derive(Resource)] struct SliceSquare(Handle<Image>); fn main() { App::new() .add_plugins(DefaultPlugins) .add_systems(Startup, setup) .add_systems(Update, create_ui) .add_systems(PostUpdate, despawn_nine_slice.after(UiSystem::Layout)) .run(); } fn setup(mut commands: Commands, asset_server: Res<AssetServer>) { commands.spawn(Camera2dBundle::default()); commands.insert_resource(SliceSquare(asset_server.load("textures/slice_square.png"))); } fn create_ui(mut commands: Commands, slice_square: Res<SliceSquare>) { commands.spawn(( NodeBundle { style: Style { width: Val::Px(200.), height: Val::Px(200.), ..default() }, background_color: Color::WHITE.into(), ..default() }, UiImage::new(slice_square.0.clone()), ImageScaleMode::Sliced(TextureSlicer { border: BorderRect::square(220.), center_scale_mode: SliceScaleMode::Stretch, sides_scale_mode: SliceScaleMode::Stretch, max_corner_scale: 1., }), )); } fn despawn_nine_slice(mut commands: Commands, mut slices: Query<Entity, With<ImageScaleMode>>) { for entity in slices.iter_mut() { commands.entity(entity).despawn_recursive(); } } ``` This code spawns a UiNode with a sliced image scale mode, and despawns it in the same frame. The bevy_ui::texture_slice::compute_slices_on_image_change system tries to insert the ComputedTextureSlices component on that node, but that entity is already despawned causing this error: ```md error[B0003]: Could not insert a bundle (of type `bevy_ui::texture_slice::ComputedTextureSlices`) for entity Entity { index: 2, generation: 3 } because it doesn't exist in this World. See: https://bevyengine.org/learn/errors/#b0003 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Encountered a panic when applying buffers for system `bevy_ui::texture_slice::compute_slices_on_image_change`! Encountered a panic in system `bevy_ecs::schedule::executor::apply_deferred`! Encountered a panic in system `bevy_app::main_schedule::Main::run_main`! ``` Note that you might have to run the code a few times before this error appears. ## Solution Use try_insert instead of insert for non critical inserts in the bevy_ui crate. ## Some notes In a lot of cases it does not makes much sense to despawn ui nodes after the layout system has finished. Except maybe if you delete the root ui node of a tree. I personally encountered this issue in bevy `0.13.2` with a system that was running before the layout system. And in `0.13.2` the `compute_slices_on_image_change` system was also running before the layout system. But now it runs after the layout system. So the only way that this bug appears now is if you despawn ui nodes after the layout system. So I am not 100% sure if using try_insert in this system is the best option. But personally I still think it is better then the program panicking. However the `update_children_target_camera` system does still run before the layout system. So I do think it might still be able to panic when ui nodes are despawned before the layout system. Though I haven't been able to verify that.
Grammar changes only.
) # Objective - Many of our CI workflows contain a `NIGHTLY_TOOLCHAIN` environmental variable. - This specifies which nightly to use. If there is a bug in one of the nightlies, we can pin the toolchain to be an earlier version. - Both the daily and weekly workflows do not use the nightly compiler, but still have a `NIGHTLY_TOOLCHAIN` variable. ## Solution - Delete the unused variable.
…ngine#12954) # Objective - Closes bevyengine#12930. ## Solution - Add a corresponding optional field on `Window` and `ExtractedWindow` --- ## Changelog ### Added - `wgpu`'s `desired_maximum_frame_latency` is exposed through window creation. This can be used to override the default maximum number of queued frames on the GPU (currently 2). ## Migration Guide - The `desired_maximum_frame_latency` field must be added to instances of `Window` and `ExtractedWindow` where all fields are explicitly specified.
…vyengine#12998) # Objective Fixes bevyengine#12900 ## Solution Added comment to example indicating that additional audio formats are supported when the feature is added. --------- Co-authored-by: James Liu <[email protected]>
# Objective - Fixes bevyengine#13024. ## Solution - Run `cargo clippy --target wasm32-unknown-unknown` until there are no more errors. - I recommend reviewing one commit at a time :) --- ## Changelog - Fixed Clippy lints for `wasm32-unknown-unknown` target. - Updated `bevy_transform`'s `README.md`.
# Objective - The docs says the WireframeColor is supposed to override the default global color but it doesn't. ## Solution - Use WireframeColor to override global color like docs said it was supposed to do. - Updated the example to document this feature - I also took the opportunity to clean up the code a bit Fixes bevyengine#13032
…functions (bevyengine#13044) # Objective Fix bevyengine#2128. Both `Query::new_archetype` and `SystemParam::new_archetype` do not check if the `Archetype` comes from the same World the state is initialized from. This could result in unsoundness via invalid accesses if called incorrectly. ## Solution Make them `unsafe` functions and lift the invariant to the caller. This also caught one instance of us not validating the World in `SystemState::update_archetypes_unsafe_world_cell`'s implementation. --- ## Changelog Changed: `QueryState::new_archetype` is now an unsafe function. Changed: `SystemParam::new_archetype` is now an unsafe function. ## Migration Guide `QueryState::new_archetype` and `SystemParam::new_archetype` are now an unsafe functions that must be sure that the provided `Archetype` is from the same `World` that the state was initialized from. Callers may need to add additional assertions or propagate the safety invariant upwards through the callstack to ensure safety.
# Objective The warning mentions the function `add_state` which doesn't exist; replaced with `init_state`
# Objective - `MeshPipelineKey` use some bits for two things - First commit in this PR adds an assertion that doesn't work currently on main - This leads to some mesh topology not working anymore, for example `LineStrip` - With examples `lines`, there should be two groups of lines, the blue one doesn't display currently ## Solution - Change the `MeshPipelineKey` to be backed by a `u64` instead, to have enough bits
Adjusted the documentation to better describe the performance cost of `ButtonInput::any_just_pressed|any_just_released|any_pressed`. Each function iterates the full input, but each check is expected constant cost. It was described previously as a full input check, and a full internal list iteration, which I believe is incorrect.
# Objective Makes crate module docs render correctly in the docs for the monolithic library. Fixes bevyengine#13055. ## Solution Swap from ```rust pub mod foo { pub use bevy_foo::*; } ``` to ```rust pub use bevy_foo as foo; ```
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.20.8 to 1.20.9. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.20.9</h2> <h2>[1.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/44548ad17abdc3e4ebfa53252764e3ff21dbfa0f"><code>44548ad</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/73fb2cad756df30f27730df4ec7abb6e8088f682"><code>73fb2ca</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/21838b0e7d8402e8ede4de677fbfb84b6e226d5e"><code>21838b0</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1000">#1000</a> from epage/dba</li> <li><a href="https://github.com/crate-ci/typos/commit/ee32d77aba122c27b38006345490647394f2b699"><code>ee32d77</code></a> fix(dict): Don't correct dBA</li> <li><a href="https://github.com/crate-ci/typos/commit/56df0bd8d66ef3cc9f4c7e99f0b228cc5ff8dd47"><code>56df0bd</code></a> test(dict): Show dBA behavior</li> <li>See full diff in <a href="https://github.com/crate-ci/typos/compare/v1.20.8...v1.20.9">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective Allow parallel iteration over events, resolve bevyengine#10766 ## Solution - Add `EventParIter` which works similarly to `QueryParIter`, implementing a `for_each{_with_id}` operator. I chose to not mirror `EventIteratorWithId` and instead implement both operations on a single struct. - Reuse `BatchingStrategy` from `QueryParIter` ## Changelog - `EventReader` now supports parallel event iteration using `par_read().for_each(|event| ...)`. --------- Co-authored-by: James Liu <[email protected]> Co-authored-by: Pablo Reinhardt <[email protected]>
# Objective Add support so bevy_ui can correctly handle an UI hierarchy without a camera present. - Fixes bevyengine#12184 ## Solution As there was no default behavior for what should happen when a camera is not present in a UI hierarchy, the solution was based in defining that default behavior and improving the overall handling of this "exception". ## Changelog - Create default values to be used in upsert_node - Add flag to control warnings about no camera present - Create unit test no_camera_ui (to test if ui handles no camera present)
# Objective - rust-lang/rust#123905 has been merged, so the workaround introduced in bevyengine#12913 is no longer necessary. - Closes bevyengine#12968 ## Solution - Remove unecessary `allow` attribute - This is currently blocked until Rust beta updates. - Last tested with `rustc 1.78.0-beta.7 (6fd191292 2024-04-12)`.
# Objective Closes bevyengine#13017. ## Solution - Make `AppExit` a enum with a `Success` and `Error` variant. - Make `App::run()` return a `AppExit` if it ever returns. - Make app runners return a `AppExit` to signal if they encountered a error. --- ## Changelog ### Added - [`App::should_exit`](https://example.org/) - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) to the `bevy` and `bevy_app` preludes, ### Changed - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) is now a enum with 2 variants (`Success` and `Error`). - The app's [runner function](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.set_runner) now has to return a `AppExit`. - [`App::run()`](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.run) now also returns the `AppExit` produced by the runner function. ## Migration Guide - Replace all usages of [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) with `AppExit::Success` or `AppExit::Failure`. - Any custom app runners now need to return a `AppExit`. We suggest you return a `AppExit::Error` if any `AppExit` raised was a Error. You can use the new [`App::should_exit`](https://example.org/) method. - If not exiting from `main` any other way. You should return the `AppExit` from `App::run()` so the app correctly returns a error code if anything fails e.g. ```rust fn main() -> AppExit { App::new() //Your setup here... .run() } ``` --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective Fixes bevyengine#12470 This adds a examples for `ButtonInput` with `KeyCode`, `MouseButton`, and `GamepadButton`. It also includes an example of checking a multi-key combination, and checking multiple keys to mean roughly the same thing.
This reverts commit c312bb6.
Co-authored-by: BD103 <[email protected]>
rparrett
force-pushed
the
better-patches-ci
branch
from
e270f1f
to
e82657b
Compare
github-merge-queue bot
pushed a commit
to bevyengine/bevy
that referenced
this pull request
Apr 22, 2024
# Objective Fixes #12539 Improve [this CI output](https://github.com/bevyengine/bevy/actions/runs/8367408952/job/22909715870#step:7:11). ## Solution - Don't stop after the first failure. - Print the filename of the patch(es) that failed. - Clean up an unused package install while we're at it. Tested over here: rparrett#20 --------- Co-authored-by: BD103 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Test