Discussion in 'Bukkit News' started by Dinnerbone, Feb 25, 2011.
how can i get this new console? I didnt find it in this thread!
I'm talking about the "[Info]", "[Warning]" etc parts of the output. Before we updated to the bukkit version with the updated terminal, it was still in English.
However, after updating bukkit it became localized. I can only take it that the bukkit team made it be so.
It's another thing that should be an option.
But it IS, just start it LC_LANG=C java. This is the standard ways for over 40 years now...
this whole bukkit thing with the console should have been an option.
quote from dinnerdude
personally I didn't mind the default console, now the console doesn't work and it's frustrating.
Couldn't this have been a plugin instead, or something along those lines >_>
1.4minecraft is just around the corner and bukkit will simply have to vanish from my comp I guess.
You know you can disable the fancy console by disabling jLine right?
Again, you shouldn't HAVE to disable it, it should be disabled AS A DEFAULT. If you must, add a line in server.properties once it is launched set to false by default.
The default for a console is for human interaction. So the improved console should be default. Wrappers can start the server how they need it to be for them very easily.
Forgot I'm a major in java, my bad.
If I knew that do you think I'd be here looking for a way to fix ? =/
Right... what is "LC_LANG=C" and how do I use it in C# running on Windows to start the server process with English localization?
Besides that, it has nothing to do with the principle I'm putting forth, that you should not modify the default behavior.
Thing is, I, as other, have worked as a coder (C++, sorry), for... wow, now most of life, that is sad, anyway, and the general rule is don't change the API. Just don't do that unless you really really have to. And in this case, it's a case of "I wanna" over "I need to". Anybody wanting the extra features should be able to turn them on easily, I'll grant you that. But if you're just getting bukkit (because it's more stable, safer, plugins, whatever), you might not even know about the console output except as something to check out if something went terribly wrong.
Personally, I can disable it, so it's not a big problem for me. However, as it is, it really stands as a piece of bad design and I remember the goals of this community including a proper good design.
well you just need basic in reading, since the howto is given on page 5 of this topic, 3 posts before yours.
But I do agree that it should be an option on commandline.
And it has EVERYTHING to do with basic behaviour. Just because you are a blind windows user does not mean that a principle working for 40 years should be bent because of MS.
I've been loving the new console and here I see people complaining about it. Is it because I grew up with DOS and use CUI versions of Linux that make the difference?
Tried it and I only get
" '-Djline.terminal' is not recognized as an internal or external command, operable program or batch file."
As I said, I program in C#, not C or C++. LC_LANG is not something that I have access to use directly.
Besides, there is no way for me to modify the locale of the process that I start from C#.
And blind Windows user? I bet you're one of those that see Linux as the holy grail of computing and hates everything Microsoft.
I use Windows as everything I need is on it. I'm also an avid gamer, and Linux is not exactly brimming with games. And no, do not tell me to use Wine.
That is not to say that I don't use Linux at all. I set up my own virtual Ubuntu to cross-build FFmpeg for Windows.
But still it does NOT have anything to do with what the default behavior is. If an application was originally made to be unlocalized, making it localized is breaking the default behavior.
Why are you writing in C# anyway?
You don't seem to understand that this is a pre-release stage for Bukkit. They can change the entire thing at any time if they choose. Just think how bad Bukkit would be if it changed as much as Minecraft does in each update.
Because it's what I learned to program in first, and what my current job is using.
You seem to be forgetting that Bukkit, or Craftbukkit, is a mod of the original Minecraft server. That means that the default behavior is by extension that of the original server, which is unlocalized and does not use jline.
So to not modify default behavior, these should be optional switches in Craftbukkit.
My question was more, why are you using C# with Minecraft? I'm not bashing C#, I love and prefer it.
I am not forgetting that. Everything in Bukkit is an improvement over Notch's weird code.
I'm just using C# for the wrapper I'm developing, since it's what I'm most comfortable with. And when I finally release it, it'll be portable thanks to Mono.
If I started making plugins I'd probably need to dust off my Java skills, unless Bukkit in the end will support C# for plugins that is.
You obviously have no idea what locales are all about.
Besides, from what I googled, SetThreadLocale() changes locales.
P.S.: I used and programmed for windows for 10 years and still use them to play games. I was just criticising that somebody should change localization standards just because you do not know how to use them on windows.
I can run Bukkit without Java, but I haven't found a way to run .Net (or Mono) dlls in Java. I'm still working on it though. If I get something, I'll certainly release it.
That doesn't help him change what Bukkit is spitting out. He's connecting to it via standard input/output rather than a plugin.
I tried -Duser.language=en on my command line and I think that will work to start CraftBukkit's Java process in English?
The only thing I've found so far that seems to be pretty painless is http://www.jnbridge.com/. Though it's expensive, and licensing is also very confusing.
I know very well what locale is, and SetThreadLocale() is a funtion declared in kernel32.dll that needs to be called through interop.
I'd much rather use System.Threading.Thread.CurrentThread.CurrentCulture which is available in .NET to change locale.
But changing the locale will still only affect my application and not Craftbukkit, since it is run in a separate process, and I only capture input/output to interact with it.
And I'm not calling for a change to the standard. Only that CraftBukkit follow what was used for the original Minecraft server, which is English.
Do not change default behavior, unless you have a very good reason to.
Yes I saw JNBridge too. It's too expensive for what it does though. All it does is marshal calls over a socket from one framework to the other. I'm actually writing something like that in C# right now. For free.
Oh for crying out loud. Locale-enabled IS a default behavior.
And is it that hard to actually run minecraft (the other process) with changed locale in the command line using a system call?
So you're suggesting that we don't change the default servers behaviour, so all the Bukkit fixes for stuff broken in the original server should be toggled off by default, as well as toggling off the plugin API unless they are individually explicitly enabled by, say, a command line switch?
Yes it is default behavior, for Java as a whole. But Notch forced the server to be in English locale for some reason.
And no, it's not hard. Not now that I know what the argument is. Not everyone does however.
No, that is not what I'm saying at all. Think of the standard server as an interface. You do not modify the interface i.e. change the standard command window or change the language.
Bugfixing is fixing the implementation of this interface, not changing it.
Adding the Bukkit API is like making it implement another interface. It doesn't change the other interface, but merely adds a new one that can be used on top of it.
What I was suggesting is that instead of breaking stuff be changing the default, you'd instead ad it as an interface so to speak, which looks like this:
And it's accessed through commandline options.
If you know it's bukkit, you know there is the extra function that gives you a new fancy terminal.
If not, well then you only know that the old terminal exists, since that's the only interface you know of.
When you use CraftBukkit, you are installing a modification. It mods things. Even default things. *gasp*
The Bukkit Team is very amiable to ensuring options exist to turn their suggested defaults off so their modification does act like notch's default implementation. Why are we wasting their time having them defend this position?
If you are creating a GSP, a wrapper, or anything else that interacts with a Minecraft server and you want to support CraftBukkit servers also, YOU need to compensate for CraftBukkit.
This thought just crossed my mind. Uzza, you are welcome to download the source and compile it yourself. With or without specific features.
Richard: That thought occured to myself also, but then I realized how much Java and github scared me to death before I just forced myself to dig in... But, it might be unfair to force people to learn Java/etc if they simply want to emulate how Mojang's server works by default. CraftBukkit's success will certainly hinge on it's ease of use across all target audiences.
To that end, I created this thread that I hope helps in the future: http://forums.bukkit.org/threads/emulating-default-mojang-server-behavior-with-craftbukkit.9632/
I want to disable this console thing, so I can update bukkit again :<
Separate names with a comma.