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

Added new property Viewer for hologram. #99 #100

Merged
merged 9 commits into from
May 25, 2024

Conversation

BigTows
Copy link
Contributor

@BigTows BigTows commented May 23, 2024

Added a new property to the hologram instance.
This property specifies the list of players who are allowed to view this hologram. (Similar to a permission right now.)

If that solution is relevant, I can add command for that field.

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

via #99

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

I think it would be better to implement something into the current system instead of having 2 different sets of uuids, we could probably make the set of shown players into a map of uuids to boolean. The boolean value being a sort of "force view" which ignores permissions.

There is likely a better solution than this too though

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

@OakLoaf For memory obviously, but not for logic. This structure will complicate the management and editing of the code.

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

If you wanna one structure for that. Need create some PlayerContext and control them. For next updates that context can be improved without edit current code.

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

@OakLoaf For memory obviously, but not for logic. This structure will complicate the management and editing of the code.

This current solution is not good for memory and I'm almost certain this isn't the best solution from a logic standpoint either.

Another alternative would be to add a requiresPermission attribute that can be disabled.

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

Another alternative would be to add a requiresPermission attribute that can be disabled.

Yeah it's another solution by different way.

So how can we fix #99?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

Another alternative would be to add a requiresPermission attribute that can be disabled.

Yeah it's another solution by different way.

So how can we fix #99?

I think adding a permission option might be the feasible option

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

Another alternative would be to add a requiresPermission attribute that can be disabled.

Yeah it's another solution by different way.
So how can we fix #99?

I think adding a permission option might be the feasible option

May be convert visibleByDefault to ENUM?
like that:

ALL,
NO_ONE,
PERMISSION_REQUIRED

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

I think if we were to do something like that it'd make more sense to accept a predicate.

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

I think if we were to do something like that it'd make more sense to accept a predicate.

From? I didn't understand you

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

Or do you talk about API? Yeah it's possible, propably good idea.

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

Only issue regarding that would be that there would need to be some way to save that predicate

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

I personally think we should just stick with the requiresPermission option, if there is an issue in the future where another filter type option is needed then we can reconsider implementing a predicate system.

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

@OakLoaf check this out please.

Copy link
Contributor

@OakLoaf OakLoaf left a comment

Choose a reason for hiding this comment

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

With these changes it would probably be a good idea to rename VisibleByDefault to VisibleTo

Comment on lines 28 to 33
@Nullable
public static Visibility byString(String value) {
return Arrays.stream(Visibility.values())
.filter(visibility -> visibility.toString().equalsIgnoreCase(value))
.findFirst().orElse(null);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be removed in favour of Enum#valueOf(String#toUpperCase)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

valueOf is throwable, for safe parsing null needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

There should be no instance where it returns null anyway, if it is null wouldn't there be issues in other places? If so the error would be more helpful.

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 about Optional ? :)

build.gradle.kts Outdated Show resolved Hide resolved
@@ -209,7 +209,8 @@ public boolean execute(@NotNull CommandSender sender, @NotNull String label, @No
yield FancyNpcsPlugin.get().getNpcManager().getAllNpcs().stream().map(npc -> npc.getData().getName());
}
case "block" -> Arrays.stream(Material.values()).filter(Material::isBlock).map(Enum::name);
case "seethrough", "visiblebydefault" -> Stream.of("true", "false");
case "seethrough" -> Stream.of("true", "false");
case "visiblebydefault" -> new VisibleByDefaultCMD().tabcompletion(sender, hologram, args).stream();
Copy link
Contributor

Choose a reason for hiding this comment

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

Creating a new command object for every tabcomplete is probably not a good idea, I would just copy the contents of the method over.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is should be refactored at all.

All CMDs impltement Subcommand with execute and tabcompletion methods.

Comment on lines 236 to 238
final var visibleByDefault = Optional.of(config.getString(
"visible_by_default", DisplayHologramData.DEFAULT_IS_VISIBLE.toString())
).map(Visibility::byString).orElse(DisplayHologramData.DEFAULT_IS_VISIBLE);
Copy link
Contributor

Choose a reason for hiding this comment

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

