Console colors not being passed through from server (colorized modded servers)

[mkhatri1]

For the past few years, I have been using many platforms such as spigot, forge, bukkit and now, sponge. Consistently, I had been using a server wrapper called minecraft remote toolkit, but it had proven to be less than what I needed. Mainly due to incompatibility with sponge and forge. Hence why I had decided to come here, and use wrapper.py, which met my needs perfectly. To some extent.

My suggestions to wrapper would be the following:

-Support for jline. This would probably be fairly challenging to implement, as jline is a Java library. However, it is a very useful handler. Jline is a Java library for handling console input. It makes it so all the console output from the server directly is shown correctly, with color if applicable(sponge, spigot, bukkit and forge have colored output at times). http://jline.sourceforge.net

-The ability to customize shutdown and restart messages

-The ability to change what the prefix to commands is. (Instead of having / one could change it to .) That is just a personal preference

EDIT: In response to suresttexas00

-I use wrapper because it enables me to restart, and back up my server easily. It is meeting my needs better because it is highly adaptable and does not require craftbukkit to work. It doesn't have any excessive features like an "easy to use gui" and lets me run it within the server folder independently.

-In terms of proxy mode, I do not have a use case for it. Bungeecord has a considerably more amount of features, and supported plugins which enable me to ban, kick, or message people across the network.

-In terms of coloration, there are no encoding errors, and there are no random ASCII characters being output. However, all the characters that should be colored, are not and revert to B/W.

[suresttexas00]

Those are good suggestions, but "Why" do you use wrapper? "How" is it currently meeting your needs better? I need to understand who our user base is and why they would choose wrapper.

I already understand those like myself that want mod-like functionality on non-modded vanilla servers. It is the modded-server user base that I need to understand better.

Do you need to use proxy mode? If so, why?

[suresttexas00]

As regard coloration of modded server lines, I would have thought that they would retain their native coloring.. you are saying that they revert to B/W? Are there any weird ASCII characters being displayed?

[mkhatri1]

Edited original comment.

[suresttexas00]

So to use it with bungeecord and multiple server worlds, you would have each server running under a separate wrapper instance? ..and the wrapper would handle the backups, restarts, etc?

[mkhatri1]

Exactly. I have separate linux users for each server. I use a screen session to have all of the servers on one instance of putty.

[suresttexas00]

why different users? Are you hosting for other people?

Where are you losing the coloration, in the putty, or the actual bash/console windows of each user?

[suresttexas00]

Python uses the readline module, which, as far as I can tell, is what jline is a java implementation of... Not sure if readline works well on Win systems (the creator of wrapper, BenBaptist, was not certain)

[mkhatri1]

I have different users to organize all the files easier, and make it easier for me to hand off ssh access to staff members in my network if they need it for certain servers, and not to all. The servers are hosted on a remote dedicated box, with centos 6 minimal (no gui/terminal only). Putty mimics the output of the actual servers output very closely, so I'd say coloration is being lost in both.

[mkhatri1]

Oh, I was not aware that I had to install the readline module, my apologies. I will edit the documentation today, and send a pull request for it just to remove any future confusion.

[suresttexas00]

However, it is possible putty is not getting the colorcodes. Is there a way to physically check for sure?

I would say another way to check would be to run a server unwrapped and see if the putty session is colorized. However, to be absolutely sure, I would see if you would look at an actual console display.

readline should be in the standard library... o_O?

[suresttexas00]

Don't bother.. the documentation needs a complete overhaul...

[mkhatri1]

I remember the wrapper giving me a yellow message about readline not being there or something of the sort. There is no way to check physically, however running the server unwrapped does give colored output.

[suresttexas00]

that would explain the problems.. but I thought readline was a standard module.

[suresttexas00]

now that I know we are referring to external colorization, and since you don't use the proxy.. maybe the master branch would work better for you? Does the master branch (the 0.7.6) also lose the coloration from slave server processes?

This would also restore your ban functionality to the server process..

[mkhatri1]

Yes

[suresttexas00]

let me know what you find on the readline...

[mkhatri1]

After installing readline, the yellow error message is not showing up, but the output is still B/W

[suresttexas00]

I am wondering if wrapper is just receiving the plant text or is stripping the colorcodes and retransmitting plain text... I can't promise I can get to this anytime soon; this code started out pretty ugly, and even though it is cleaner than it used to be, its still hard-to-follow code in many places. I'll keep this open as an issue for colorization.. The whole console section probably needs a refactoring and overhaul.

[mkhatri1]

Sounds good. Best of luck!

[suresttexas00]

I have updated the README.md and updated the ban section to default to server-side banning commands. I would appreciate a test of how it works for you using the developement branch 0.8.8. (The console arrows and coloring are not fixed yet). You must still run the source code...

[mkhatri1]

The banning does default back to the server, there were no errors with the wrapper starting up. All looks good so far!

[suresttexas00]

I also found the problem with the build script. It was not zipping the Wrapper.py file properly. I'll have it fixed in a few minutes as build 125, version 0.8.9.

[mkhatri1]

I will check it out once I get time. Plus, I would much rather run the source code in case I ever need to edit it for my needs.

[suresttexas00]

May last push is build 126 and it fixed problems with many of the wrapper commands like /start /stop. Since much of this caused bugginess in the console, updating this could also possibly fix your arrow keys issues. FYI, you can use "/help" in the console to get the help for wrapper commands.

[mkhatri1]

Awesome! I will check it out promptly.

[mkhatri1]

The arrow key issues were resolved, and looking through command history works as well. Thank you for all your help!

[suresttexas00]

Verifying that colors is still not working (as that is what I have changed this thread to track)?

