Hi :)
There is some problem with TabExecutor and I think I found the problem.
Exemple :
/send <playerName|all|current> <targetServer>
When I write "/send " (with trailing space) and press Tab, I don't have any suggestion. But when I wrote the first character of an online player, it suggest all players which start with this same character (expected behavior)
The problem is the same when I wrote "/send marcbal " (with trailing space). When I press Tab key, I have "marcbal" suggested instead of servers suggestion. (the result is "/send marcbal marcbal"). But when i wrote the first character of a server name, it suggest all servers which start with this same character (expected behavior)
other exemple : there is 2 players online in the same server : me (marcbal) and marcbaleeee (for exemple)
when I wrote "/send marcbal " (with trailing space) and I press Tab key, I have the suggestion of the 2 player names.
I deduced that the onTabComplete() don't care about the trailing space of the command string (exemple : "/send marcbal ") and probably a problem when splitting (removing last trailing empty args), so, the onTabComplete method try to complete the first argument "marcbal" instead of the second empty argument.
To split the command line, you use the method Pattern.split(CharSequence) that remove trailing empty strings http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#split(java.lang.CharSequence)
So, we should use the other split() method, with a second argument which has to be a negative integer value. (see Javadoc)
PS : Sorry for my bad english x)
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.
When searching for the networkaddress.cache.* values java will default to these
values when it can't find a manually set value, however if a security manager is
in place then as a special case java will set the cache lifetime to infinite.
Manually setting the values solves this issue.
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.
