[BUG] VelocityCTD + LimboAPI

[Sc1Ter]

Latest versions of VelocityCTD + LimboAPI

[limboapi]: Exception while registering LimboAPI login handlers for [connected player] --- (/).
java.util.concurrent.CompletionException: java.lang.ExceptionInInitializerError
at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:315)
at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:320)
at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:722)
at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:148)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:141)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:535)
at io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:201)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1195)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at com.velocitypowered.proxy.util.concurrent.VelocityNettyThreadFactory$1.run(VelocityNettyThreadFactory.java:69)
Caused by: java.lang.ExceptionInInitializerError
at net.elytrium.limboapi.injection.login.LoginListener.lambda$fireRegisterEvent$0(LoginListener.java:278)
at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:718)
... 8 more
Caused by: net.elytrium.commons.utils.reflection.ReflectionException: An unexpected internal error was caught during the reflection operations.
at net.elytrium.limboapi.injection.login.LoginTasksQueue.(LoginTasksQueue.java:320)
... 10 more
Caused by: java.lang.NoSuchFieldException: DEFAULT_PERMISSIONS
at java.base/java.lang.Class.getDeclaredField(Class.java:2784)
at net.elytrium.limboapi.injection.login.LoginTasksQueue.(LoginTasksQueue.java:295)
... 10 more

[kripypastishka]

[mdxd44]

either use the real Velocity, or go bother the developer of that mess

[Sc1Ter]

either use the real Velocity, or go bother the developer of that mess

So you can't do anything?

[WouterGritter]

For context:

• Fix LimboAPI login injection on Velocity-CTD  #236 (comment)
• Fix LimboAPI login injection on Velocity-CTD  #236 (comment)

We may end up maintaining a fork of LimboAPI that keeps up with Velocity-CTD if the guys over here aren't willing to communicate reasonably.

Who knows, maybe we'll even end up supporting LimboAPI's API natively in Velocity-CTD with our own backend implementation, so you don't need the plugin. Luckily their license allows it.

[hevav]

either use the real Velocity, or go bother the developer of that mess

So you can't do anything?

even if we make the necessary changes, the plugin may stop working again in the future, while the developers of unofficial Velocity forks will make critical changes that can be easily avoided (even according to their comments).

[hevav]

Who knows, maybe we'll even end up supporting LimboAPI's API natively in Velocity-CTD with our own backend implementation, so you don't need the plugin.

it sounds fun that LimboAPI was originally built into our Velocity fork, then separated into plugin for compatibility purposes, and it would being build into some fork again.

it shouldn't be that hard to reimplement LimboAPI in the fork yourself, so I wish the fork developers happy hacking and good luck

[WouterGritter]

either use the real Velocity, or go bother the developer of that mess

So you can't do anything?

even if we make the necessary changes, the plugin may stop working again in the future, while the developers of unofficial Velocity forks will make critical changes that can be easily avoided (even according to their comments).

That's fair. If that's the stance LimboAPI is going to make:

not chasing every Velocity-CTD internal change that doesn't touch the public API

then there's no need to rude about it. Of course when we (Velocity-CTD) are changing the internal implementation there's a chance plugins making heavy use of reflection will break. That's by design. It's an anti-pattern to rely on reflection, and every plugin developer should know that and accept the risks. If that means breaking compatibility with forks, and making their customers unhappy, that's their own decision to make. But as per my previous comments, I get why a plugin like this would need to use reflection (again - that's why this is a great thing to ship in Velocity-CTD itself).

I personally would like to see us working together on this. We are getting lots of tickets complaining about LimboAPI being broken with CTD, and us maintaining a fork of LimboAPI would probably not be the thing you'd like us to do, as it only splits the userbase in two.

[hevav]

I personally would like to see us working together on this. We are getting lots of tickets complaining about LimboAPI being broken with CTD, and us maintaining a fork of LimboAPI would probably not be the thing you'd like us to do, as it only splits the userbase in two.

Feel free to maintain the LimboAPI "optimized for Velocity-CTD" fork

[kripypastishka]

Will he be working on VeloFlame?

[WouterGritter]

This specific compatibility issue should be fixed on CTD's side by GemstoneGG/Velocity-CTD@cee1dcb

[hevav]

This specific compatibility issue should be fixed on CTD's side by GemstoneGG/Velocity-CTD@cee1dcb

offtop: а слов то было