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

NPC #23

Open
Phoenix616 opened this issue Mar 10, 2023 · 5 comments · May be fixed by #26
Open

NPC #23

Phoenix616 opened this issue Mar 10, 2023 · 5 comments · May be fixed by #26
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt enhancement New feature or request service A new service which Tresor should add
Milestone

Comments

@Phoenix616
Copy link
Member

Phoenix616 commented Mar 10, 2023

Issuehunt badges

Design a service provider for working with NPCs.

Questionable how configurable this should be. But at least creating simple ones and querying for existence might be a good start.

Plugins that will be supported right out of the gate:

  • Citizens
  • find more?

IssueHunt Summary

Backers (Total: $20.00)

Submitted pull Requests


Become a backer now!

Or submit a pull request to get the deposits!

Tips

@Phoenix616 Phoenix616 added the enhancement New feature or request label Mar 10, 2023
@github-project-automation github-project-automation bot moved this to Accepted service in Tresor Service Planning Mar 10, 2023
@Phoenix616 Phoenix616 added this to the Full Release milestone Mar 10, 2023
Copy link

issuehunt-oss bot commented Apr 19, 2024

@phoenix616 has funded $20.00 to this issue.


@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label Apr 19, 2024
@IllusionTheDev
Copy link
Contributor

Different NPC systems have different ways of approaching NPC IDs. I'm questioning if I should make a generic NPCIdentifier interface to account for that (Citizens uses numerical IDs, other plugins may use UUIDs or internal names)

@Phoenix616
Copy link
Member Author

Phoenix616 commented Apr 22, 2024

Yeah that's indeed an interesting question. This might actually be the case for more services than just this now that I think about it (e.g. someone might not use a string for the holograms either) so maybe having a general Identifier interface in the Tresor API that can be used by any service which might handle IDs could be best (one could even argue that a player using a UUID is kinda arbitrary and should use such an interface...)

If you want to take a stab at designing something like that feel free but I will too have to think about the best approach for that as it needs to be user-friendly enough to be easily usable. (E.g. you wouldn't want to have to always wrap your player-UUID to use an Economy service but this might not be that big of an issue in the case of NPCs or even holograms where you already have the Identifier from creating it. But again, some people might want to store them in a config/database, so any Identifier implementation would also need to be able to properly be converted into a storeable format...)

So yeah, thanks for bringing this up. If you have a good idea for addressing these points then feel free but it's definitely not part of this issue and if you want to do NPCs too then feel free to just implement it in a way that you think should work with most (e.g. Citizens can get NPCs via UUID too, maybe just using that for now would be the best approach)

@IllusionTheDev
Copy link
Contributor

Another issue I can think of is persistence. Certain APIs create persistent / non-persistent NPCs/Holograms etc. How should we tackle this? Citizens has its NPCRegistry system that allows us to choose, I'm unsure about other plugins like ZNPCs

@Phoenix616
Copy link
Member Author

Sounds like something that could be put behind a Feature enum (like one for persistent, one for temporary) and an option on NPC creation to store it or not. (And a create method without a parameter to be used with all plugins which should probably default to storing for those that can do both as I would assume that's what one usually expect it to do)

@IllusionTheDev IllusionTheDev linked a pull request Apr 23, 2024 that will close this issue
@Phoenix616 Phoenix616 moved this from Accepted service to In development in Tresor Service Planning Apr 28, 2024
@Phoenix616 Phoenix616 added the service A new service which Tresor should add label Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💵 Funded on Issuehunt This issue has been funded on Issuehunt enhancement New feature or request service A new service which Tresor should add
Projects
Status: In development
Development

Successfully merging a pull request may close this issue.

2 participants