[mkhatri1]

Can confirm. They are not working.

[suresttexas00]

I am going to try using sys.stdin.readline() versus raw_input()/input(). I'll have a build in the next 15 or so minutes (i'll want to test the arrow keys first,as this may break them.) EDIT: Arrow keys and console last command list still work...

[suresttexas00]

Ok.. this is pulled into the development. How goes the colors now?

[mkhatri1]

I will check it out once I get time.

[suresttexas00]

oh yes, BTW, these are real builds you can use the Wrapper.py file on.

Oh yes, no hurry to test.. I just realized that this is not the function that is reading the server output anyway (the part that is losing coloring)... So this is definitely still broken.

[mkhatri1]

Yeah, the color is still not working.

[suresttexas00]

This has to do with the process handler itself, because wrapper only Reads the console output, so wrapper "proper" could not be losing the color coding. You might be able to address this in a test of your own:

EDIT: THIS IS THE FILE WHERE THE CODE IS LOCATED: Using (edit and running) the source code, in this file: wrapper\core\mcserver.py, in line 133, this command starts the server:

            self.proc = subprocess.Popen(self.args, cwd=self.serverpath, 
                                         stdout=subprocess.PIPE, stderr=subprocess.PIPE,
                                         stdin=subprocess.PIPE, universal_newlines=True)

you can try adding the following options, experimenting to see if one or both will fix it: start_new_session=True shell=True

shell = true is not normally used due to shell injection possibilities, but I don't think it necessarily poses such a risk in wrapper based on how we are using it.

[mkhatri1]

Where would I add those options?

[suresttexas00]

They go right in with the other options, like so:

self.proc = subprocess.Popen(self.args, cwd=self.serverpath, 
                                         stdout=subprocess.PIPE, stderr=subprocess.PIPE,
                                         stdin=subprocess.PIPE, universal_newlines=True,
                                         start_new_session=True, shell=True)

don't add them both at once.. be scientific.. Add 1, see if it works. If not try, the other. If neither work, then try both.

Line 133, in this file: wrapper\core\mcserver.py

Since you are editing the source code, make sure that is what you run for your test.

[mkhatri1]

I apologise for the late reply, but neither of the arguments work. Adding Shell does not let me start the server at all, and start_new_session does not start the wrapper at all.

[suresttexas00]

you did not capitalize it, correct? (shell) I can't imagine why that would prevent it from starting...

[suresttexas00]

If the wrapper does not start at all, please note any errors. you may have a whitespace problem creating a syntax error (when you modified the file to add the arguments).

If you put tabs in (wrapper uses spaces per PEP-8) or did not indent correctly, it will error out.

[suresttexas00]

I am still not understanding this. If these servers are printing color codes, those codes should be in the text output stream. I have researched this and none of the console reading schemas do any filtering to account for this. My only conclusion at this point is that those codes are NOT in the output stream.

Can you run a local wrapper and spigot server on your own user's Desktop with no putty type interface and see if the colors are still removed, or if you notice other anomalies?..

I am wondering at this point if these servers might be handling their own terminals with java-specific formatting devices/methods that are not actually passing colorcodes in the text stream (things like the jline which are functioning more like 'curses').

[suresttexas00]

I think I might have a solution to the lost colors. Please try #409 and let me know. I only have vanilla servers and don't want to go through the maven builds and such LOL :P

This was helpful: http://stackoverflow.com/questions/34624751/get-output-colored-text-with-popen

[mkhatri1]

My apologies for not responding or being active. I have had some things keeping me fairly busy in life. I will test out and respond to the latest build as soon as possible.

[suresttexas00]

I'd like to be able to close this. Any way to do a quick test and find out if the coloration issue is fixed?

[mkhatri1]

Sorry again for being late. Colours are not shown with the newest build.

[suresttexas00]

I have one more trick before I give up again for a while. Please try pull request #412 build 185

[mkhatri1]

It spams this in chat: `[21:35:03] [Wrapper.py/INFO]: Starting server... Option Description

---

-?, --help Show the help -C, --commands-settings <File: Yml File for command settings (default:

-P, --plugins Plugin directory to use (default:

-S, --spigot-settings File for spigot settings (default:

-W, --universe, --world-container, -- World container

-b, --bukkit-settings File for bukkit settings (default:

-c, --config Properties file to use (default:

-d, --date-format <SimpleDateFormat: Format of the date to display in the

--demo Demo mode -h, --host, --server-ip <Hostname or Host to listen on

--log-append Whether to append to the log file

--log-count Specified how many log files to cycle

--log-limit Limits the maximum size of the log

--log-pattern Specfies the log filename pattern

--log-strip-color Strips color codes from log file --noconsole Disables the console --nojline Disables jline and emulates the

-o, --online-mode <Boolean: Whether to use online authentication

-p, --port, --server-port <Integer: Port to listen on

--paper, --paper-settings <File: Yml File for paper settings (default:

-s, --max-players, --size <Integer: Maximum amount of players

--server-name Name of the server (default: Unknown

-v, --version Show the CraftBukkit Version -w, --level-name, --world World name Jan 21, 2017 9:35:04 PM org.bukkit.craftbukkit.Main main SEVERE: f is not a recognized option `

[suresttexas00]

Did you include everything. This part looks like something is missing:

--nojline Disables jline and emulates the  <- __THE "WHAT"?__

-o, --online-mode <Boolean: Whether to use online authentication

[suresttexas00]

I ask because I find this info enlightening.

[suresttexas00]

Although, this is clearly a failure.

[mkhatri1]

Don't even worry about it man. Coloured output is really just a personal preference, and i'm sure that most of the people using Wrapper won't need it.