entities not present when spawned in the same frame #8515

Activity

1. nablabla

   added

   C-BugAn unexpected or incorrect behaviorAn unexpected or incorrect behavior

   S-Needs-TriageThis issue needs to be labelledThis issue needs to be labelled

   on Apr 30, 2023
2. SkiFire13 commented on Apr 30, 2023

   

   SkiFire13

   on Apr 30, 2023

   Contributor

   More actions

   As the issue you linked explained this is a very complex feature since Commands can potentially modify anything in the World, and this would conflict with any other system that could potentially be running in parallel with it. The general solution is to put a apply_system_buffers system in between the two system, this way any pending command will be flushed before the second system run and so it will be able to see all the entities.

   👍React with 👍2Reacted by Gino Valente and alexniver
3. JoshLambda commented on May 6, 2023

   

   JoshLambda

   on May 6, 2023

   More actions

   And there's also an example for apply_system_buffers.

   👍React with 👍1Reacted by Alexey
4. james7132

   added

   A-ECSEntities, components, systems, and eventsEntities, components, systems, and events

   and removed

   S-Needs-TriageThis issue needs to be labelledThis issue needs to be labelled

   on May 9, 2023
5. volodalexey commented on Jun 26, 2023

   

   volodalexey

   on Jun 26, 2023

   More actions

   And there's also an example for apply_system_buffers.

   I faced with the same problem. Thanks!

   My solution.
   I have two systems:

   • spawn_game_over_menu - draws game over menu

   fn spawn_game_over_menu(mut commands: Commands, asset_server: Res<AssetServer>) {
     commands.spawn((TextBundle {
       ..default()
     }, FinalScoreText {},))
   }

   • update_final_score_text - update final-score text in game over menu

   fn update_final_score_text(
       mut text_query: Query<&mut Text, With<FinalScoreText>>,
   ) {
       if let Ok(mut text) = text_query.get_single_mut() {
         text.sections[0].value = format!("Final Score: {}", 1234);
       }
   }

   I do not want to set final-score while I am drawing the menu, I want to update this menu only once after it was created.
   I have change state to AppState::GameOver

   So the final solution I came up with:

   use bevy::prelude::{
       apply_system_buffers, App, IntoSystemAppConfig, IntoSystemAppConfigs, IntoSystemConfigs,
       OnEnter, Plugin,
   };
   
   pub struct GameOverMenuPlugin;
   
   impl Plugin for GameOverMenuPlugin {
       fn build(&self, app: &mut App) {
           app
               // OnEnter State Systems
               .add_systems(
                   (
                       spawn_game_over_menu,
                       apply_system_buffers,
                       update_final_score_text,
                   )
                       .chain()
                       .in_schedule(OnEnter(AppState::GameOver)),
               )
     }
   }
6. torsteingrindvik commented on Nov 16, 2023

   

   torsteingrindvik

   on Nov 16, 2023

   Contributor

   More actions

   The example is now this: https://github.com/bevyengine/bevy/blob/main/examples/ecs/apply_deferred.rs

   @nablabla I think this can be closed since you found your solution and it was not a bug?
7. nablabla commented on Nov 16, 2023

   

   nablabla

   on Nov 16, 2023

   Author

   More actions

   I don't think so, the above workaround is only for startup systems, and also skips a frame. I expect when I explicitly order systems that the second system or the same system can access entities that were created before
8. torsteingrindvik commented on Nov 17, 2023

   

   torsteingrindvik

   on Nov 17, 2023

   Contributor

   More actions

   I just meant that e.g. here: https://github.com/bevyengine/bevy/blob/main/crates/bevy_render/src/lib.rs#L74-L160
   apply_deferred is used in a way so that system A and system B will observe entity insertion/removal if one of the Flush sets are in-between.
9. james7132 commented on Mar 23, 2024

   

   james7132

   on Mar 23, 2024

   Member

   More actions

   With #1613 closed via #9822, this is likely resolved as the second system with the after relationship will now observe any commands produced in its dependency. Closing this out.
10. james7132

    closed this as completedon Mar 23, 2024