Bevy: Spawning an Entity affecting other Entity behavior

[ncallaway]

This is happening for me on bevy 0.1.3. The behavior appears to be introduced by commit 4eb437. The immediately prior commit (2dadc8) produces the behavior I expect.

Calling commands.spawn is causing one of my entities to disappear, and causes another entity to take on the Transform of the entity that disappeared. I suspect that some kind of entity ID or entity index is becoming incorrect.

Here is a sample of correct behavior with my code running with bevy#2dadc8:

He is a sample of the incorrect behavior with bevy#4eb437:

Notice on the client that the cube disappears and that the plane appears to be getting the Transform that should be being applied to the cube.

Finally, on 4eb437 if I comment out spawning the messages that display on the sidebar in the client, the correct behavior is restored (except the client no longer has messages in the sidebar list)

// commands.spawn((Message::new(
//   &server_message.message,
//  &server_message.from,
//  server_message.ordinal,
// ),));

Reproduction

This can be reliably reproduced by:

• checking out ncallaway/bevy_prototype_networking_laminar commit 90cebc (currently master)
• Update cargo.toml to point bevy at the last known working commit:

bevy = { git = "https://github.com/bevyengine/bevy.git", rev="2dadc86fb003f64db5e6870a327fd0ed969881e5" }

• Run the server and in a separate shell the client cargo run --release --example testbed -- -s 127.0.0.1:12530, cargo run --example testbed -- -c 127.0.0.1:12541 127.0.0.1:12540 foo
  
  
  
  • Observe things working as expected (the messages appear in the sidebar, the server can move the cube with WASD and the cube position is replicated to the client)
  
  
• Update cargo.toml to point bevy at the next commit:

bevy = { git = "https://github.com/bevyengine/bevy.git", rev="4eb437ab2e3c2b69ade01f3661fe128fe8027daa" }

• Run the server and client again
  
  
  
  • Observe the issue described in the ticket: on the client the cube disappears and the plane takes the translation that should be applied to the cube.
  
  
• Comment out the client's messages spawn in examples/testbed/net/mod.rs lines 127-131
  
  
  
  • Observe that the cube now behaves correctly on the client.
  
  

[ncallaway]

Suggested Labels: bug | ecs

[sanisoclem]

not sure if this is related, but I experienced a similar thing where the material would "jump" between entities even if I don't have any systems that change the material, and each entity has their own material. Not working on materials atm so I haven't had the chance to investigate it yet.

This started happening after updating to 0ae74a4a4dd3acfeebb2d6e6040c25fad70a2c9f, I was using 2dadc86fb003f64db5e6870a327fd0ed969881e5 before this.

[cart]

I have a feeling that this is related to #299, which i am investigating now. Probably caused by #216

[ncallaway]

@cart Yea, that looks similar to the commit that introduced the issue for me (4eb437).

@sanisoclem Any chance you could try the two commits I identified as bad and good and see if your issue was introduced in the same commit?

[jngbsn]

Here's a minimal repro example, with some of my findings in case they help. https://github.com/jngbsn/bevy_entity_bug

[sanisoclem]

@sanisoclem Any chance you could try the two commits I identified as bad and good and see if your issue was introduced in the same commit?

yep, confirming that the issue only happen when using 4eb437ab2e3c2b69ade01f3661fe128fe8027daa and up.

[cart]

Cool cool. Thanks y'all! I'm working on a fix now.

[ncallaway]

This issue no longer repros for me with master after the fix was merged!

@jngbsn @sanisoclem you might double check your test cases with master, but I suspect this is fixed.

[sanisoclem]

fixed for me as well, despawn works as expected too. Cheers!

[cart]

Thanks for checking!