The Enjin plugin is what connects the donation store. With PermissionManager, the best permission plugin right now imo, the donation store doesn’t work and the server always appears offline. The only thing that has stopped me from releasing my server was your words. Enjin is a service not just a website.
“We are aware the plugin is currently incompatible. I will be working on fixing this soon. Currently just been a little busy.”
Two weeks ago you finally replied to my complaint that I made 22 days ago. I just want to know if you are working on it or not so I know to wait a bit more, or just switch everything over to PEX.
May I ask why you’re choosing to depend on individual plugins, rather than the PermissionService as a whole? It surely makes sense to depend upon the service instead of individual implementations?
Sponge permission service isn’t as reliable nor functional as individual APIs and cannot meet the needs of EMP. In many cases plugins don’t utilize the service api, so we have to rely on individual APIs anyways.
PermissionService absolutely is functional, and can be used to achieve everything you’re currently doing via native APIs. You’re currently supporting only 2 permission plugins, which is very unhelpful for users who aren’t using one of the two. It’s also x times more work for you.
Could you give an example of a plugin that doesn’t utilise the service API? The current two supported plugins in EMP implement it, as well as the other 3 main “popular” ones available for Sponge. (my own implementation included.)
I also wasn’t able to find any source code? You’re not obfuscating your binaries, you have nothing to lose and a lot of gain by publishing the source.
As I’ve said numerous times to other people in this thread, we are not open sourcing the plugin. It’s not my decision and I can’t force the owners of Enjin to open source the project when they have no desire to do so.
Enjin relies on plugin listeners to ensure that we receive prompt updates on changes to users. As I also mentioned, not all permission plugins use the permission service nor can I expect them to update to it. Supporting all plugins isn’t as simple as using the sponge api, especially when the entire permissions system is undocumented.
“Enjin relies on plugin listeners to ensure that we receive prompt updates on changes to users.”
That’s just a complete lie. Both PermissionsEx & PermissionManager expose no events for you to listen to, so no, you don’t rely on plugin listeners. They do not exist.
That’s then not your problem. If a “permissions” plugin doesn’t implement the service, it’s not a permissions plugin. It is a Sponge requirement.
Not simple? Hey, let me do the work for you!
I wrote this complete implementation in ~5 minutes.
Ah, my bad. I was searching for events - for which there are none. Neither plugin exposes any events available in Sponge. I apologise.
My copy was based off PermissionManager. You don’t seem to be hooking with it anyways - or is that why your implementation is broken?
Either way, there’s actually no real need for the events. You can just periodically check for changes against your internal systems. Pretty much all implementations of PermissionService are thread-safe (this might even become a requirement at some point), so you can even check for those changes async, every minute or so.
Your point about simplicity still makes absolutely no sense, and the code I provided will still do exactly the same as the c.e.s.permissions.handlers.PermissionManagerHander class. You then have no specific dependencies, other than any permissions plugin.
I did have a hook for an older version of PermissionsManager, not sure if it was included in the last update or not, but I had implemented support for a previous version. Right now I’m just upgrading to the latest versions to get support implemented.
Ultimately I’d rather have the listeners than not. Checking ranks and sending them periodically just adds overhead to the data the enjin api has to process.
I’ll consider switching down the road, but as of right now the authors of both PEX and PermissionsManager haven’t advocated for using sponge api and have directed me to rely on internals of the individual plugins.
The author of PEX hasn’t advocated use of his own API? That’s certainly, uhm, surprising. PEX’s internals are package-private, that’s a greater indication than any that you shouldn’t be using them directly.
As I said, there’s not really any overhead. You can check asynchronously.
The users of your plugin seem annoyed at the lack of support for a wide range of permission plugins - using the abstraction interfaces provided by Sponge is surely an obvious way to fix that? I’ve already shown you it’s possible. There’s really no reason not to use it.
Perhaps you misunderstood - the author of PEX wrote the Sponge permissions API. If anyone knows how to implement it properly, it’s him. If you compare the two, the internal design of PEX very closely follows PermissionService. (I guess they were probably written at the same time )
And again, to quote myself:
You sadly ignored the rest of my message. I guess I’ll just give up now? Only trying to help, as you can probably tell; I’m not making these suggestions to make your plugin worse. If you don’t want to listen to me, listen to the people paying (even if it is indirectly) for your services. By the looks of some of the comments above, some of them aren’t too happy with the lack of support! Telling your Sponge users to “just use the Spigot plugin” is totally the wrong attitude, and very poorly reflects on Enjin.
Anyway, I’ll leave you to it. I hope you do decide to take note of my suggestion.
I was confused at first at what you meant, as I havn’t seen it communicated.
Wasn’t an attack, it was a genuine question.
Yes you can expect them to update to it, a permissions plugin that isn’t using the Permissions Service isn’t a permissions plugin in Sponge, all plugins that use permissions on Sponge are indirectly using the Permissions Service.
I didn’t initially understand why you needed listeners / callbacks, after thinking about it some more, I assume it’s because you are syncing group memberships back to the enjin communities / have permissions on the site that tie directly into the servers permission system?
If so we can create some events for permission changes / inheritance changes in the API so that you don’t need to tie into specific providers any more.
SpongeAPI has breaking changes, and the team is committed to providing API for what people need. If you need events / listeners create a ticket against the API detailing the usecase and we can consider adding support.
Went ahead and created an issue on Github regarding the event/notifications. Hopefully they’ll take it into consideration and implement support for permission events so that we can get realtime notifications of changes.
As per Enjin’s own advertisement, users of Enjin Hosting are also paying for ‘Deep-Game Integration’ - a fancy terminology to explain that we are paying for such things as: -MultiServer Support -Fast Server Commands -Rank Integration -Donation Store
All of this achievable as “available and powered by the Enjin Minecraft Plugin.” Now, whilst I understand that it is challenging due to the large amount of users needing this plugin (and your lack of ressources), I think that telling users that it is best to head to Spigot (when all platforms are currently supported) is a bit non-sensical.
Regardless, I have been with Enjin for the last 2 years, and I will continue to be as long as they can continue to upkeep what I am paying for. I understand my fellow owners’ frustrations, but I think it is best to find a middle-ground and commit to testing and helping in whatever way possible, by providing bug reports and continuing to purchase our monthly terms with Enjin itself, as I have personally done at the time of posting this.
)
If you don’t want to listen to me, listen to the people paying (even if it is indirectly) for your services. By the looks of some of the comments above, some of them aren’t too happy with the lack of support! Telling your Sponge users to “just use the Spigot plugin” is totally the wrong attitude, and very poorly reflects on Enjin.