# Bevy World Utils [![https://crates.io/crates/micro_bevy_world_utils](https://img.shields.io/crates/v/micro_bevy_world_utils?style=for-the-badge)](https://crates.io/crates/micro_bevy_world_utils) [![https://docs.rs/micro_bevy_world_utils](https://img.shields.io/docsrs/micro_bevy_world_utils?style=for-the-badge)](https://docs.rs/micro_bevy_world_utils) Handy, reusable utilities for working with direct world access in a Bevy exclusive system ## Installation `cargo add micro_bevy_world_utils` ## Usage Check out [the docs](https://docs.rs/micro_bevy_world_utils) to get a full list of functions. Each function will take at least an `&mut World`, as well as whatever parameters it is working on. ### Sending events If you're working on highly branching code in an exclusive system (e.g. monolith collision handlers), instead of creating an event writer for every possible event, just call `send_event(&mut World, EventType)`; the type of event writer to use is inferred from the event parameter ### Sort entities based on components If you have two entities, and you want to figure out which one contains a certain component, or to sort based on parent components, you can call one of the `get_[specifier]_[specifier]_entities`. Check the docs for more in depth information on how these work; at a basic level, you pass in two entities and will receive those entities back in a sorted tuple, where the left and right entities correspond to the left and right component parameters. E.g.: `get_left_right_entities::(world, first_entity, second_entity)` will mean that the first returned tuple entry has the "GroundSensor" component, and the second will have the "GroundTag" component. If the conditions cannot be fulfilled with the given entities, the result will be `None` ## Bevy Compatibility | world_utiles ver | bevy ver | |------------------|----------| | 0.5 | 0.14 | | 0.4 | 0.13 | | 0.3 | 0.11 | | 0.2 | 0.10 | | 0.1 | 0.9 |