#waterfall-dev
1 messages · Page 20 of 1
So there is no way to detect this solely using a plugin?
did you try the connection request thing?
I am not sure which thingy you mean
Yes I have found it, there is a callback but I am not sure how do I use it to connect a player to a server. I normally use ProxiesPlayer.connect
use the builder to create the connection request
I cannot set target on it
There is only getTarget method
P. sure it was in the method to create the builder

oh, didn't notice that xd
Its usually named like setTarget
How do I pass the ServerConnectRequest to the player now?
oh, just player.connect(ServerConnectRequest )
This callback does not detect when the socket is closed before logged in, result is "SUCCESS" right after the socket is opened, does not care about that the socket was closed right after that before responding with minecraft login packet.
oh, ouch then
idk, bungee never did a good job of exposing that mess
(and, I got tired of tweaking smaller things in the API and breaking shit)
To fix that, I'd need to add another concurrent connection request system alongside the existing one
there is no option for windows?
How do I edit this thing, everything i do is always restored back to original when i build it
build with maven directly
otherwise, make sure to rebuild patches
heavily suggest reading the contrib guide
(The contrib guide from like paper 1.16 might be more fleshed out and useable)
Anything I do in the Waterfall-Proxy folder is totally ignored
git says its already up to date
you need to commit in -Proxy
running the wrong jar
which is the correct one? this one was in ...-proxy/proxy/target
bootstrap
If I add new event, will the PR be accepted? or it this only for small patches
btw modified jar working good, thanks
I mean, "yes"
but, I got a hugeass backlog and bungee is generally dead to me right now
When you build with bash first time, (applying patches) Next time if you dont want to lose your progress just do mvn clean install or smth like that
I'm a little confused regarding the ProxyPingEvent's PendingConnection and ServerPing classes.
From my personal experience does ServerPing$Protocol#getProtocol() return the Protocol version of the pinging client, right?
If so, I assume getName() gives the client's username? Or would I use getName() from PendingConnection?
I basically want to obtain the client's protocol version and name in the ProxyPingEvent, but since Javadocs are a myth in BungeeCord itself am I not sure what to use here.
where are the good docs for waterfall
and spigots wiki for some stuff
can you even run waterfall on MH?
yea
u can
and custom plugins
just no idea if it will work or not since MH does the proxy stuff for you
and i got no idea on how a proxy works lmao
Very good JD
Pretty sure that it just stores the name that the client sent in the handshake
Kind of interesting how PendingConnection has stuff documented while Protocol doesn't
The project is lombok'd
I'm btw surprised that Velocity Javadocs aren't included in that page yet
Wonder what the best way to check the status of a different waterfall server is (e.g. waiting for players, game in progress)
Currently I can think of
A) Using PluginMessage but it seems inefficient sending to all servers
B) Using a SQL db to store the state of each minigame and reading from there
Is there any better way to do this?
wrote a standalone app which exposes a rest API which does all of the magical state management for stuff
You can use redis pub/sub or any message broker
technically MySQL/MariaDB to store the state with registered notifiers would be the best of both worlds (in memory shared state cache + pub sub)
but sql notifications seem to be rarily used so dunno if there are issues with it ¯_(ツ)_/¯
Atm i've done it with server pings and checking the motds and changing them when events happen
i think so too
Can I know why nobody first replies on GitHub issues
And why ServerKickEvent isn't working since 1.19 update?
- my care for going deep into "doesn't work" issues is minimal
- that event has been shaky for years
- afaik, 1.19 has literally changed nothing here
I said the reason on GitHub issues
From Bungee 1.19, only playerquitevent is being fired on server stop, on 1.18 (even waterfall) was working fine
Which doesn't give me much to go off without spinning up instances and messing around to test stuff around an event which has been janky for years
Literally nothing changed
I'm assuming md5 did another mess with bungeecord
I was messing around for testing the new version (1.19) and after some accurate test(s) I'm here to report that ServerKickEvent isn't started if a connected sub_server crashes (or just runs /stop).
Apparently, the issue is gone if /kick (or /ban) and /restart are being executed.
Another thing I saw after some debugging is that the proxy is using PlayerDisconnectEvent if a sub_server goes down (even in /stop) instead of kicking the player.
The issue is here after 1.19 BungeeCord's update.
Waterfall version: 1.19-496
Spigot instances: Paper 1.19-13
This is full message
Logs don't say anything apart from "proxy lost connection", latest waterfall updates don't change anything related to that
from a quick skim of the 1.19 update, I can't see any changes which would induce that
But why then 1.19 only is having this problem?
I don't know
No, my plugin isn't the issue since was fine before
Another thing i saw
On bungee is totally broken
Unless the server changed something here, idk
On waterfall sometimes works sometimes not
Only proxy 1.19 is affected, since I tried in old instances and newer one but still the bug is here
So I'm assuming that again, something broke from normal BungeeCord side
It was too strange that nothing broke in 3/4 updates, then md5 came up with a new bug
I can't see anything which would induce it, but, god knows
I don't have the commitment to waterfall to try to dig into that mess right now
What do you think then?
I don't know
I analysis in 1.19 bungee commit i see that nothing is changed in that
But why now the issue is there?
I don't know
FlameCord (sorry for comparing) seems not affected
as I said, theres not much to go off here which would imply a much deeper look into it
Other proxies such as aegis are just to throw away
Can i do something?
I mean, if something changed, I'd need to work out what
I can't see anything which changed which would affect this and would have to do much deeper testing/analysis than I care to do for waterfall right at this time
I just wrote down in console log what event are being fired
Even serverdisconnectevent isn't being fired now
Only playerdisconnectevent
uh huh
the player kick event cant fire if the server crashes because there’s never a kick packet to handle
then why in 1.18 was working fine?
if you sigkill a minecraft server it will have the same behavior
the server does send a kick packet on crash in 1.18 because its still able to it seems like
it should call the event on a random kick, but, that's purely waterfall doing that
that event has always been caveated af
am not aware of any real changes there
as for the ServerDisconnectEvent- its never guaranteed to be called in the first place
if the downstream connection dies first then there’s no event loop left to get back to
this is the issue with bungees event manager .call(…) function
but we cant change it without breaking the event even more
then how i'm supposed to fix it?
i have 200 servers online that are using my plugin, and still they didn't move to 1.19
i don't know if they will be happy if everything is broken
frankly I dont know how to fix this mess
the event loop works very different on velocity
as said, I'm not aware of any changes in the 1.19 patch which could affect that
and it works on unmodified bungeecord?
nop
Which is my point, nothing seems to have changed on that front
?!? So the issue is not in Waterfall at all
as said, that event has always been kinda broken af, we have a patch which fires it in. some extra places vs bungee, but, am not aware of any other changes there
that's why i'm asking, bungee created the issue, waterfall partially has it working
I'd need much more information to find something to work off here and waterfall is really bottom of the barrel for me
can i help somehow?
partially because its being fired in the same place as the serverdisconnectevent
and we know that event is broken
is something i really need (since people is using my plugin)
if i can contribute bisecting or i don't know
From what I can tell it is broken because the event loop is already gone by the time it would be called
I'd basically need a means to create a setup whre I can reproduce such an issue within a sane manner
sincerely idk why bungee is totally broken but on waterfall partially
The event should stll afail be fired unless he changed something with that
on my setup is called fine
because Waterfall calls the event too if there has not been a kick packet
I'd need to go much deeper into the changes
but like on a friend one, only playerdisconnectevent is fired
cat there’s nothing
I checked
the only variable is 1.19 behavior
I expect downstream to die before upstream
thus no event loop to fire event upstream
Yea, I mean, what is the manner in which the client is being kicked here is the Q
nothing changed in those events
but the client logic changed
if it works with the current version of waterfall and a 1.18.2 server/client
then it is 100% because of 1.19 logic
time to try i guess
Mojang doesn't particularly care about proxies as much as minimal accomidations
it doesn't help that bungee is massively scuffed here in some fronts
trying with 1.19 proxy
but 1.18 client
1.8 works fine, the thing is i also tried with 1.19
and was working, but for some, not
what the heck is going on
anyway, testing proxy & paper at version 1.19 with 1.18 client
@wide maple i'm sorry for ping, seems that on non-working setup with 1.18 client now the issue is gone
now i'm trying with normal bungeecord
confirmed
1.19 client issue
now everything is working fine
confirmed even in older versions with updated proxy, the issue is 1.19 not sending a kick packet i think (?)
did you /kick yourself to test?
the server is not expected to send a kick packet if it crashes ever
I'm a bit lost here... What event should I use if I want to get the player's name and IP during their join?
Should I use PostLoginEvent?
Also, how would I exactly obtain the IP the player joins with? Need this stuff for caching
Waterfall is an improved version of BungeeCord, right? Could I request a feature what is missing from Bungee, will you implement it?
depends
- being frank, dealing with bungeecord has left me heavily burnt out
- theres much stuff on my todo list which means that placement of a feature request could vary like crazy
Look at this: https://github.com/SpigotMC/BungeeCord/issues/1619
I'm trying to use Bungee in a Docker environment so it's a pain in the ass thing that couldn't use hostname to connect to containers (ie. if a container crashed and restarted the environment assign a new IP for it)
er, yea, that's a pita of one
- fixing that would involve breaking the API
- some level of "urrrgh"
I mean, maaaaybe I can do it without breaking the API but I've been burned by that shit so many times that it makes me weary af
if you wanna toy uorself, in the api, util class, there is a methdod called getAddr
replace the constructor at the end with a call to InetSocketAddress.createUnresolved()
idk what other implications that might have
(You'd also need to disable netty dns in waterfall.yml)
(but, assuming docker, you've already done that)
Hm okay, I'll try it, thank you
.
PostLogin will have their confirmed IP
Well, their player name
PreLogin will have it before its validated with mojang, etc
also, assuming that you mean the IP they had in their client?
Yes. The IP the client tries to connect from to the proxy
I'm not sure if I can just use getAddress because it's deprecated, but the alternative available doesn't seem to have any way of obtaining the IP?
Well, if you mean their actual IP address, getSocket or something, see the JD for that deprecation
if you mean the address that they shoved to connect to, i.e. my.pretty.server, get the pending connection, it has the vhost on that
Their own IP
And as I said. getAddress is deprecated because of BC accepting Unix sockets and the only alternative I can see here is getSocketAddress but this seems to have no method nor info about getting the IP from it...
you'd need to cast it to INet
So this would work?
@EventHandler
public void onJoin(PostLoginEvent event){
InetSocketAddress address = (InetSocketAddress)event.getPlayer().getPendingConnection().getSocketAddress();
plugin.getCore().getPlayerHandler().addPlayer(event.getPlayer().getName(), address.getHostString());
}
Yes
Okay, good
i tried everything, /restart /stop and all
so yeah, i'm confirming an 1.19 issue
seems not sending the packet, or at least proxy isn't doing that
Is ignored, like to send the brand
Is there some sort of AsyncTabCompleteEvent like in paper? Because i have to wait for a database query to finish before sending the suggestions to the client
Anyone has any experience what will happen if I’m trying to remove the fallback server?
no, that happens on the network thread iirc, and there are wider issues to solve to get an async tab complete event there
Hellow !
Could someone tell me where these errors come from and how to fix them or hide them from my console?
something opened a connection and didn't send anything for 30 seconds
stuff like that is generally janky server lists type stuff or random crud on the internet
generally, use firewall to block it
ups, wrong channel...
Holy shit you have a lot of plugins on your proxy
I don't think so x)
Btw why you have viaversion on proxy?
Such as useless, and works bad compared to backend
At least for me yes, you have some useless plugins for a proxy.
I find that it looks better when it changes the protocol (my server is 1.18x - 1.19 compatible)
You can just use some other plugin that is exactly for that, make priorited server 1.18 Up.
Viaversion on proxy,nah just avoid It.
Do you have any idea for this?
Well, some plugin that blocks versions for bungee, im pretty sure that exists.
I just removed and potentially found a plugin. I put it in my list of plugins to test.
But however, I still have the problem with the read timed out D:<
I mean, did you make sure your plugins are rigthly supportin 1.19/updated??
I switched from FlameCord to WaterFall, because I didn't like then, and in the end I find myself spamming with these errors (or in FlameCord there was an option to hide I think)
I will test without plugins
?? Flamecord It just toggles handlerboss messages, use a log filter or do It yourself.
Are there a demo which could send messages using strings in a language file?
Does anyone know how to fix this error? I do use a fiver wal
11:20:32 [INFO] [NiekonFlames,/14---------:63269] <-> InitialHandler has connected
11:20:42 [SEVERE] Error authenticating NiekonFlames with minecraft.net
java.net.UnknownHostException: sessionserver.mojang.com: Temporary failure in name resolution
at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
at java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
at java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
at java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
at java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
at java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
at java.base/java.net.InetAddress.getByName(InetAddress.java:1251)
at net.md_5.bungee.http.HttpClient.get(HttpClient.java:65)
at net.md_5.bungee.connection.InitialHandler.handle(InitialHandler.java:486)
at net.md_5.bungee.protocol.packet.EncryptionResponse.handle(EncryptionResponse.java:56)
at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:114)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:800)
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:487)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:385)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Thread.java:833)```
disable netty dns in the waterfall config and see if that fixed it
Do not work
I use a firewall
well- fix your system DNS and ensure the session servers are reachable
Bruh
Your server failed to lookup the IP address of the session server
check your DNS setup
That's pretty much all we can say on a DNS issue
i need some help with my configuration
i have it set up like this
public void setupRoleMapping(Configuration configuration) {
Configuration roleSection = configuration.getSection("roles");
Collection<String> permissions = roleSection.getKeys();
for (String permission : permissions) {
System.out.println(roleSection.get(permission));
this.permissionToRoleMap.put(permission, roleSection.getLong(permission));
}
}
the keys are not null
they show up properly
but the values are null
not sure if im missing something plainly obvious
have u tried printing permission
iirc permission doesnt directly give the full yaml path
do not use .'s in keys
that was the issue ^
How do i get player prefix?
I Guess that your plugin haves that?
Nope, i want to use vault prefix but there is no vault on bungeecord
I think on bungee/waterfall/velocity you're basically stuck with hooking into permission plugins directly, no nice friendly middleman to make life easy
I mean that is for backends
Plugins like luckperms can make that easier with the API built on.
Where can I find the latest API version of Waterfall to import it with Gradle? Or do you keep it in sync with the Paper version such that the two are always the same?
Thanks!
what's the best practice for custom bungee<->paper messaging? should i add a listener that provides an extra subchannel on BungeeCord or is it better to use a custom channel (in which case doesn't that mean the client knows about it/can mess with it?)
generally, use your own channel
(make sure to validate that the sender is the server, etc)
what about on the server end? how can i tell the difference between a packet from a client and from bungee?
ohhh should i make bungee cancel incoming packets from client before they get to servers in the first place?
Yes
Since that’s unsupported you won’t get help with it here for obvious reasons
But I’ll say this much; you’ll somehow have to get the artifact into your project environment

Hi everyone! Anyway I can easily debug:
could not decode packet! java.lang.IndexOutOfBoundsException: readerIndex(4) + length(1866) exceeds writerIndex(5): PooledSlicedByteBuf(ridx: 4, widx: 5, cap: 5/5, unwrapped: PooledUnsafeDirectByteBuf(ridx: 6, widx: 6, cap: 2048)
Values of length(var), ridx, widx and cap vary.
Someway I can get a stack or the packet thats causing this?
I think its probably caused by one of our plugins 😮💨
There is a system property which lets it produce a bit more info in the debugger for some stuff
can't say entirely as stuff like that gets kinda nasty
I'll look for such a property, thank you.
Its only towards 1.19 clients too, all other versions we support over ViaVersion work fine.
I have been able to figure out it only happens when another player comes close to the 1.19 player.
Don't use ViaVersion on proxy is useless firstly and wont work on it now, also on your backends use "viaversion dev" from jenkins builds
Yes is it, some of your plugins is oudated.
I don't use viaversion
Are yo using lastest build of waterfall?
oh, i thined by "via" you was meaning it
Does Bungeecord have an API way of loading Plugins at Runtime? Or do I need to use reflection
What are you trying to accomplish by loading plugins at runtime?
Writing a Mocking Library for Bungeecord
I'm using the latest waterfall
generally looks like the server tried to kick the player during an unexpected phase
Joining the server directly when setup that way works fine, whenever waterfall is in between it gives the error I've shown. Is forge just generally unsupported?
Ah, that's the reason then
I'm running forge 1.15.2
I imagine there is no way to resolve that, I'll just have to deal with it and run the forge server separately?
correct
You have an option, use a fork called ligthfall with modern forge support.
hey im not very familiar with bungee's basecomponents
how would i serialize a string into a basecomponent and keep thecolors?
this.broadcastedMessages.add(TextComponent.fromLegacyText(messages));
i have this
but the messages arent colored
Chatcolor be like
yeah it fixed it by doing chatcolor.translate
but now my issue is links aren’t clickable lol
TextComponent message = new TextComponent( "Click me" );
message.setClickEvent( new ClickEvent( ClickEvent.Action.OPEN_URL, "http://spigotmc.org" ) );
player.sendMessage( message );
idk how to do it in a config though
it’s easy to hardcore
hardcode
anyways i figured it out, the person using the plugin had a color code in the middle of the link so the client wasn’t reading it as a url
You should lean java ig
i know java
i don’t know how i would be able to put click and hover events in a configurable message
Get the string with the ClickEvent, that's all
You could try Lightfall, a waterfall fork that has modern forge support
Someone else mentioned that too, wasn't bothered enough to re-build my docker image yet though
Thanks
Is there a PlayerCommandPreprocessEvent (from bukkit) equivelant on waterfall?
or, a way to cancel a command
I thing that you will need to use the chatevent
If im not bad, #isCommand exists.
Yep you're right, thanks

Hey everyone, how can I retrieve the ip-address and the port of the proxy my plugin is installed on? On a Paper-Server one can achieve this information with Server#getIp() and Server#getPort()
the proxy can listen on multiple with multiple listeners so you need to iterate through them
oh, thanks
Whats the difference between Handshake#getProtocolVersion() and Handshake#getRequestedProtocol()?
With the first method you get the protocol version, with the second you get the requested
That's not really any help, i got that from the method names.
from the code it looks like "request protocol" is the next state that the handshake wants (status vs login)
seems to have nothing to do with the protocol version
itÄs the fourth field: https://wiki.vg/Protocol#Handshake
*it's
Ah awesome, thanks
I want to disconnect clients below 1.19 from joining before the secure-profile check, so that outdated clients still get "Outdated clients" instead of "requires secure profiles". From what I've seen the only event fired before that check is the PlayerHandshakeEvent, however if I disconnect people in there they client doesn't get the disconnect message I've set
@EventHandler(priority = EventPriority.HIGHEST)
public void onPlayerHandshake(PlayerHandshakeEvent e) {
if (e.getHandshake().getRequestedProtocol() == 2) {
if (e.getHandshake().getProtocolVersion() < ProtocolConstants.MINECRAFT_1_19) {
e.getConnection().disconnect(new ComponentBuilder("Outdated client").color(ChatColor.RED).create());
}
}
}
Client just get's "Disconnected". Is there any better way of doing that or am I doing something wrong?
handshake doesn't have a kick packet
earliest disconnect with message is in the login stage iirc
couldn't you just let them join the proxy like normal but kick them afterwards?
The proxy checks for secure profiles really early
And now my issue is that when you try to join with 1.18 or lower you don't get "Outdated version" because you don't even reach the backend server, so you just get the "requires secure profile" which is super unhelpful for users
Or can I disable "enforce secure profiles" in the config and manually check for that at a later stage?
yeah well my thought was that you would just not require secure profiles but just kick outdated clients/non-secure ones after they joined but I guess then the client wont accept that the server requires secure profiles afterwards
(I also already handle the outdated client stuff on the proxy itself, not on the server behind it)
I just use the PreLoginEvent, that might be before the whole secure profile stuff takes place (at least it looks like it from the login packet flow on wiki.vgr
*)
nope, it is right after iirc
oof :S
kinda odd that a "Pre" event is after login data was already exchanged :S
oh, wait
yeah, that implementation isn't good either
that's... dum...
tbh just having an event for it (or including it in the PreLoginEvent instead of manually handling those states) would solve this ¯_(ツ)_/¯
right now you can't even bypass the slot count with the event lol (something that works in the Bukkit API)
Or, if secure profiles are enabled, just kick clients that don't support it with Outdated & secure profile required
I mean... why not just adjust the translation key? xD
or that
But I honestly think that my solution is cleaner
I'll open a PR to waterfall
is there a method to get the default fallback server?
@glad salmon it uses a priorities list now. the first entry will be tried first, the second second etc.
Or is other way to stop competly the proxy?
don't ping cat
sry, nvm i found better way
Hello 👋 how can I access profile properties on handshake? The class which represents properties in normal BungeeCord is net.md_5.bungee.protocol.Property, however, there seems to be no protocol package when building for Waterfall. Were the classes moved to another package or how can I access those classes?
I mean, those are internals
if you want to access those you'd need to build waterfall and install it to your own local repo or whatever yourself
Someone remind me to publish my papermc api gradle plugin someday
That’s still on my list of things to do
you do stuff first
Yes, however my plugin is built primarily for BC and Waterfall users report that the plugin cannot load because the class is not available. With 1.19 release the Property class was moved to another package, is there any possibility Waterfall kept it at the previous location?
Yes, updating the plugin
why not just use api? 👀
Just use the new location? It wasnt removed from the api and you should always only use latest with bungeecord or waterfall anyway