It would probably be a good idea to add backwards compatibility and support the old boolean option for a while.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You want to check booleans and convert into Predicate?

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

With these changes it would probably be a good idea to rename VisibleByDefault to VisibleTo

On java layer or config too?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

With these changes it would probably be a good idea to rename VisibleByDefault to VisibleTo

On java layer or config too?

I'd say in config too, with backwards compatibility kept if the new one isn't defined

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

With these changes it would probably be a good idea to rename VisibleByDefault to VisibleTo

On java layer or config too?

I'd say in config too, with backwards compatibility kept if the new one isn't defined

I can but you really want store deprecated fields? Are you sure that it won't confuse users?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 23, 2024

I can but you really want store deprecated fields? Are you sure that it won't confuse users?

It would likely get automatically updated on auto-save anyways but I think that loading from the old config would mean that the pr is more likely to be merged sooner

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

I can but you really want store deprecated fields? Are you sure that it won't confuse users?

It would likely get automatically updated on auto-save anyways but I think that loading from the old config would mean that the pr is more likely to be merged sooner

Right now old configuration supported. Boolean converting to Enum on save.

@OliverSchlueter
Copy link
Member

Maybe we should rename the visibleByDefault command with just "visibility"

@BigTows
Copy link
Contributor Author

BigTows commented May 23, 2024

Maybe we should rename the visibleByDefault command with just "visibility"

Added migration for field visible_by_default.

After launch old boolean value will be converted to one of the following modes:
ALL - true
PERMISSION_REQUIRED - false

On save visible_by_default will be deleted (on v1 and v2 too).
And new field visibility will be generated.

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

@OliverSchlueter @OakLoaf Is there something else?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

Not that I can think of, I will review this after work in a few hours

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

@OakLoaf Fixed, check another comments please.

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

All looks good to me

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

Has this been tested in-game to make sure everything works and is backwards compatible?

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

Has this been tested in-game to make sure everything works and is backwards compatible?

I tested that on v2 configuration works fine for me. Do you have an example of old (v1) configurations?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

This should do, just teleport it to your location

  test-text:
    type: TEXT
    location:
      world: world
      x: 45.06436912097689
      y: 87.61627563479522
      z: -90.4272584957459
      yaw: -109.71094
      pitch: 90.0
    visibility_distance: -1
    visible_by_default: true
    scale_x: 1.0
    scale_y: 1.0
    scale_z: 1.0
    shadow_radius: 0.0
    shadow_strength: 1.0
    text:
    - Edit this line with /hologram edit text
    - test with more words

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

Configuration before:

holograms:
  test-text:
    type: TEXT
    location:
      world: world
      x: 45.06436912097689
      y: 87.61627563479522
      z: -90.4272584957459
      yaw: -109.71094
      pitch: 90.0
    visibility_distance: -1
    visible_by_default: true
    scale_x: 1.0
    scale_y: 1.0
    scale_z: 1.0
    shadow_radius: 0.0
    shadow_strength: 1.0
    text:
    - Edit this line with /hologram edit text
    - test with more words

Edit command
image

Move here
2024-05-24_21 32 05

Remove perms
2024-05-24_21 32 41

Configuration after stop the server

version: 2 # DO NOT CHANGE
holograms:
  test-text:
    type: TEXT
    location:
      world: world
      x: 81.10001790115858
      y: 75.0
      z: 71.98312464428668
      yaw: -165.9294
      pitch: 21.240873
    scale_x: 1.0
    scale_y: 1.0
    scale_z: 1.0
    shadow_radius: 0.0
    shadow_strength: 1.0
    visibility_distance: -1
    visibility: ALL
    text:
    - Edit this line with /hologram edit text
    - test with more words
    text_shadow: false
    see_through: false
    text_alignment: center
    update_text_interval: -1

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

Very nicee

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

And one more test :)
2024-05-24_21 37 16

Remove perms
2024-05-24_21 37 38

Configuration after stop the server

