Open alice-i-cecile opened 2 years ago
Hi there! Never contributed before but want to give it a try. Can I help on this issue?
Hi @franciscoaguirre, that sounds great :) Are you comfortable with the process of making PRs in general? See https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md#contributing-code for a refresher if you need it.
This should be a straightforward PR: just drop the snippet into place, and write a simple test to verify that it works as expected :) Feel free to open a draft PR (that says "Closes #3392" in its body) and then ping me for questions in that thread (or ask around in #scenes-dev on Discord).
What is the actual use case here? This enables nested boxing, which i'd like to avoid unless absolutely necessary.
I don't immediately remember the end user use case right now. I suspect that #3694 will help.
IIRC someone wanted to store Box<dyn Reflect>
s in a component (possibly a Vec
of them), and still be able to reflect that component.
What is the actual use case here? This enables nested boxing, which i'd like to avoid unless absolutely necessary.
@cart this will allow to serialize structs with dyn Reflect
fields. For example, I have a struct that contains modified components from the last network tick (and components represented as dyn Reflect
) that I need send over the network. Is this a valid use case or is there a better way to achieve this?
Currently I creating a newtype with dyn Reflect
, clone TypeRegistry into a global variable and implement Serialize / Deserialize on this newtype using the global TypeRegistry
.
For example, I have a struct that contains modified components from the last network tick (and components represented as dyn Reflect) that I need send over the network. Is this a valid use case or is there a better way to achieve this?
For this, it feels like what we really want is better DynamicScene
support, and the ability to use those for that sort of diff-ing operation. We already have a tool for the serde of collections of dynamic components, but it's not clearly documented and the use case hasn't been fleshed out.
For this, it feels like what we really want is better DynamicScene support,
It looks like it can only be serialized to RON, which is not suitable for network transmission. Also DynamicEntity
contains only u32
. When sending over the network I need all Entity
bits from server and map it into the corresponding client entity using EntityMap.
But it would be great to improve it.
What is the actual use case here? This enables nested boxing, which i'd like to avoid unless absolutely necessary.
I ran into this while trying to write a task system for my game:
#[derive(Component, Reflect)]
struct MoveTask {
to: Vec3,
next_task: Box<dyn Reflect>
}
/* more tasks here ... */
#[derive(Component, Reflect)]
struct NoOpTask {
next_task: Box<dyn Reflect>
}
fn no_op_task_tick(
mut commands: Commands,
q_tasks: Query<(Entity, &NoOpTask)>
) {
for (entity, task) in &q_tasks {
commands.entity(entity).remove::<NoOpTask>();
if let Some(new_task) = task.next_task {
commands.entity().insert_reflect(new_task);
}
}
}
There might be a better way of doing this, like a command for inserting a Box<dyn Component>
.
I have found this to be something I would have used - also for a task system. My task steps were components that I pull out of a Vec<Box
What problem does this solve or what need does it fill?
Boxed Reflect trait objects should themselves be reflectable
What solution would you like?
Implement
Reflect
forBox<dyn Reflect>
.What alternative(s) have you considered?
None.
Additional context
Working snippet from @Davier: