Placeholders

[Phoenix616]

Add a provider abstractions for the different placeholder systems.

---

IssueHunt Summary

Backers (Total: $20.00)

• phoenix616 ($20.00)

Submitted pull Requests

• #29 placeholder abstraction

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[issuehunt-oss]

@phoenix616 has funded $20.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[IllusionTheDev]

The main issue I'm seeing here is the required underscore with PlaceholderAPI but not with MVDW, as well as the PAPI and MVDW formats being different (%name_value% vs {name}). For more specific placeholders ("%island_top_1%") it'd be great to build some kind of context tree. Not sure how fancy I'd like this to be

[Phoenix616]

I don't think the format difference would be a big issue. The basis is the same after all: A key which gets mapped to a value. How that key is replaced and represented internally in the plugins providing the service interface shouldn't really matter for the interface itself. Imo. an interface providing simple key -> value mapping as well as utility methods to replace in strings should be enough. (Although the more I think about text-related stuff I realise that with components being a thing this might get a lot more complicated as we would ideally want component support in the api but not all platforms or plugins use the same ones (Adventure vs. Bungee-Chat vs. other libraries/NMS access). I guess for now a simple string placeholder querying and replacement would be enough and components support could be part of #8, maybe once the ecosystem finally settles on one implementation...)