Today I got myself back in to coding mode and put in a few dozen commits onto the server branch. I added quite a few comments that I think help the readability, though it might still not be comprehensive enough (knowing that the comments mean a lot to me doesn’t mean it means a lot to others).
Live console is already implemented, though it is probably hard to tell from the code. In the code, the functionality called ‘make_tail’ mimics the ‘tail’ functionality available in Linux, which means that the webui can live-stream any file in the entire current working directory, e.g., /var/games/minecraft/servers/myservername. This goes beyond just /logs/latest.log–and in fact can tail any number of files simultaneously.
Before we can add the feature for player list, let’s determine where this information is stored. In vanilla minecraft, is there a clean, systematic way of getting all players online?
To return to the web-ui a live-updating list of players, in other words, we need to know where we can even a single-snapshot of the players currently online.
RCON is one method, I believe, though it is somewhat iffy, because not all servers have it enabled or even want it enabled. Typing /list reports players online, then we just need to figure out how we’ll get that information into the web-ui, etc…
@ElPres As far as what you want to do to start contributing, you start by forking mineos-node. This is done from here, within github. Once you fork it, it’ll turn into flareofghast/mineos-node.
Personally, I use Github for Windows, and with it, it downloads all my gits to my desktop, which I can edit using my editor of choice. Since you already have created node-advertiser, I assume I can skip explaining how to get yourself a sandbox set up. But if you need direction on how to get it up and running, its node webui.
Rather than babble on about all the different possibilities, let me know what you’re able to get set up on your own, and where we need to fill in the gaps for you to have the backend server completely up and running (which it is, just not fully featured).
There’s another project that uses node.js which has the stdout and stderr redirected to his console implementation, it looks like he may have one server running at a time though so not sure if this would be any better or doable. There is also someone’s blog or something that I read that had output stdout piped to sed and grep to get the player list. I’m sure if you’re outputting to a file getting the playerlist is going to be pretty straight forward.
Then, it’s all front-end work to get the returned information to display on the existing web-ui, which exists on the other branch ‘webui’. I’m sure you can guess by now why I felt so confident that it’s not just comments keeping MineOS from having many outside contributors…there’s a lot involved–and only one dedicated contributor (so far) over the span of 5 years.
This iteration of the web-ui requires knowledge of node.js, html/css (obv), and javascript (in the form of Knockout.js).
There’s a bit for me to get my head around. I feel like the first thing I want to do is add the listener capability, as I believe that would give me understanding how to do this style of Javascript coding. I’m used to coding in Java now, and there is a bit different for Javascript, where I have previously been interacting with html elements.
I’ve set the default page as login_en.html so when you browse to localhost:3000 that will come up first.
I was thinking that it would be better to put different languages in a different file. Such as en.txt or something and parse that in for buttons and other labels. That way if someone wants to change the language to say French each line (as an example) would map to a different label/button and they could have fr.txt.
:edit:
Ok, just noticed that that’s part of the old stuff. I guess you don’t want to reuse the old templates?
Perhaps I shall just start chucking stuff together and see how we go?
No, I pretty much intend to use the exact same template, but based on the change from an asynchronous polling to event-triggered backend, pretty much 100% of the Javascript/Knockout.js will have to be rewritten.
Writing up a new version of the web-ui is always a lot of work, and the web-ui front-end is not something I’m eager to redesign, that’s for sure.
I suspect not all that much is broken… I’m choosing to redo 100% of the JS (scriptin.js) because my Javascript-fu is far more sophisticated now than it was a year ago or more.
Most of what is in-place could be used, but I also suspect that it’ll take less time for me to strip out all the innards and write it from scratch (drawing upon existing code for inspiration and code snippets) than to guess what should stay and what should go.
I’ve just updated webui.js to serve my login.html on /
I have just added in some knockout.js databinding for localisation purposes. It’s probably not the best way to do it but it works and is easy enough to change or whatever.
I don’t know how to handle authentication at this point in time so I have left that out at the moment.
