-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Console colors not being passed through from server (colorized modded servers) #316
Comments
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? |
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? |
Edited original comment. |
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? |
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. |
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? |
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) |
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. |
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. |
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? |
Don't bother.. the documentation needs a complete overhaul... |
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. |
that would explain the problems.. but I thought readline was a standard module. |
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.. |
Yes |
let me know what you find on the readline... |
After installing readline, the yellow error message is not showing up, but the output is still B/W |
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. |
Sounds good. Best of luck! |
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... |
The banning does default back to the server, there were no errors with the wrapper starting up. All looks good so far! |
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. |
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. |
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. |
Awesome! I will check it out promptly. |
Where would I add those options? |
They go right in with the other options, like so:
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: Since you are editing the source code, make sure that is what you run for your test. |
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. |
you did not capitalize it, correct? (shell) I can't imagine why that would prevent it from starting... |
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. |
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'). |
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: |
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. |
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? |
Sorry again for being late. Colours are not shown with the newest build. |
I have one more trick before I give up again for a while. Please try pull request #412 build 185 |
It spams this in chat: -?, --help Show the help -P, --plugins <File: Plugin directory> Plugin directory to use (default: -S, --spigot-settings <File: Yml file> File for spigot settings (default: -W, --universe, --world-container, -- World container -b, --bukkit-settings <File: Yml file> File for bukkit settings (default: -c, --config <File: Properties file> Properties file to use (default: -d, --date-format <SimpleDateFormat: Format of the date to display in the --demo Demo mode --log-append <Boolean: Log append> Whether to append to the log file --log-count <Integer: Log count> Specified how many log files to cycle --log-limit <Integer: Max log size> Limits the maximum size of the log --log-pattern Specfies the log filename pattern --log-strip-color Strips color codes from log file -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 |
Did you include everything. This part looks like something is missing:
|
I ask because I find this info enlightening. |
Although, this is clearly a failure. |
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. |
@Darkness3840 This is due to your Putty configuration and is not an issue with wrapper. Wrapper uses standard ANSI color codes with support on both *nix and windows systems. Please confirm that your putty is using default terminal settings, specifically the following: Window -> Colours -> ensure 'Allow terminal to specify ANSI colours' is checked If that doesn't work, try the following: Connection -> Data -> Terminal-type String -> change it to |
@Darkness3840 Did JasonBristol's comment help? |
My putty configuration already had 256 bit colour enabled, alongside ANSI colours. It is the first thing I tried when attempting a fix. This is still, unfortunately, an issue with Wrapper. JasonBristol's comment did not help. |
Ok, I am reviewing this again and I think we need a point of clarification; There is not an issue with wrappers log colors, correct? The problem is the colors from the wrapped modded servers that is not being passed, correct? The issue, if I recall was not that colors don't work, but, rather, that colors are not piping through from the various server consoles into the wrapper console... ? I think this got sidetracked by the discussion of whether your terminal has colors enabled... |
One other thing.. you stated at one point: "Sorry again for being late. Colours are not shown with the newest build.".. Was there ever a wrapper that DID pass the colors correctly. If so, let me know what version... |
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.
The text was updated successfully, but these errors were encountered: