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

SpectateLogin implementation #2745

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

Bagietas
Copy link

Re-opened #2552 cause I don't have access to modify any of that.

@ljacqu
Copy link
Member

ljacqu commented Sep 3, 2023

  • Unit tests are missing
  • If the server crashes and players are not authenticated, players will be stuck in spectator gamemode (see comment thread in the original PR referencing "limbo player")

newProperty("settings.restrictions.spectateStandLogin.headYaw", 0.0f);

@Comment("Head Pitch position for 'spectateStandLogin'.")
public static final Property<Double> HEAD_PITCH =
Copy link
Member

@ljacqu ljacqu Sep 3, 2023

Choose a reason for hiding this comment

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

I think this should work with the version of ConfigMe that AuthMe is using (please ignore this suggestion if it doesn't)

Suggested change
public static final Property<Double> HEAD_PITCH =
public static final Property<Float> HEAD_PITCH =

Also the naming is a bit weird, I don't know that RestrictionSettings#HEAD_PITCH refers to the spectate stand feature, and as a user I'm not sure I'll understand what this setting represents. Is it possible to elaborate in the comment? I would make a suggestion but I'm actually not really sure what the yaw & pitch settings are for

Copy link
Author

Choose a reason for hiding this comment

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

I don't know If i understood you correctly, but HEAD_PITCH and HEAD_YAW are under spectateStandLogin so It's obvious what are these settings for.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for changing the comment. I also meant the field name, RestrictionSettings.HEAD_PITCH in the code sounds very generic. Could we maybe name it SPECTATE_HEAD_PITCH, or maybe you have a better idea?

Copy link
Author

Choose a reason for hiding this comment

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

Renamed.

@@ -316,6 +319,8 @@ public void onDisable() {
// Wait for tasks and close data source
new TaskCloser(this, database).run();

spectateLoginService.removeArmorstands();
Copy link
Member

@ljacqu ljacqu Sep 3, 2023

Choose a reason for hiding this comment

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

Potential null pointer if the plugin crashes before this service is set on L251

The proper way to do this is to not have the field, but to use another method from the injector (not sure what methods exist by heart, but if there's something that returns a singleton if it's been registered, that would be it, otherwise maybe injector.createIfHasDependencies though it's not ideal to still potentially create it at this point)

Copy link
Author

Choose a reason for hiding this comment

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

Fixed it.

Copy link
Member

Choose a reason for hiding this comment

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

  1. The field on the class is no longer needed (an IDE shows an unused warning)
  2. injector.createIfHasDependencies(SpectateLoginService.class) might return null, so the issue of a potential null pointer still remains. And I think it would be better to use injector#getIfAvailable

Copy link
Author

Choose a reason for hiding this comment

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

Done.

|| spectateLoginService.hasStand(event.getPlayer())) {
// If a player is dead, no stand will be created for him
// therefore we can be sure that there will not be two stands
bukkitService.runTaskLater(() -> spectateLoginService.createStand(event.getPlayer()), 1L);
Copy link
Member

@ljacqu ljacqu Sep 3, 2023

Choose a reason for hiding this comment

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

I can't confirm the comment about stands not being created if a player is dead but maybe I'm missing the relevant point, but interestingly the logic here specifies a stand should be created if the setting is enabled, or if the player has a stand? I don't think that makes much sense.

Copy link
Author

Choose a reason for hiding this comment

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

Removed unnecessary comment.

Copy link
Member

Choose a reason for hiding this comment

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

Now an armor stand is created for a player every time he respawns, regardless of whether an armor stand already exists or not

Copy link
Author

Choose a reason for hiding this comment

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

Done.

@Bagietas
Copy link
Author

Bagietas commented Sep 4, 2023

  • Unit tests are missing

What do you mean by this? (Never used tests)

  • If the server crashes and players are not authenticated, players will be stuck in spectator gamemode (see comment thread in the original PR referencing "limbo player")

Implemented it.

@Bagietas Bagietas requested a review from ljacqu September 4, 2023 13:01
@ljacqu
Copy link
Member

ljacqu commented Sep 4, 2023

Unit tests are missing

What do you mean by this? (Never used tests)

Every class has a "Test" class associated to it, e.g. BukkitService has BukkitServiceTest. These are unit tests, which ensure that refactorings and similar don't break things in unexpected ways. Searching for JUnit should also provide additional information.

If the server crashes and players are not authenticated, players will be stuck in spectator gamemode (see comment thread in the original PR referencing "limbo player")

Implemented it.

I think it would be important to test different scenarios, like if existing limbo player data exists before these changes, there might be limbo player data already stored on disk. Since no "gamemode" exists, it's null, which I think will cause further issues down the line when we try to set the gamemode to null on a player. I don't fully remember the whole lifecycle of the LimboPlayer (and I'm going abroad soon, so a little pressed for time this week) but I think this would be nice to really test in detail to make sure this won't break players' data.
It might make sense to only touch the gamemode if the player is currently in spectator mode, the spectating setting is enabled, and we have another gamemode on the limbo player. Or maybe to have a config like we have for many of the other limbo stuff to allow it to be enabled and disabled. Someone else from the AuthMe team might have some good inputs here.

Copy link
Member

@ljacqu ljacqu left a comment

Choose a reason for hiding this comment

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

Your code doesn't compile btw

@Bagietas
Copy link
Author

Bagietas commented Sep 9, 2023

Unit tests are missing

What do you mean by this? (Never used tests)

Every class has a "Test" class associated to it, e.g. BukkitService has BukkitServiceTest. These are unit tests, which ensure that refactorings and similar don't break things in unexpected ways. Searching for JUnit should also provide additional information.

It's my first time I do something like tests. That's my try to implement it but I don't know if it's correct.

If the server crashes and players are not authenticated, players will be stuck in spectator gamemode (see comment thread in the original PR referencing "limbo player")

Implemented it.

I think it would be important to test different scenarios, like if existing limbo player data exists before these changes, there might be limbo player data already stored on disk. Since no "gamemode" exists, it's null, which I think will cause further issues down the line when we try to set the gamemode to null on a player. I don't fully remember the whole lifecycle of the LimboPlayer (and I'm going abroad soon, so a little pressed for time this week) but I think this would be nice to really test in detail to make sure this won't break players' data. It might make sense to only touch the gamemode if the player is currently in spectator mode, the spectating setting is enabled, and we have another gamemode on the limbo player. Or maybe to have a config like we have for many of the other limbo stuff to allow it to be enabled and disabled. Someone else from the AuthMe team might have some good inputs here.

If I understood you correctly I've added what you've meant.

@Bagietas Bagietas requested a review from ljacqu September 9, 2023 07:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants