[Project] New Launcher (Ported)

[BantyRooster]

Original Post by TheKraken7:

Hello Everyone,

I would like to officially let you all know that a new launcher is under development. The development has been going at a relatively slow pace for the past two months but it has finally reached a phase where it can be contributed to.

Currently most of the development of this launcher has been purely on the UI. The GUI library used is Oracle's JavaFX. The immediate next phase is integrating the mojang auth library into the launcher so that access tokens can be generated for login. A lot of the internal functionality has not been planned out, however the current plan is to use the old launcher's code for reference (not direct use). A big goal of this launcher is to make it much less error-prone. To do this I am attempting to reduce external dependencies and implement a system where java versions are automatically located by default (similar to mojang's minecraft launcher). I also plan to implement a system that catches issues and lets the user know exactly what the issue is. For example, if this launcher ends up being 64-bit Java only (probable) and the user only has a 32-bit java installation, the launcher will display a notification to the user explaining that this is the issue. Most likely I can then have the web browser on the launcher automatically open a wiki page to the detailed solution of the issue. This is just a proposition, but I would like a feature to this effect to be implemented to simplify the user's task.

The source code is currently available on GitLab, however it has only private access. I don't think I have access to change the visibility level so I will update this post once the code becomes public. Any coder with access to the WesterosCraft GitLab account will have full access to the repo.

See here: https://gitlab.com/westeroscraft/WesteroscraftNewLauncher

If any of you would like to assist with the development of this launcher then leave a reply below. At some point in the future I would like to meet on discord with anyone who wants to help to discuss internal design and finalize a feature list for the initial release.

The design for this launcher was created by carcinogenius. Visuals shown below:

The launcher as it appears on startup.

Web browser and toolbar demo. Notice that the page auto-scrolls and some of the spacing is reduced. This is done by injecting some JavaScript into the web engine that will execute on specific pages. This allows us to optimize the look of certain pages on the limited space available.

The launcher log.

Opening log in new window.


If you have any design or feature requests do not hesitate to leave a reply

 

[BantyRooster]

Looking good! Nice to see how this has come along in the past few months. Overall it looks much easier to comprehend than our current launcher, and the injected JavaScript is a neat touch.

The source code is currently available on GitLab, however it has only private access. I don't think I have access to change the visibility level so I will update this post once the code becomes public.

Sorry about that! Didn't realize the Master permission level couldn't change visibility so I've re-added you as an Owner. I've changed the visibility level already, so both projects should be public now.

 

[BantyRooster]

How is it going on this front Kraken?

 

[BantyRooster]

Not bad, I just recently returned to University so progress has hit a speedbump, hoping that I can put in some significant work soon.

 

[BantyRooster]

Hello everyone, I have some updates.

First of all I would like to apologize for the slow progress on this, I have been quite busy lately. This weekend was a lot slower for me so I was able to cross a daunting task off the feature list. This feature was having to do with the WebView on the launcher, particularly concerning the context menu. For whatever reason, JavaFX does not provide access to the default context menus using their public api. Accessing it was claimed to be essentially impossible on all of the stackoverflow articles I read. After investigating the source code for some of these things I was able to open access using private api and reflection. These methods are clearly unsafe since they may cease functioning if Oracle decides to implement some under the hood changes to the JavaFX API. We should be relatively okay though, because it seems that the utilities I am accessing have been in place for over two years. Should this ever cease functioning in a future release, there are certain safe-guards implemented so that the default context menu should display anyway (without our modifications).

So now for the exciting part, what was actually accomplished. I was able to modify the context menu to replace one obsolete button and add a new one. The menu item "Open Link in New Window" has been replaced with "Open Link in Default Browser" and a brand new menu item has been added called "Open Page in Default Browser".

Below are some gifs to demonstrate functionality.

Open Link in Default Browser:

Open Page in Default Browser:

[rule]

I an hoping to get more done before the month is over, and there are a few things that you guys could do to help me. Mainly I need graphics. The launcher is an undecorated window

 

[BantyRooster]

I have one comment to make regarding the use of internal api in the launcher. Everything I am currently doing is expected to work in all of the later Java 8 version (~Update 40 and above? Don't quote me on that). There is an issue though, which is that Java 9 will essentially break all of the internal api code due to modularization in Project Jigsaw (read more here). Java 9 is scheduled for general availability in September of this year and I plan to have this launcher done well before then. This means that once Java 9 is finally released I will need to update the launcher to a Java 9 version in order for it to work properly. The good news that is coming out of this is that Oracle claims that they will extend their public api to allow for more of the really necessary stuff (such as creating custom controls) which is only possible by working with the internal api. Hopefully I will be able to convert all of the unsafe code to use those planned features at the time, which will make the Java 9+ version more or less version safe. I haven't looked extensively at the JFX9 dev builds so I can provide more details as Java 9 gets closer.

The only thing that needs to be done on the user end is to distinguish which version to run. Should the launcher be complete soon then we will just list it on the downloads page since everyone will be running Java 8 (if they are running below 8 then they will not be able to use the launcher). Subsequently once JRE9 is released we will simply need to put out an announcement that the launcher is not compatible, or I could add some sort of version detection on the launcher, since it should attempt to start up, however there will probably be some access exceptions thrown. Once the launcher is updated for Java 9 we can list that on the downloads as Java 9+. The best thing will be to probably support both versions for 6 months or so as things get adjusted to the new versions and then deprecate the Java 8 version and recommend people use Java 9. This is something we won't need to worry about for at least 7 months, however I wanted to put this out there.

I also just want to assure you guys that I will make sure the launcher is made compatible with Java 9 when the time comes. Once the current Java 8 version is complete I will be able to start the conversion by building it against some jdk9 dev builds and making the necessary changes.

As for the current development of the launcher, I am working on the settings features (saving, updating, reading).

 

[BantyRooster]

Hey guys I've been trying to get some work done on this but unfortunately there's a lot on my plate at the moment. I think the best way to get this launcher done quickly and done well would be to recruit a few other coders and delegate tasks among each of us. I'm currently on Spring break from uni so I have some time to get people up to speed on what's been done, what's half done, and what's left to do. If you're interested in contributing to this project leave a reply to this thread or send me a pm, whichever is easiest for you.

I hope to get a few replies before the week's end so I can bring you guys up to speed in a discord meeting. We can discuss the current functionality and the features that we expect to have complete before an initial release, and how to implement them. We can also organize and delegate tasks to have a clean workflow going through git (avoid messy merges). If you are not strong with front end development then you don't need to touch any of the JavaFX and can simply work on the internal portion (downloading and organizing assets from the mojang servers as the main thing). If you are bad at back end development then you can work on the UI. Any skill is welcome, so long as you know what you're doing.

So yea leave a reply and we can talk as a group on discord later this week. Looking forward to working with you guys on this.

 

[BantyRooster]

Hey guys, still trying to find the time to work on this. Maybe once my spring semester ends I'll find some free time. I'm still looking to get a few other coders on board to speed this up, so let me know if you're interested.

I didn't want to have so much time pass with no new updates, so I added the ability for you to send the launcher output automatically to hastebin.

Take a look:

(mp4 link if you want to pause it https://i.gyazo.com/9da845a013d79308fa00c00cd4dea29d.mp4 ).

 

[BantyRooster]

Looks nice! How are you approaching the client content management (e.g. deploying of the client updates, and the like)? I glanced at the code quickly, so I probably missed it.

 

[BantyRooster]

A lot of the internal functionality, including the content management, has not been worked out yet. So far most of my work on this has been putting together the GUI and implementing some of the front end features. The plan for the internal functions needs to be put together soon. I'm hoping that I can get a few other coders on board with this and we can discuss the goals for this launcher and how we will implement them. In doing that I think the final product will be more stable and optimal.

 

[BantyRooster]

I am considering restarting this project and moving away from JavaFX/Java in general. I've been guaging the memory usage of the GUI library and with what we current have implemented (just what you can see on the screenshots), the usage is about 650 MB of RAM. Honestly, I think this is rediculous. The whole point of the launcher is to be a light-weight utility to dispatch news directly to users and handle all of the mod building/version control required for connecting. There is absoutely no reason it should take more than 100MB, at an absolute worst case scenario. The current launcher is actually not that much better on this front. It uses an older library, so the memory usage is not as high but still ranges between 350-500 MB. If you look at any other program which does way more than the launcher the memory usage is almost always below 100 MB.

I have been considering the impact on moving away from Java and so far I can see no red flags. The ideal choice would be C++, although it's no small task to create GUIs with that language. Also, I haven't made anything substantial with C++ so switching to that would really kill any goal of having this launcher done by July.

In looking for an alternative I've considered several factors.

The first, and most important in my opinion was simple and flexible UI creation. JavaFX made it extremely difficult to do many necessary things simply because the API lacks some less used though still essential features. If you've been keeping up with this thread over the months you are definately familiar with my posts explaining how I had to "hack" into private api to accomplish what was desired on the UI side.

The second consideration I made was to select a platform that is new, popular, and recieving constant support. I would not want to choose an old system or something that is obsolete to preserve the longevity of the launcher.

Finally I wanted to ensure the platform was something I could jump onto relatively quickly and port the existing code with relative ease.

The platform I found is called Electron. The framework is built ontop of Node.js, which is actually becoming very prevalent in the development world. The beautiful thing about electron is that the GUI is written in HTML, CSS, and JavaScript. The final product is then wrapped into a chromium browser. This is great for many reasons, but the main one is that it allows us to develop GUIs quickly and use features that may not be present in other languages. We have the full power of web development at our disposal to craft a unique GUI. You will not know that the application you are using is wrapped in a web browser unless you go to great lengths to make the app look like a browser.

With this switch several things will have to be rethought about the launcher. In my opinion this is a good thing. We could still use the embeded website thing for the News, FAQ, etc tabs using iFrames, however they can easily be rebuilt into the launcher. The news module on the site is built with HTML/CSS/Javascript and the Electron launcher will be able to run all of those things. For example, with the news module instead of showing the actual /servernews page we could use a RSS feed or adaption of what ATSlayer did and have a news section on the launcher.

Using Electron is one of our best options right now and I'm prepared to move forward with it. Javascript is not a language I know fluently although I have made small scripts with it in the past. I took an hour out of my day yesterday to setup some tests and everything seems completely doable. I'll post an image below of what I put together. Obviously this doesnt look as good as what's been done with JavaFX so far, the reason for that is simply because I've spent virtually no time on it so far. The alert box saying "green" is just a test I wrote to retrieve the status of the mojang session servers. It clearly works

https://i.gyazo.com/4a8ec10581bafb51a8a6e2447677f35a.png

Of course if the other coders dont want to switch to Electron, we can stick with JavaFX although I am really unpleased with the current results. The purpose to create this new launcher was to replace the current one with something more efficient, stable, and personalized. I have strong doubts that continuing with the Java implementation will allow us to reach those goals.

I would like to get together on Discord ASAP with some of the new coders to discuss getting started with Electron. Since this code will be started from scratch we can discuss our overall goals for this redo and how we will get them DONE before July, preferably in mid June to allow for a testing period. Javascript is a powerful yet lightweight language. I have full faith that we can implement things in a timely manner.

I just want to note that I cannot do this unless I have active support from at least one other coder. The tasks NEED to be divided or this will take forever. If I spend 150 hours rebuilding the GUI and implementing the new features discussed earlier I'll be completely burnt out by the time I hit the important backend stuff. Ideally while one person works on the UI, the other works on the internals. Once the GUI is rebuilt, internal tasks will be delegated accordingly. For example, someone can work on authentication with mojang and storing credentials, while the other works on the system to manage our modpack version and handle a download queue. There's just too much to do unless we really rev things up.

I understand people have time constraints, as do I. I expect not much work to be done on my end until may 5th or so when I finish finals and head back home. Nonetheless I want to at least get a few meetings going so we can solidly plan and create this. I'll send a message to the other coders, although I don't know all of them. The only ones I know to still be here are Mike, Hal, Miguel, Matan, illblew, and Nightmare (not officially so far, but he's assisting with this project).

TL;DR Sorry for the long post but please try to read it. I've wrote a bit about switching the development platform for the new launcher.

 

[BantyRooster]

Couple of thoughts:
1) http://pivot.apache.org/ - Apache Pivot - fully open, seems pretty nice, usable for both rich desktop and applets (although almost nobody is doing the latter anymore....). I don't have personal experience with it, but I know folks that are using it and like it.
2) Follow the pattern that a lot of folks are doing these days: make the UI a 'browser container' hosting a Javascript-based application for all presentation and user interaction, and have the 'function' implemented via localhost-type REST interactions to an embedded Java-based web server. Makes the GUI part develop like a web app (which lots of people know how to do well), while making the logic/function develop like a set of microservices (which also is how lots of people develop). This seems similar to the pattern for Electron, but it's probably worth considering, even if you do not opt for Electron, since it'll allow you to have a world full of JavaScript app framework tools and libraries, while avoiding the fact that UIs aren't Java's strength (and Electron seems to be JavaScript centric, with a node.js personality for logic, which isn't going to necessarily help with being able to grab existing Java-based code for handling Minecraft client launch, authentication, and update)

 

[BantyRooster]

As for the minecraft client launch, I believe we can start program by creating the process with Node.js. As for the client authentication, luckily someone was nice enough to make a Node.js version of the MojangAuthLib. Not sure how secure it is but at first glance it looks good. In order to handle updates I'm fairly sure all of the assets are listed in a json file so there should be no reason we can't just parse that and grab the assets as usual. The only thing I am unsure about is grabing the modpack because I don't know how that logic works at the moment.

I'm going to attempt to do all this stuff in Node .js, although if you think it would be better do the java based web server I can attempt that also. I would just need to discuss that a bit because I'm not sure how I would go about implementing that type of thing.

 

[BantyRooster]

If you've got a handle on the dependencies for doing it in node.js, and are otherwise comfortable in developing in node.js, I've got no concerns. It's a good choice for what we're doing here - node.js SUCKS for compute-centric processing (as does JavaScript, in general), but perfectly fine for asynchronous I/O processing, as will be involved with downloading the mod pack content and spawning off the launcher itself. I was mostly suggesting the Java server side as a point of leverage of existing code, and my perception that you might already have a higher experience and comfort level with coding in it for the 'server side'. Key point, for you sake and ours, is the platform portability - Windows, Mac, Linux are definitely all required here. Are you figuring on using Electron, then?

The other thing that we (and most launchers) have tried to do is to be sure that the launcher itself is automatically upgradable: that is, the base of the launcher itself is a small stub that doesn't do more than check to see if the body of the launcher is present and up-to-date, and to pull down it down if either is not true. We want to be sure to avoid telling people they need to pull down launcher patches (just like the MC client patches and mods). This sort of thing will likely be pretty easy to 'add on' once we get the launcher itself coded: it's just a 'pre-launcher' that could just do the update check and download, and then hand off to the 'full' launcher, so it's easy to do after the rest is in good shape.

 

[BantyRooster]

Sounds good Mike. Of course I'm more comfortable with Java development, although I think the best thing with this project is to finish it off in Electron and Node.js. The launcher shouldn't be doing much computing, and the real heavy stuff is just work with I/O. As you said, Node.js should have no issue with this. In my opinion, Electron will excell where hava has failed, that is on the user interface. Just as any website we'll just connect the backend features to the front using some Javascript. I got into a meeting with Matan and Nightmare and we are ready to go on this. I've also been speaking to NewEnglandRed who is willing to provide support on the UI and its design.

I have setup the base code and put it up on a new repo. You can check that out here:
https://gitlab.com/westeroscraft/electronlauncher

I havent created a readme, but the only thing you need in order to start using it is Nodejs (7.9.0). Simple pull the code, open a command window inside the folder containing the package.json and run npm install. I provided a simple run script to use while we develop this, which will open the window. If you're on windows you can use that, or simply run the command npm start.

The recommended IDE for this is VS Code. It's open source and cross platform, made by microsoft. I know, hell froze over. You can use it with git or simply use Git bash. Fun fact: VS Code is written with Electron

I'm fairly certain that when we ship this the users will not need to install Node.js. It will either be packaged or done by the installer (which electron provides).

 

[BantyRooster]

Quick update on this, I put together a readme with instructions on how to install and debug this program. I've also provided a launch script for VS Code and instructions on how to install it. If anything is unclear feel free to edit the read me or let me know

https://gitlab.com/westeroscraft/electronlauncher

 

[BantyRooster]

In the last brief meeting we had yesterday, we agreed to delegate tasks among each of us. Matan agreed to rebuild the UI on the electron launcher, Nightmare said he would be able to work on the settings management, and I took the task of managing the asset downloads from mojang.

I'm proud to say that the first (real) work on the backend is underway, and the progress is looking great already. I was able to parse mojang's index file and successfully retrieve/format the download urls and destination paths. On top of that, I am able to download them all

This is the first step in a long process but things are definately being worked on. Once the UI is complete I'll work on connecting the download progress to some sort of progress bar.

[user]5606633[/user] I do have a question though. On the current launcher all of the assets are stored in the root folder, ~/WesterosCraft/assets/. Does this mean the assets are redownloaded everytime the user decides to change version? I do see that the vanilla launcher does this also, so maybe I'm missing something. Any insight?

Also, is there an equivalent asset index for the instance files, under ~/WesterosCraft/instances/{version}, or are those just generated by the game? If you arent quite sure because I know it's been a while since the original launcher has been worked on I can look through the source and see what's up. Found what I need.

EDIT:

Async downloading has been implemented, it's a bit slower than downloading everything at once but it doesnt cause any lag spikes on a user's pc

 

[BantyRooster]

As of ef420d4b asset downloading is complete. Down the line I will deploy some improvements to the progress tracker as I learn exactly what needs to be transmitted to the UI.

The new launcher is now able to properly download all assets, libraries, native libraries (per OS), client.jar, and logging client. These were all the files provided by Mojang's version index therefore I assume the other files will be generated by the client. I will move forward with this assumption and work on basic account authentication with Mojang. I will not be saving this data as I've given that task to another coder. If I am able to generate valid access tokens I will move forward on launching the client with a goal of logging onto vanilla minecraft. Once that's complete I will either begin to work on the forge implementation.

This launcher is being built for 1.11.2 clients meaning I will not be supporting any sort of legacy file index. I don't see any possibility of us reverting to older versions so there's no point in doing that haha. I cannot guarentee that this launcher will work on our current 1.7.10 server because I am not building it with that intent, and as you know A LOT changed with 1.8.x. Therefore in the event this project is finished before the server migration, people will most likely not be able to use it.

I am still pushing for Beta release in mid June to allow for a testing period. With the afformentioned progress only taking three days of work, I expect us to reach that goal. Again though, that will require support from the other coders which I'm hoping will happen. If I spread myself too thin things won't be finished. I only say this because I haven't seen any code committed by the others yet.

Good stuff though, moving to Electron was definately a good choice!

 

[BantyRooster]

HUGE PROGRESS -> VANILLA IS FUNCTIONAL

 

[BantyRooster]

[user]mikeprimm[/user] I need some insight into the system we use to download the mods. I see that they are hosted on the site although I don't really know where to get the asset index from. Also, maybe we could get together in discord and put the new mods for 1.11.2 up onto the filesystem. This will allow for quick testing of forge mod support and most likely allow us to use the new launcher to log onto the test server.