Time moves forward, so the second call to nanoTime returns a bigger number than
the first one, giving a negative elapsed time … defeating the whole purpose of
this code. :-(
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.
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)
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.
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.
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.
Currently, passing a null favicon String to the ServerPing(Protocol, Players, String, String) constructor causes a NPE. However, passing a null `Favicon` object to the corresponding constructor does not cause one. Setting the favicon String using the setFavicon(String) method doesn't cause a NPE either.
Therefore, the NPE thrown by the constructor is inconsistent and should be avoided. Please find a sample NPE here: http://newpaste.md-5.net/pmtqjc8vl (Note the `null` favicon)
This PR changes the documented (unintended?) behaviour by adding a null check before passing the favicon String to the alternative `Favicon` object constructor. This makes the constructor consistent with the other one and the `setFavicon(String)` method. This also adds compatibility for old (made before Favicon API) plugins passing `null` favicon Strings (and expecting no favicon to be displayed instead of a NPE).
Thanks!
