Console consult

Discussion in 'Bukkit News' started by Dinnerbone, Feb 25, 2011.

Thread Status:
Not open for further replies.
  1. Offline

    hash

    WOOOOO!!

    (+1 for not a huge fan of defaulting to dropping the date or of the leading '>' though.)
     
  2. Offline

    Stephen92

    I feel like a noob but where do I download this at? My server is dedicated so can I still use this?
     
  3. Offline

    PhonicUK

    MCMA seems to be coping well enough now:

    Code:
    [Debug] Java start arguments: -Djline.terminal=jline.UnsupportedTerminal -client -Xmx1024M -Xms1024M -jar craftbukkit.jar nogui -d "yyyy-MM-dd HH:mm:ss"
    
    It's not getting any unexpected data being pushed into its console, and it all responds as normal. Rolling this out to everyone soon.
     
  4. Offline

    Takato

    So, can I at least ask what I can try if the console reads out my "run" file and nothing happens ? maybe remove plugins etc ? what should I try D: I'd really like to get this working :(
     
  5. Offline

    Crystalise

    This will be GREAT! thanks :) Love the usability for Admins =) Thank you! =D
     
  6. Offline

    BeardedSp0rk

    Hey i really liked the shortened way to get items in hMod (ex: /item 46 3000). Also with hmod you could have more than 64 items at a time. Will that ever be possible with Bukkit?
    --- merged: Mar 2, 2011 1:50 AM ---
    Hey i really liked the shortened way to get items in hMod (ex: /item 46 3000). Also with hmod you could have more than 64 items at a time. Will that ever be possible with Bukkit?
     
  7. Offline

    PanCakes

    umm the use of this? i personally dont see any i got 2 servers and i cant remember the last time i actually used the console to do anything its either ingame or on ftp.
     
  8. Offline

    monotonehell

    Well that's how you use it. I on the other hand remote into my server several times a day and really appreciate the console improvements.
     
  9. Offline

    CaptainDDL

    I can't wait until this makes it into the recommended build. :)
     
  10. Offline

    RedstoneWizard

    Thank you for breaking my MineAdmin C# Program...

    [​IMG]

    Since your update i am not longer able to access "RedirectConsoleInput", this means i am not able to send any command to my server and in result of that fact, my program is completely useless now.

    Please fix that, or do a rollback, whatever, i was coding hours and hours to have a nice tool to administrate my server, and now my work was all for nothing, only for the reason that unixusers can play arround with their console window..., thats not what i call 'fair play'.

    Dont think just about the linuxusers out there, include the windowsusers too.

    If you want me to give you a sample whitch shows you the problem 'as-it-appears', i will give you a visual studio 2010 project and instructions how to run it, via pn.
     
  11. Offline

    Abrupt

    in case you haven't realized this, but YOU decided to write a damn program for bukkit, a minecraft server wrapper that hasn't even had any official releases yet. It is completely acceptable that they make ANY changes to THEIR program, both little or small, and you should have known that before you started your project. If you want an addition or a fix for something, don't be a deuce about it.
     
  12. Offline

    Dinnerbone Bukkit Team Member

    Have you tried disabling jline?
     
  13. Offline

    RedstoneWizard

    Hey sorry if you think the same the troll wrote before you xD i was just angry because i thought 'now its over, everything is at its end' i dont want to annoy you...

    i tried the following:

    bukkitLoader.StartInfo.Arguments = "-Djline.terminal=jline.UnsupportedTerminal -Xms1024M -Xmx1024M -jar bukkit.jar";

    but its still not working... any suggestions?
     
  14. Offline

    EdGruberman

    try:
    Code:
    bukkitLoader.StartInfo.Arguments = "-Djline.terminal=jline.UnsupportedTerminal -Xms1024M -Xmx1024M -jar craftbukkit-0.0.1-SNAPSHOT.jar nogui -d""yyyy-MM-dd HH:mm:ss"""
    you still need to start CraftBukkit's jar file for the server. and you'll need to use the -d parameter to get the date back (if needed)

    i use a System.Diagnostics.Process object to manipulate it also. it should work for you too. (tho StdOut will still have extra ">" characters as compared to before)

    but i'm still hoping they implement a simpler option to disable this feature. "nojline" or similar for a CraftBukkit jar argument that reverted it all back to the simple console would be hawtness. i like this feature, just would really prefer it to be an option.
     
  15. Offline

    Huns

    This is really, really awesome, and I'm going to go ahead and suggest two things: This should be turned off by default, and turning it on should be a single command-line flag. I know that's not the way you have in mind for implementing it, but there are REALLY, REALLY GOOD reasons behind these suggestions.

    I'm setting up Bukkit for testing on one of my servers, and eventually I'm going to deploy it to all of my customers (or at least those who want it - judging by hMod adoption, probably 80-90%.) If I hadn't chanced on this thread, I wouldn't have any idea about it. My custom wrapper doesn't know how to strip out your prompt or any of the ANSI codes that make line editing and all that fancy stuff work. I would've figured that out eventually, but for someone who isn't a developer and doesn't have a lot of experience working with the Minecraft server, this problem could be so perplexing that they might not even be able to solve it - particularly if they're using a wrapper that they don't know needs to be updated. Therefore, I strongly suggest that this be off by default. If someone JUST HAS to have a cool ANSI terminal, they can turn it on.

    If you need any more convincing on this point, I've been playing other online stuff for a long time, and I've seen MANY instances where the developers changed a feature without realizing all the trouble it would cause for people who expected things to work the old way. I've had many hours of my time wasted by features that just suddenly changed one day, and I've grown to really hate that. It's completely unnecessary. New stuff should be optional, not mandatory. People shouldn't feel like they need to wonder what weird unexpected thing the software is going to do the next time they update it. We've already seen plenty of examples of that happening right here in this very thread. That doesn't surprise me, because it's the same mistake I've seen other game developers make many times. They think, "Look at this rad new feature!" I think, "Crap, there's several hours shot."

    My second suggestion is to make turning it on a simple, one-shot command line argument. Don't make people specify the time format - this creates a dependency on the time format never being changed by Mojang, without giving any actual benefit in exchange for that. If I'm developing a server wrapper (which I am) and I read on the Mojang blog that the output format will now be such-and-such, I should just be able to teach my server wrapper about those changes. I shouldn't have to worry about Bukkit modifying the server output, at all.

    You see, some of my customers will want to run Bukkit. Others will want to run plain old vanilla. I know this because that's precisely what happened with hMod. I don't want to have to modify my wrapper to be able to understand the "Bukkit way" and the "vanilla way" of presenting the server output. I don't want to have to scratch my head and figure out how to pass new parameters to Bukkit to make it work the right way. I *need* this thing to pass console output unmodified, and I *need* to know that it isn't going to do some weird thing like injecting ANSI escape sequences and right angle brackets the next time I update it.

    This stuff probably doesn't matter all that much to people who are just running it at home. For GSPs like me, there are already enough things that can break while looking after multiple server farms in different cities. What I'm asking you to do is make Bukkit well-behaved for people like me who have to manage large amounts of servers.


    BTW, disabling jiline doesn't fix the ">" showing up. That thing needs to go away.

    Thanks for your consideration. I'm not the first guy in this thread to point some of these things out, but they bear repeating. MANY people want to be able to *totally* disable this, JUST IN THIS THREAD ALONE. There's a very good reason for that!

    Take care!
     
  16. Offline

    lukegb

    Err, what? No, it doesn't. You just update the time format. If the time format is changed by Mojang, you'd have to update your script anyway, to parse said new time format.

    ANYWAY I have to admit, I sort of agree. Or at least we make it a single option inside the config file to turn off - you're going to have to edit the config file anyway, and if you aren't, you're a BAD GSP. [​IMG]
     
  17. Offline

    Huns

    Well, sure, but it's something that would be easy to forget and potentially break stuff. Right now the time format thing is fresh in my mind. If it's changed a year from now, it's going to take me a while to remember back to this thread and whatever work I'd have to do to implement it in my scripts. (I mean, hosting this stuff on multiple servers requires a hell of a lot of individual things working together. I might not immediately make the connection.)

    And yeah, of course I'm editing the config file. [​IMG]
     
  18. Offline

    lukegb

    But yeah, if we make it a single option within the config file, there are two benefits:
    • Set and forget
    • Vanilla will ignore it anyway
    Win win? :p
     
  19. Offline

    EdGruberman

    i went back and forth on this as default. if you look at what Mojang did, the gui is default and i don't think any wrapper works that way. don't all wrappers use the "nogui" parameter?

    just like Mojang makes the gui/"easiest" interface the default, I think it makes sense to have Bukkit's default with the improved console also. a simple parameter (or config file option even) to completely disable it would be perfect.

    most users will not dig into the details and will just want a simple/easy interface by default. the new console should be that default to ease it for those basic users. advanced users will dig in deeper and learn the parameters to alter as they need.

    @Huns as a GSP, if you are installing custom modifications and not expecting to have to track those modifications for changes, i'm suddenly realizing why most GSPs have problems... ;) (at the same time, kudos to you for coming here to do said tracking, but that doesn't mean Bukkit should compensate for you if you don't in the future.)
     
  20. Offline

    Huns

    My point is that the least surprising thing should be done by default, unless there is some really compelling reason to do otherwise. That kind of philosophy is best for helping different systems that are maintained by different parties stay compatible with one another. (Isn't the entire Ruby programming language based on this idea?)

    When I was developing stuff for Second Life, the company that ran it (Linden Lab) would change how a function call worked every now and then. Suddenly, there would be 1000s of scripted objects out in the world that would suddenly stop working for no apparent reason. We would have to bug them for weeks to revert the change, which they did, and then just added another function to do things the new way if it was necessary.

    Linden Lab never learned their lesson. 8 years after they opened, their public JIRA is still full of tickets with titles like, "Why did you change how llSomethingSomething works? You just broke my product for 500 people." Second Life is probably going to go tango uniform sometime this year, and a BIG part of the reason for this is that they keep alienating both the developers AND the end users by introducing breaking changes.

    Here we see the exact same pattern repeated in this thread, in black and white: The guy who makes the Web admin thing had literally THOUSANDS of customers who couldn't use Bukkit because of this.

    Did we, as a community, gain something that was worth thousands of servers being out of commission? LOL. Of course not. Performance and stability are more important than new features almost all of the time. (That's another thing Linden Lab never got right. The game is still buggy as hell, and they spent many millions of dollars on a new viewer that has fewer features, and a bunch of other stuff like "avatar phone lines" that were an incredible waste of time.)

    Wisdom is where you go through life, making mistakes, getting hurt by those mistakes, and then learning from them.

    Smarts are where you look at the mistakes a wise person has made, and learn from them, WITHOUT having to go through the pain.

    It's better to be smart, than to be wise.

    I guess what I'm try to say is, look at the way Linden Lab did Secondlife, and then do the exact opposite thing. They've spent hundreds of millions of dollars of other peoples' money making an extensive series of mistakes so that you don't have to. :p
     
  21. Offline

    EdGruberman

    This is a development build of a custom modification for a beta indie game. If you are going to try and compare it to a full released production supported product, again I say your intentions are misguided at the least.

    It's simple. You test your new configurations in a test environment first. Once you determine it's ready for your service, THEN you implement it. To blindly assume that Bukkit will ensure GSPs are unimpacted is naive.

    If you want real world comparisons, I work in IT as an enterprise architect for multiple (15+) large customers (10K+ seats). Every single customer tests all patches in a test environment first before implementing. They do their research, consider the impact, then make the choice only after rigorous assurances are made. The company releasing patches doesn't restrict how their patches work to make it any easier on us. They simply continue to release. It is our choice to install the patches as we see fit and ensure we do our research appropriately. If our products need updating for a patch we want to install, it is up to us to comply.

    Again, I give you high praise for coming here and even having this conversation, I don't want to come off as hammering on you. At the same time, I find myself wanting to defend the Bukkit team. I love the work they are doing and my enjoyment directly hinges on them continuing to feel the freedom to involve us so closely in their development cycle.

    This choice of theirs with the new console may have disrupted things, but they were quick to respond with a work-around and are very open to the idea of making the work-around even simpler. I can't ask for more than that.
     
  22. Offline

    Huns

    We (our GSP) is in beta. We treat it like we're in production, in terms of how seriously we take the impact of what we do on our customers. Habits now influence performance later. ;) Just because something isn't officially "in production" doesn't mean it's okay to treat it like a midterm college project. Thousands of people are relying on it. That changes the game.

    It doesn't have to be. That's the point of having a dialog. That's why he posted this thread to begin with, rather than just dropping it in there and saying "lol whatever." If you are developing with Microsoft Visual C++, you should be reasonably assured that strtok() isn't going to change how it functions in a way that breaks existing code. That's what I'm talking about. Never make a change that breaks existing stuff unless it's actually necessary. ANSI terminals are an example of something that's nice, but not necessary.

    I don't usually install new stuff hot off the press, because I like to test it first and see if other people have problems with it. Unfortunately, Minecraft releases are sometimes mandatory, and any time the server is updated I have to update Bukkit too for obvious reasons. If I sit around fiddling with it while a new mandatory update has been pushed, all of my customers are either offline, or running without Bukkit. (Starting up without Bukkit when everyone's already used to it being there is something I want to avoid, especially since some people will use plugins that stop lava from flowing, and their stuff will get ruined if the server is started without Bukkit.)

    Ideally, the devs here will be sensitive to this and not introduce changes that mean that - on top of whatever downtime comes from applying the new mandatory release - I also have to figure out some weird new thing.

    The server admin guy who posted about his thousands of customers was unable to help his customers until the blurb on how to disable the ANSI stuff was introduced. Was that really necessary? No. Did Dinnerbone mean for that to happen? Of course not. I'm sure he didn't foresee it at all. However, introducing this level of headache for literally thousands of people in order to have a pretty terminal is just not even close to being a good tradeoff. Think of all the extra support traffic that happens when thousands of people suddenly can't use Bukkit.

    So, it's a learning experience, and I am doing what I can to provide some perspective, because I've already seen mistakes like this over the years I spent in another virtual world platform. If the Bukkit team learns from Linden's mistakes, they will save themselves and everyone who depends on Bukkit A LOT of trouble.

    Sure you can. You can ask them to learn from other peoples' mistakes. It's a reasonable request, and it's as much in their interest as anyone else's. Bukkit isn't something three or four people are using. It's used by thousands of people. That means that making one tiny change (like this) has the potential of causing serious headaches thousands of times over. As it grows, that number will be tens of thousands, maybe even hundreds of thousands. It's very important to consider the impact of changes, even if they seem trivial, like this one.
     
  23. Offline

    EdGruberman

    You are saying: "Do not change anything that will impact things negatively."
    I am saying: "Test first and be prepared for change."

    I'm guessing we are both in agreement on the above. I'm just trying to highlight that this is a free-time custom modification in development for a beta game. You have lots of choices on how to handle the situation (e.g. allow customers to choose to use Bukkit and clearly indicate it will most likely have downtime that you are not responsible for as a result.)

    Restricting the Bukkit team's development practices because you want to do less work to make more money is something I don't want the Bukkit team to be bogged down with when dealing with that requirement. I want them coding and releasing, not trying to making GSPs happy.
     
  24. Offline

    Huns

    LOL. OK, let's nip this in the bud right now.
    • If the Bukkit team chooses to learn from the painful mistakes of others, that saves them time that they could be spending on more useful things. "They who ignore history are doomed to repeat it" and all that.
    • Accusing me of wanting to "do less work" is bunk. I've precisely outlined and provided multiple examples of why the way I suggest is better. If they do it the way I suggest, they save time for themselves and everyone else. EVERYBODY WINS.
    • Accusing of me of wanting to "make more money" is an ad-hominem. My ideas are either beneficial or they aren't. In any case, I offered to pay out of my own pocket to get changes I want prioritized, and I'll make that same offer again in the future if I think it's justified. My partner and I have donated to the Minecraft forums as well as a plugin author in the past. We didn't have to, but we wanted to be supportive. We're in this for the long haul.
    • They should be taking GSPs into consideration. Things that make life hard for us also make life hard for our customers. Bukkit exists for the community, and we are one of the ways that community will interface with Bukkit. Remember when thousands of people couldn't use it? It happened earlier in this thread and I've mentioned it myself. Those thousands of end users matter regardless of whether their servers are managed by themselves or by GSPs.
    • You say they shouldn't be "bogged down," but that's precisely what you do when you don't plan ahead. You have to go back and fix it. It takes a long time to do it the right way, but it takes longer still to do it the easy way and then have to come back and refactor everything. Two degrees of course correction five miles from the port is worth 45 degrees of course correction when you get closer. Which one is easier?
     
  25. Offline

    EdGruberman

    You seem to want to type more than I do and also to be taking me in the wrong light so, I concede.

    (But, even after all this discussion I still think that what Bukkit did on this change and how they implemented it is perfectly acceptable and GSPs/along with everyone else can totally compensate.)

    Nothing but <3!
     
  26. Offline

    Soleedus

    Uhhh, where exactly do we download this?
     
  27. Offline

    4am

    You have thousands of customers depending on uptime of a production server running a beta-version game server with a development snapshot of a 3rd part modification wrapper linked with it?

    ...
     
  28. Offline

    Huns

    I don't, but the control panel guy does. Do you see a problem with that? Do you think he shouldn't have written it in the first place?

    It doesn't make sense to wait until something like this is feature-complete to get involved with it. If it did, you wouldn't be writing plugins yourself.
     
  29. Offline

    mindless728

    no, we are just saying that someone shouldn't be complaining about stuff being broken when it is still in heavy development
     
  30. Offline

    l5p4ngl312

    Yeah same. How do you actually get/use this?
     
Thread Status:
Not open for further replies.

Share This Page