-
Notifications
You must be signed in to change notification settings - Fork 514
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
base: master
Are you sure you want to change the base?
Conversation
|
newProperty("settings.restrictions.spectateStandLogin.headYaw", 0.0f); | ||
|
||
@Comment("Head Pitch position for 'spectateStandLogin'.") | ||
public static final Property<Double> HEAD_PITCH = |
There was a problem hiding this comment.
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)
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The field on the class is no longer needed (an IDE shows an unused warning)
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 useinjector#getIfAvailable
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed unnecessary comment.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
What do you mean by this? (Never used tests)
Implemented it. |
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.
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 |
There was a problem hiding this 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
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 I understood you correctly I've added what you've meant. |
Re-opened #2552 cause I don't have access to modify any of that.