version: 2 # DO NOT CHANGE
holograms:
  test-text:
    type: TEXT
    location:
      world: world
      x: 81.10002136230469
      y: 75.0
      z: 71.98312377929688
      yaw: -165.9294
      pitch: 21.240873
    scale_x: 1.0
    scale_y: 1.0
    scale_z: 1.0
    shadow_radius: 0.0
    shadow_strength: 1.0
    visibility_distance: -1
    visibility: PERMISSION_REQUIRED
    text:
    - Edit this line with /hologram edit text
    - test with more words
    text_shadow: false
    see_through: false
    text_alignment: center
    update_text_interval: -1

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

@OakLoaf
We forgot about old API compatibility, maybe add Deprecated method

setVisibleByDefault(boolean){
   setVisiible(boolean?ALL:PERMS_REQUIRED):
}

What do you think?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 24, 2024

Yeahh that's good just pop some spaces in there so it's more readable: value ? ALL : PERMS_REQUIRED

@BigTows
Copy link
Contributor Author

BigTows commented May 24, 2024

Yeahh that's good just pop some spaces in there so it's more readable: value ? ALL : PERMS_REQUIRED

Yeah :) ofc it's was just a draft code.

I did it.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

@OakLoaf While I doing this, I am completely forgot about my case....
MANUAL not working for #99 case :(

Can I add another list of users?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 25, 2024

I really don't think this added commit should be part of this PR. As far as I am aware Issue #99 was resolved as you can now input a custom predicate.

The only issue you'd face is having it save, the only real fix for that would be to make the visibility enum into some sort of registry where people could register new visibility types, it'd just need to be done before FancyHolograms first loads the holograms.

I'm not sure what @OliverSchlueter thinks of this as it does make it more complex but the manual visibility is just not a good solution in my eyes.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

I really don't think this added commit should be part of this PR. As far as I am aware Issue #99 was resolved as you can now input a custom predicate.

It's talk about user frendly API. Do you make them implement the same type of logic every time, in every project, or do you implement once it for them?

@OakLoaf
Copy link
Contributor

OakLoaf commented May 25, 2024

The whole reason we implemented a predicate was so that we wouldn't have to have 2 viewer lists. 2 lists is not necessary.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

The whole reason we implemented a predicate was so that we wouldn't have to have 2 viewer lists. 2 lists is not necessary.

But that second list will be allocated in a lot of projects whos using that plugin. This is balance of the user friendly.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

The whole reason we implemented a predicate was so that we wouldn't have to have 2 viewer lists. 2 lists is not necessary.

But that second list will be allocated in a lot of projects whos using that plugin. This is balance of the user friendly.

And you will repeat repeat that logic every time ;/

@OakLoaf
Copy link
Contributor

OakLoaf commented May 25, 2024

I completely disagree, the entirety of the most recent commit can be replaced with the predicate (player, hologram) -> hologram.isShown(player.getUniqueId())

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

I completely disagree, the entirety of the most recent commit can be replaced with the predicate (player, hologram) -> hologram.isShown(player.getUniqueId())

Nope, show is service field. Show changing every time then plugin want, you can't control that.
For example, swap world, too far and another stuff, plugin remove player ID from that list.

@OakLoaf
Copy link
Contributor

OakLoaf commented May 25, 2024

In that case, an exception of some form could be implemented to ensure that they aren't removed in those instances. Although I imagine adding the visibility distance check into the predicate would probably the better solution here.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

In that case, an exception of some form could be implemented to ensure that they aren't removed in those instances.

Already, we can listen HologramHideEvent but this is not a solution.

Although I imagine adding the visibility distance check into the predicate would probably the better solution here.

This has a bad effect on performance and the difference in configuration

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

My point like a user.

I want to control who can and who can't see the hologram, I don't want to control the plugin processes (hiding due to distance or exiting the server)

@OakLoaf
Copy link
Contributor

OakLoaf commented May 25, 2024

I agree that the issue needs a solution and will happily resolve that myself in a different pr.

I've had a chat with Oliver and if you'd like to revert the most recent commit he'll happily merge this.

@BigTows
Copy link
Contributor Author

BigTows commented May 25, 2024

Okay.

@OliverSchlueter
Copy link
Member

Thank you for your contribution ❤️!

@OliverSchlueter OliverSchlueter merged commit 337a4ad into FancyMcPlugins:main May 25, 2024
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