Releases: BlackPhlox/bevy_dolly
bevy_dolly 0.0.5 - Bevy 0.15
What's Changed
- Fix prelude when default features are disabled by @philpax in #68
- Update to Bevy 0.15 by @BlackPhlox in #70
Special thanks to @ethereumdegen for working on the initial migration used for updating to 0.15 #69
New Contributors
Full Changelog: 0.0.4...0.0.5
Contributors
Assets 2
bevy_dolly 0.0.4 - Bevy 0.14
What's Changed
- Upgrade to Bevy 0.14 by @rparrett in #58
- Renamed Player to DollyCameraPlayer, updated info in examples by @BlackPhlox in #60
- Added inspector_egui example by @BlackPhlox in #62
- Sync - Merge pull request #62 from BlackPhlox/bevy_0.14 by @BlackPhlox in #64
- Fix prelude and added auto crate prep script by @BlackPhlox in #65
- Fixed prelude usage by @BlackPhlox in #66
Full Changelog: 0.0.3...0.0.4
Contributors
Assets 2
bevy_dolly 0.0.3 - Bevy 0.13
What's Changed
- Added bevy main ci check by @BlackPhlox in #48
- Update main.yml by @BlackPhlox in #50
- Only add
bevy_pbrif helpers are enabled by @rparrett in #53 - Upgrade to Bevy 0.13 by @rparrett in #51
- Create crate_prep.sh by @BlackPhlox in #56 for easier publishing
New Contributors
Full Changelog: 0.0.2...0.0.3
Contributors
Assets 2
bevy_dolly 0.0.2 - Bevy 0.12
What's Changed
- Update to bevy 0.12 by @BeastLe9enD in #39
- Upgraded to Bevy 0.12 and latest LWIM by @ActuallyHappening & @BlackPhlox in #42
- Fix main merge error by @BlackPhlox in #46
- Update README.md by @BlackPhlox in #47
New Contributors
- @BeastLe9enD made their first contribution in #39
Full Changelog: 0.0.1...0.0.2
Contributors
Assets 2
bevy_dolly 0.0.1 - Crate Release!
Hello crates.io!
Finally! bevy_dolly is now a crate!
I've had my hands full the last many months.
However, thanks to the great work of @nvdaz and my workload have lightened a bit, I was now able to fix the dependencies issues that prevented me from publishing to crates.io.
Dependencies
One issue that has prevented me from publishing soon was the fact that dependency on dolly.
Originally, the project started out by using dolly as a crate which went well using the newtype pattern.
The transforms dolly is using is its own handed-agnostic implementation as opposed to Bevy's own transform.
Me, not knowing (and still don't) what the best cause of action is, I decided to just create translation methods between the two.
However, I later realized the API ergonomics of this is quite poor as the user has to translate themselves every time, and in some cases had to deal with two types called Transform.
Why not upstream?
This is in my opinion the best cause of action, as I would like bevy_dolly to depend directly on the dolly crate instead of the current fork. However, that will require a lot of upstreaming of additional attributes to support a bevy feature and will add bloat to the dolly crate, and I'm not sure if that's something Tomasz would want. I'm personally still a newb when it comes to feature flags and given my limited time, is not something I have had the time to look into.
Why not native?
I have a lot of thoughts about this and have been back and forth about this matter over the span of the project. However, in the end, I think, in my opinion, defeats the purpose of the project's name and my personal wish for always prioritizing upstreaming when able. And so I will make my most sincere apologies to @slyedoc for not going with his contributions for a more native plugin, despite accepting your pull request #6 and not reaching out when I made the final decision. Your work, time, and effort should not go unrecognized. Thus I've kept the contributions to a separate branch slyedoc if you or anyone will create a new project to extend on for a native bevy implementation.
An ask for help
As said before, I'm not sure what the best cause of action is, and maybe there is a simple solution than I outlined, if so, I haven't had the time to spot this yet, if anyone would want to give guidance, raise an issue or pr, they are very welcome.
No reflection/bevy_editor_pls support ?
As flagged by @janhohenheim in #34. There is currently no support for reflections, which means that there is no runtime debugging. This will properly be the next thing I'm looking into unless someone flags things otherwise.
API Ergonomics
As mentioned at the top of the repo's readme, the API for ``bevy_dolly` is still up in the air. I like how it currently has turned out, but I'm uncertain if this gonna be the final structure. Hence, this is one of the reasons why I have hesitated to publish this as a crate. If anyone has input and feedback, please create an issue, I'll be more than happy to discuss what will be the best way forward. I'm also going to a rust meetup at the end of the month, where one of the participants is the creator and maintainer of axum who has worked with a lot of API ergonomics, where I might be able to get some feedback from him as well.
What's next? And what about bevy_config_cam?
The reason for no further updates to config_cam is much driven by the same factors as with bevy_dolly.
I wanted to reach a point for bevy_dolly which was solid enough to begin re-thinking how it should look like,
but as said, the time for me to do it wasn't there and thus no crate releases have been made since bevy 0.7 for which I'm sorry.
But since I've now committed myself to publishing bevy_dolly as a crate. I think it is time to revisit bevy_config_cam and make it more configurable and composable using bevy_dolly as the underlying crate to accomplish this.
Conclusion
All in all, I appreciate all help I've received and hope that this release can help further bevy's crate ecosystem moving forward!
Best regards
- BlackPhlox (Mikkel)
Contributions!
- Fix the free look example by @superdump in #1
- Bevy native by @slyedoc in #6
- Use From instead of "2" methods by @janhohenheim in #25
- Use ScanCodes instead of KeyCodes by @janhohenheim in #31
- Update bevy to 0.11 and leafwing-input-manager to 0.10 by @nvdaz in #36
Full Changelog: https://github.com/BlackPhlox/bevy_dolly/commits/0.0.1
