Shading nuvotifier wasn’t intentional. Our build system currently doesn’t shade it in, so there is a good chance that the team member who handles the version uploads uploaded the wrong jar as we did have some issues where locally stored jars were shading when they shouldn’t have. Regardless, I’ll raise the issue to the team and have them replace the jar with the correct one.

As a temporary solution, what people can do is delete the vexsoftware folder from the jar and that should resolve the issue.

Recently after updating to Sponge 2113 from 2053 I’ve noticed Enjin goes down frequently for a few seconds at a time (shows server as down), when I refresh the page it is back to normal. It seems it does this a few times per hour.
It causes a issue with votes, players don’t get rewards or counts towards their monthly total if they vote when it is down for that brief moment

So after doing a little research into how the target selectors work I think it’s reasonable to add such a feature. While this won’t be implemented immediately, it’ll be one of the features I’ll put on my priority to do list after I complete the major refactor to the plugin I’m currently working on.

How is this going?

Right now on the latest its just doing this with “@p”.
‘[20:46:58] Player is not linked to any valid user.’

It happens on 2053 but nowhere near as often. It’s one of the main reasons I’m still on 2053. We are a large server and get a lot of votes, thus a lot of work for our admins to manually issue rewards out

Does the server crash at all? I came across a crash report that would suggest our JSON RPC 2 could potentially be affecting the plugin’s performance. It may also be the case that it’s causing issues for servers that aren’t experiencing crashes. The users reporting the crashes were using Spigot on the other hand, so it may be that Sponge isn’t crashing while Spigot can.

Hm, it may be possible that it’s a related issue but different results on different platforms. Not sure if our new update will resolve your issue, but it does include some optimizations for data sending from the server. Let me know if you still experience issues with v3.1.0

Chances are the commit resolving the issue was made after the commit that I based the 3.x branch off of. Since the major refactor is going to be 4.x I thought it best to make a branch specifically for 3.x in which I can work off of for fixes in the meantime. I’m currently looking to see what changes I made to fix the build cycle. Once I’ve resolved it on the 3.x branch I’ll ask for management to replace the 3.1.0 jar with a corrected build.