azalea::container

Trait ContainerClientExt

Source 
pub trait ContainerClientExt {
    // Required methods
    fn open_container_at(
        &self,
        pos: BlockPos,
    ) -> impl Future<Output = Option<ContainerHandle>> + Send;
    fn open_inventory(&self) -> Option<ContainerHandle>;
    fn get_inventory(&self) -> ContainerHandleRef;
    fn get_held_item(&self) -> ItemStack;
}

Required Methods§

Source

fn open_container_at( &self, pos: BlockPos, ) -> impl Future<Output = Option<ContainerHandle>> + Send

Open a container in the world, like a chest. Use Client::open_inventory to open your own inventory.

let target_pos = bot
    .world()
    .read()
    .find_block(bot.position(), &azalea::registry::Block::Chest.into());
let Some(target_pos) = target_pos else {
    bot.chat("no chest found");
    return;
};
let container = bot.open_container_at(target_pos).await;
Source

fn open_inventory(&self) -> Option<ContainerHandle>

Open the player’s inventory. This will return None if another container is open.

Note that this will send a packet to the server once it’s dropped. Also, due to how it’s implemented, you could call this function multiple times while another inventory handle already exists (but you shouldn’t).

If you just want to get the items in the player’s inventory without sending any packets, use Client::menu, Menu::player_slots_range, and Menu::slots.

Source

fn get_inventory(&self) -> ContainerHandleRef

Returns a ContainerHandleRef to the client’s currently open container, or their inventory.

This will not send a packet to close the container when it’s dropped, which may cause anticheat compatibility issues if you modify your inventory without closing it afterwards.

To simulate opening your own inventory (like pressing ‘e’) in a way that won’t trigger anticheats, use Client::open_inventory.

To open a container in the world, use Client::open_container_at.

Source

fn get_held_item(&self) -> ItemStack

Get the item in the bot’s hotbar that is currently being held in its main hand.

Dyn Compatibility§

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors§