Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix PR Bevy 0.9 Update #38

Merged
merged 8 commits into from
Dec 9, 2022
Merged

Fix PR Bevy 0.9 Update #38

merged 8 commits into from
Dec 9, 2022

Conversation

Vrixyz
Copy link
Contributor

@Vrixyz Vrixyz commented Dec 2, 2022

My attempt to help with #36.

What I added with commit 63dc9af:

cargo test passing with bevy 0.9.1

  • renamed and split register_rollback_type in register_rollback_component and register_rollback_resource
  • all examples now compile
  • up dependency to bevy 0.9.1 to use resources.iter()
  • remove refect_resource mod

What I tested

  • cargo test.
  • run the examples (2 players + 1 spectator) on mac.

johanhelsing and others added 3 commits November 17, 2022 11:05
- renamed  and split `register_rollback_type` in `register_rollback_component` and `register_rollback_resource`
- cleaned up examples
- split register_component and register_resource
- up dependency to bevy 0.9.1 to use `resources.iter()`
@Vrixyz Vrixyz changed the title Pr/johanhelsing/36 Fix PR #32 Dec 2, 2022
@Vrixyz Vrixyz changed the title Fix PR #32 Fix PR #36 Dec 2, 2022
@Vrixyz Vrixyz changed the title Fix PR #36 Fix PR Bevy 0.9 Update Dec 2, 2022
@gschup
Copy link
Owner

gschup commented Dec 3, 2022

thank you for working on this! The two-player example seems to work, but the spectator example crashes immediately.

cargo run --example box_game_spectator -- --local-port 7002 --num-players 2 --host 127.0.0.1:7000

leads to:

thread 'main' panicked at 'This examples focus on p2p.', examples/box_game/box_game_spectator.rs:90:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\Georg Schuppe\.cargo\registry\src\github.com-1ecc6299db9ec823\bevy_tasks-0.9.1\src\task_pool.rs:273:45

Copy link
Collaborator

@johanhelsing johanhelsing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got to admit I don't understand all of the reflect stuff. But most of this PR looks sensible to me (though I wrote parts of it myself :P)

Added mostly nitpick comments.

As I understand it what were previously part of the GGRS reflect_resource module is now implemented within Bevy itself. I guess that means we should also delete the reflect_resource module?

You mentioned you didn't do much checking... One thing you could do, is check if the frame count resource in the p2p example works as expected?

EDIT: Also, thanks for picking this up! :)

examples/box_game/box_game_p2p.rs Outdated Show resolved Hide resolved
examples/box_game/box_game_spectator.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
SessionType::SyncTestSession
}
}
// TODO: more specific name to avoid conflicts?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should probably think about what to name this... It's public API that will be used, and Inputs quite easily conflicts with something else... and is very similar to Bevy's Input.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I agree, but at t he same time it's namespaced so it's not a very big issue. What do you think of SessionInputs OR SessionFrameInput ? Also this could use some type documentation.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it's easy enough to fix... More thinking about it being easy to read.

We have prefixed GGRSError, GGRSConfig. And some have P2P as prefix (P2PSession).

  1. GGRSInputs
  2. P2PInputs
  3. PlayerInputs (matches PlayerHandle which is used to index this resource)
  4. SessionInputs

Just spitballing. Don't really have a strong opinion. I'm also ok with Inputs. What do you think @gschup ?

definitely agree it could use some documentation!

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

properly naming the Inputs is tough, but I think we should definitely not name it Inputs. I like PlayerInputs quite a bit. I would shy away from naming it GGRSInputs as this struct does not come from the GGRS crate itself.

@@ -55,7 +54,7 @@ impl Rollback {

/// Provides unique ids for your Rollback components.
/// When you add the GGRS Plugin, this should be available as a resource.
#[derive(Default)]
#[derive(Resource, Default)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[derive(Resource, Default)]
#[derive(Resource, Default)]
#[reflect(Resource)]

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this accomplish ? wouldn't Resource already have some reflect capabilities ? or is it to enable bevy_egui reflection ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. maybe it's not needed? I think I maybe just made a brainfart and thought you added derive(Reflect).

I guess the real answer is to just check what works :P

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, sorry about the noise. We could perhaps add reflect in another PR. It might be useful for debugging.

}
}
// TODO: more specific name to avoid conflicts?
#[derive(Resource, Deref, DerefMut)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
#[derive(Resource, Deref, DerefMut)]
#[derive(Resource, Deref, DerefMut)]
#[reflect(Resource)]

