Created PlaceholderAPI soft dependency #311
Conversation
|
Thanks for the PR. I think my primary concerns with the changes are the following:
I think it would be cleaner to hook in PlaceholderAPI as public class PlaceholderAPIDynamicReplacer implements DynamicReplacer {
@Override
public boolean find(String s) {
return PlaceholderAPI.containsBracketPlaceholders(s);
}
@Override
public String replace(StatusResponse response, String s) {
PlayerIdentity identity = response.getRequest().getIdentity();
if (identity != null) {
// Note: I'm not sure if getOfflinePlayer is really safe here.
// Server status pings are handled asynchronously (not on main thread)
return PlaceholderAPI.setBracketPlaceholders(Bukkit.getOfflinePlayer(identity.getUuid()), s);
} else {
return replace(response.getCore(), s);
}
}
@Override
public String replace(ServerListPlusCore core, String s) {
return PlaceholderAPI.setBracketPlaceholders((OfflinePlayer) null, s);
}
}This would be registered like Main problem perhaps is that I'm not entirely sure if |
|
From a user perspective, the PAPI placeholder standard is SLP supports very few placeholders natively -- 16 currently. I would hope that conflicts with PAPI placeholders could be managed, and should have the same values in any event. As a lesser alternative, you could add a few -- |
|
I think the primary advantage of PlaceholderAPI is that it allows ServerListPlus to integrate with other plugins that hook into PlaceholderAPI. I do not have the time to add every little placeholder someone requests. But from a support perspective I would rather like to have a clear way to differentiate SLP placeholders and PAPI placeholders. Originally I was thinking about wrapping the PlaceholderAPI placeholders (e.g. |
Agreed.
I would prefer you didn't, but it's your plugin. |
|
Heyo!
When the UUID is available would the easiest thing to do be to use
Looking at the Placeholder page on the wiki do I see no placeholder conflicting with any of the known placeholders in PlaceholderAPI, so I doubt there is any conflicts to happen.
@SlimeDog Technically speaking is the pattern more Also shouldn't it be that big of an issue if you translate the internal placeholders first, before passing them on to PlaceholderAPI to process. |
To my knowledge was it added to provide support with MVdW Placeholders in some way (or to at least allow placeholders in placeholders) |
|
We now use a different, dev-responsive, server-list plugin which fully supports PAPI. |
By dev-responsive you mean a not semi-dead one? |
|
That is what I meant. Fortunately, we found a fully functional alternative. |
To be honest, I myself also use an alternative now that provides HEX colors. |
|
It's the nature of MC plugins:
There were 98,900 downloads of SLP 3.4.8, but alternatives have passed it by, functionally. Sad, but expected. |
Yes.
The problem is that you cannot implement the This is kind of unfortunate, because the the placeholder implementation in SLP is optimized to find the used placeholder during configuration load. Later, when all the requests are handled, only the used placeholders are actually processed. If you cannot implement
If you have found a true replacement of ServerListPlus: open-source, a similarly clean and flexible configuration format, feel free to post a link here. There is no need to duplicate effort if someone else is already maintaining a truly better replacement. As for all your concerns about the semi-abandonment of ServerListPlus: I am sorry that it came to this. I have been collecting ideas and concepts for ServerListPlus 4.0 for a long time, and had a clear integration plan for most of the open feature requests in the new architecture. (Note for example the I started work on SLP 4.0 twice but I never came very far because of an overall change of interests. I haven't played Minecraft for years and therefore have no personal use for any Minecraft-related projects anymore. It's unfortunate, but I guess this applies to a lot of people who made Minecraft-related projects. I do however care enough about my previous projects to somehow try to keep them somewhat alive (without spending much time on them). This is the reason why SLP (and all my other MC-related projects) are in this weird semi-abandoned state. For some of them, the situation is better because they were taken over by other people (and I just provide suggestions/review occasionally). Unfortunately SLP is not one of them. |
Even if this may sound harsh, but perhaps it would be best to move on. |
I assume if someone was willing to take over development of the plugin, they would let me know. (And if someone is reading this and is interested in doing this, please DO let me know!)
I appreciate your comment but it's not entirely clear to me if you're concerned about the (maybe not so well-spent) time I still invest in keeping SLP semi-alive, or concerned about all the people who still consider using this plugin because it seems somewhat alive. I limit my involvement to occasionally helping people who end up here on the GitHub project asking for help. If there are really better replacements I would expect that people don't show up here anymore, and that would therefore result in SLP being put "to rest". |
The problem is, that people will be unsure about using other plugins, especially if they don't know it. Keeping SLP alive stops people from looking for alternatives and for those alternatives getting exposure. |
|
I don't generally (publicly) recommend alternatives until they have some history. Over six years of MC experience tells me that most plugins end up in the dustbin, when the original developer moves on with real life. Only occasionally does another developer pick up a project and truly run with it. It is the nature of the beast. The vast majority of MC plugins are simple projects that help someone learn to code in Java. But there is no framework or forum for people to learn good software development skills, with the result that most plugins are very poorly written (nevertheless self-advertised as "the best ever") and full of bugs. Rather than develop a new idea, they simply write yet-another plugin that does the same thing as scores of others (search SpigotMC for "motd" for an example of this phenomenon). That is also the nature of the beast. |
|
I have no issue with SLP remaining on life support. It works for a lot of people, obviously. It just doesn't work for me, and others who want full PAPI support. It's open source. Anyone is free to take it on. |
So you're essentially suggesting that I make the status of the plugin more clear in the README etc? I think that's a fair point. I'm also not opposed to actually link to some good alternatives, provided that they fulfill certain criteria that I found important for ServerListPlus (open-source, reasonable code quality). |
|
I quickly list two alternatives I know:
This list is of course not official and the positives and negatives are only from my personal perspective. |
PAPI support? That was the (initial) focus of this issue. |
Yeah. Sadly don't know if any of them does provide this... I mean the second one at least mentions that you can add your own through the API (I feel like this plugin tries to be like SLP...) |
|
:( OK. We are currently using ServerListMOTD which is a resurrection/continuation of this one. It has 300+ downloads (the original had 1800). It's only 6 months old, but the developer seems committed. He supports only two plugins, both of which he resurrected. You can read about him at the bottom of the Overview page. |
|
Done. |
|
❤️ |
|
The discussion here somehow motivated me to do something about the open PRs at least. I tried the suggestion from my comment and it seems to work fine: #311 (comment). I realize the bracket syntax is not ideal, but it's the easiest way to integrate PlaceholderAPI with SLP right now and I'd argue it's better than nothing. |
|
Or you could have just merged the PR, which rendered all placeholders equal in terms of syntax, instead of inventing additional syntax. :( |
|
I appreciate that your developer made this PR @SlimeDog. But IMO the PR has several problems that my implementation does not have, as documented in the comments. Even if there are no actual conflicts with existing placeholders, the following problems do exist in this PR:
The last one may not seem very significant from a user perspective, but it's a design decision that I described in #311 (comment). The solution I suggested integrates directly with SLP's placeholder system, which is the least intrusive way to support PlaceholderAPI for SLP, even if that means using a slightly different syntax. |
|
I just wanted to jump in here and say thank you for keeping this on life
support even after you’ve left the game. It’s much appreciated. I’ve been
using the plugin for years.
…On Wed, Apr 28, 2021 at 4:39 PM SlimeDog ***@***.***> wrote:
Or you could have just merged the PR, which rendered all placeholders
equal in terms of syntax, instead of inventing additional syntax. :(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#311 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEATM2GYMQMC77QRK3DX54TTLB6ARANCNFSM4SRBFTWQ>
.
|
|
All good. Agree with the thanks for keeping it alive. |
Allows parsing PAPI placeholders in MOTD and in player hover message
Should address #146