If the list would look like this
- test1 -> 1.8 -> ServerKickEvent cancelled -> reason set to "outdated"
- test2 -> 1.8
- test3 -> 1.9
and a player joins with version 1.8 he would never be connected to test2 because the server test2 is not equal to test1 and the server test3 is not equal to test1.
So test3 is the last in the while loop and would be used also if another server with higher priority matches the requirements.
Action Bar packets in 1.9 now correctly support the JSON format, however sending them the 1.8 way will kick the client. This keeps the compatibility with 1.8 clients with the version check whilst correctly sending the packet to 1.9 clients.
This commit adds a config switch that allows users to turn off
the logging of proxy commands. It is set to off by default to
prevent unwanted log spam and keep current behaviour.
Log proxy commands
This commit changes the PluginManager to print a message to
console and the log when a proxy command is executed.
This may assist with debugging and miscellaneous
investigations.
* Only check the version of FML if we are running Minecraft 1.7.10 - 1.8 clients are always valid.
* If the version of FML that is reported is 7.10.99.99 - report the Forge version instead.
This method is simple: it resets the current part to default settings, keeping only the current text. It therefore acts like the old ChatColor.RESET
code. The retain method allows for more control over what is reset.
Add a test to verify proper functioning of reset()/retain().
The previous native cipher code has been refactored so that it may be loaded and used slightly more generically, allowing more native components to be easily added as time goes on.
I have also written a new native code compression module, which wraps around zlib in the same manner that Inflater / Deflater does, however it operates directly on the memory addresses of it's input / output buffers which means that we can save one, or maybe even two copies. To support this, the VarInt decoder has been adjusted to always use a native buffer.
For Minecraft+Forge 1.8 we can detect whether the user is a Forge user before we get the mod list, due to the changes to the initial (not FML|HS) handshake that are now made (which is for vanilla client support). Bungee can exploit this to detect FML clients from the off, but it still does not tell us what the mod list is. Thus, creating this API method for users who simply need to know whether the user is connected via FML is no longer a duplication of the getModList api method.
For Forge 1.8, a new \0FML\0 token is included in the handshake packet host field. Whilst from a Forge <-> Bungee standpoint, this is good in the long run (we can detect Forge/FML clients right from the off, allowing us to expose a reliable API for detecting modded 1.8+ clients), it plays havoc with IP forwarding on Spigot servers, as they expect a very specific format.
Until we can look at improving this situation (probably by creating an updated IP forwarding protocol on the server side), this removes the FML marker from the handshake whenever IP forwarding is on. If you have a FML 1.8 network, IP forwarding MUST be off.
With thanks to @geNAZt for finding the issue.
This patch makes the patch transparent to existing callers using cancel(ScheduledTask) from the scheduler. It also simplifies some logic in BungeeTask itself.
A mass of NullPointerExceptions would be outputted when tasks were stopped. This is resolved by checking if we are still running (indicating a possible scheduler cancel) before telling the scheduler to pull the plug.
Ideally, the entire BungeeCord scheduler should be rewritten. It has quite a few issues which could be avoided with a new system.
This is a workaround for quite possibly the weirdest bug I have ever encountered in my life! When jansi attempts to extract its natives, by default it tries to extract a specific version, using the loading class's implementation version. Normally this works completely fine, however when on Windows certain characters such as - and : can trigger special behaviour. Furthermore this behaviour only occurs in specific combinations due to the parsing done by jansi. For example test-test works fine, but test-test-test does not! In order to avoid this all together but still keep our versions the same as they were, we set the override property to the essentially garbage version BungeeCord. This version is only used when extracting the libraries to their temp folder.
This is needed because when the player disconnects from bungee they are removed from the connection map, this causes the tab-list rewrite to fail due the player no longer being on bungee and therefor it ends up not removing the player (online vs offline uuid). This would only happen on servers without ip-forwarding enabled
Always send the packet when going from modded -> anything, send the packet later when going from vanilla -> modded, never send it on a vanilla -> vanilla switch.
This causes the cached entry to be looked up every 5 minutes instead of the previous system where it was kept as long as it was used. This fixes an issue where after Mojang's session servers go down the ip address tends to change. This caused bungee to repeatedly hit the old (inactive) one which with the previous system would be re-cached every time someone tried to connect
This commit allows BungeeCord to support Minecraft clients both of versions 1.7.x and of 1.8.x. There should be no breakages to any other support, however following their deprecation and uselessness within 1.8, the Tab list APIs have been removed.
Please report any issues to GitHub and be sure to mention client, server and BungeeCord versions.
When used with an appropriate server jar (such as multi protocol Spigot), this will allow clients of many versions to concurrently be connected to the same set of servers.
Java uses ! to indicate a resource inside of a jar/zip/other container. Running Bungee from within a directory that has a ! will cause this to muck up.
This commit adds the basis for the intergration of a security manager into BungeeCord. The goal of the security manager is to prevent plugins from doing potentially dangerous or otherwise undesirable behaviour that may damage the stability of Bungee itself or pose a risk to the user's server.
One common theme in some Bungee plugins, especially those which were written in the very early days, is using Threads and ExecutorServices for scheduling purposes. Not only is this inefficient as there is no use of the thread caching features provided by the scheduler, it is also difficult to track who created which thread. Additionally creating threads not managed by the BungeeCord scheduler poses issues for when|if a plugin reload system is implemented, as these threads cannot be appropriately cleaned up and may continue to leak class references or perhaps even continue executing.
At this stage the SecurityManager is set to warn of prohibited actions, but not block them. For some plugins using external APIs, where usage of an ExecutorService is unavoidable, we have included an Unsafe interface to the scheduler which allows direct access to the underlying ExecutorService, or potentially a compatability wrapper.
