i still haven't actually tested any of this yet lol but in theory it should all work
i'll probably either actually test az-client and fix all the remaining issues or update the azalea crate next
ok also one thing that i'm not particularly happy with is how the packet handlers are doing ugly queries like
```rs
let local_player = ecs
.query::<&LocalPlayer>()
.get_mut(ecs, player_entity)
.unwrap();
```
i think the right way to solve it would be by putting every packet handler in its own system but i haven't come up with a way to make that not be really annoying yet
now it runs the schedule only when we get a tick or packet 😄
also i systemified some more functions and did other random fixes so az-world and az-physics compile
making azalea-client use the ecs is almost done! all the hard parts are done now i hope, i just have to finish writing all the code so it actually works
i guess i'm using bevy_app now too huh
it's necessary for plugins and it lets us control the tick rate anyways so it's fine i think
i'm still not 100% sure how packet handling that interacts with the world will work, but i think if i can sneak the ecs world into there it'll be fine. Can't put packet handling in the schedule because that'd make it tick-bound, which it's not (technically it'd still work but it'd be wrong and anticheats might realize).
i'm probably gonna change it so azalea entity ids are separate from minecraft entity ids next (so stuff like player ids can be consistent and we don't have to wait for the login packet)
and other fun changes
i still need to make ticking use the ecs but that's tricker, i'm considering using bevy_ecs systems for those
bevy_ecs systems can't be async but the only async things in ticking is just sending packets which can just be done as a tokio task so that's not a big deal