src/world_snapshot.rs Outdated Show resolved Hide resolved
Co-authored-by: Johan Klokkhammer Helsing <johanhelsing@gmail.com>
@@ -32,7 +32,7 @@ impl Config for GGRSConfig {
}

#[repr(C)]
#[derive(Copy, Clone, PartialEq, Pod, Zeroable)]
#[derive(Copy, Clone, PartialEq, Eq, Pod, Zeroable)]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eq was not really necessary but it pleases clippy :)

// in order to allow a GGRS `SyncTestSession` to construct a checksum for a world snapshot
#[derive(Default, Reflect, Hash, Component)]
// You can also register resources.
#[derive(Resource, Default, Reflect, Hash)]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if reflect/hash is still needed, I didn't check

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of this is still kind of shallow, but register_rollback_resource seems to need Reflect because it's needed for TypeRegistration::insert...

Or more specifically TypeRegistration::insert needs the TypeData trait to be implemented, which is automatically implemented by deriving Reflect.

I think #[derive(Hash)] and #[reflect(Hash) is not needed. At least the examples, including synctest, run fine without them. Perhaps @gschup would like to confirm?

Copy link
Owner

@gschup gschup Dec 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Deriving and reflecting hash is useful here. It is definitely optional, but encouraged to give SyncTest an actual meaning beyond "checking if this still runs".

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we could be more specific about it in the comment... Something like "By deriving Hash and adding reflect(Hash) the resource can automatically be checked for desyncs during a SyncTestSession"?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is definitely a lot to be improved regarding documentation (see e.g. #35). It might probably even be better to that outside of this PR, in a big documentation commit.

Copy link
Collaborator

@johanhelsing johanhelsing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested resource rollback by adding some logging to the synctest session example's FrameCount. Everything works as expected :D

Also ported my tutorial to this branch, and it works fine (though that doesn't really need resource rollback): https://github.com/johanhelsing/extreme_bevy/tree/bevy-0.9-wip

Feels like this is really close now, just some minor nits and some docs for the new resources would be nice. Great work @Vrixyz !

// in order to allow a GGRS `SyncTestSession` to construct a checksum for a world snapshot
#[derive(Default, Reflect, Hash, Component)]
// You can also register resources.
#[derive(Resource, Default, Reflect, Hash)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding of this is still kind of shallow, but register_rollback_resource seems to need Reflect because it's needed for TypeRegistration::insert...

Or more specifically TypeRegistration::insert needs the TypeData trait to be implemented, which is automatically implemented by deriving Reflect.

I think #[derive(Hash)] and #[reflect(Hash) is not needed. At least the examples, including synctest, run fine without them. Perhaps @gschup would like to confirm?

@@ -55,7 +54,7 @@ impl Rollback {

/// Provides unique ids for your Rollback components.
/// When you add the GGRS Plugin, this should be available as a resource.
#[derive(Default)]
#[derive(Resource, Default)]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, sorry about the noise. We could perhaps add reflect in another PR. It might be useful for debugging.

SessionType::SyncTestSession
}
}
// TODO: more specific name to avoid conflicts?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, it's easy enough to fix... More thinking about it being easy to read.

We have prefixed GGRSError, GGRSConfig. And some have P2P as prefix (P2PSession).

  1. GGRSInputs
  2. P2PInputs
  3. PlayerInputs (matches PlayerHandle which is used to index this resource)
  4. SessionInputs

Just spitballing. Don't really have a strong opinion. I'm also ok with Inputs. What do you think @gschup ?

definitely agree it could use some documentation!

examples/box_game/box_game_spectator.rs Outdated Show resolved Hide resolved
examples/box_game/box_game_spectator.rs Outdated Show resolved Hide resolved
examples/box_game/box_game_p2p.rs Outdated Show resolved Hide resolved
Vrixyz and others added 3 commits December 9, 2022 13:08
Co-authored-by: Johan Klokkhammer Helsing <johanhelsing@gmail.com>
Co-authored-by: Johan Klokkhammer Helsing <johanhelsing@gmail.com>
Co-authored-by: Johan Klokkhammer Helsing <johanhelsing@gmail.com>
@gschup
Copy link
Owner

gschup commented Dec 9, 2022

I don't think we are missing much here. I think it would be nice to rename Inputs to PlayerInputs and then, we can merge :)

@gschup gschup merged commit b730a0b into gschup:main Dec 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants