[Project] New Launcher (Ported)

[BantyRooster]

The production catalog file is at http://mc.westeroscraft.com/WesterosCraftLauncher/westeroscraft.xml : this is what the current launcher hits to find out about the different available clients, as well as the available files, optional vs required, their hashcodes, and source + target locations. Most of the relevant parsing code is https://bitbucket.org/westeroscraft...r.java?at=master&fileviewer=file-view-default

 

[BantyRooster]

Is there a reason this is written in XML? It would be infinitely simpler to parse the distribution index if we could rewrite it in JSON format, since the new launcher is written in node.

 

[BantyRooster]

No specific reason, beyond its the original source format - rewriting it in JSON would be as much work as writing JavaScript code to parse the XML (it's not like XML parsing is that unusual in JavaScript - just use the DOMParser: HTML is an XML application these days!)

 

[BantyRooster]

I see what you mean, although it will be a lot of work regardless, as the asset index is going to need several updates haha. The new launcher was built to use the new library structure as introduced by the minecraft launcher that was released on April 18, 2013. Therefore, rather than placing everything inside of a lib folder, a library is placed into a more specific folder. For example one of the many lwjgl libs is now placed in ~\.minecraft\libraries\org\lwjgl\lwjgl\lwjgl_util\2.9.4-nightly-20150209\lwjgl_util-2.9.4-nightly-20150209.jar rather than just ~\lib\<name>.jar. The mcforge installer follows this structure, therefore one of its scala libraries would be found under ~\.minecraft\libraries\org\scala-lang\scala-swing_2.11\1.0.1\scala-swing_2.11-1.0.1.jar rather than just ~\lib\scala-swing.jar

My guess is that this launcher will be done around the same time the server port is done, so there will be little need to support the 1.7.10 version. Also, having this new launcher incompatible with the existing 1.7.10 versioning will force people to upgrade when it's done.

I will see if I can draft an updated version of this in JSON and get it to work. Reading the JSON will be as simple as JSON.parse(content), which returns a nice javascript object. Once I do that I'll get the required client files together and let you know what needs to be put up onto the host.

 

[BantyRooster]

Is there anywhere I can check a list of the latest forge dependencies/libraries?

Also, I'm working on the json index and this is what I'm working with so far: https://hastebin.com/iquqagipef.json

Edit: this might be it https://github.com/MinecraftForge/Installer/blob/master/src/main/resources/install_profile.json - if you have anymore info please do reply.

Edit: The information can be found by looking into the forge universal jar file and extracting the version.json file.

And another edit: I think we can dramatically reduce the size of our launcher distribution file. Since A LOT of the current one is filled with a bunch of forge dependent libraries, the only thing we really need to put in our distro is the forge file itself. From there we can extract the version.json file from the forge universal jar file and install the libraries it lists.

 

[BantyRooster]

If you do the manual install of the test client I describe in the "Migrate to 1.11" thread, and then look the the application folder for the vanilla Minecraft launcher, you'll find a directory named 'versions', under which will be a 1.11.2-forge1.11.2-13.20.0.2282 directory (if you installed the 2282 forge build), within that is 1.11.2-forge1.11.2-13.20.0.2282.json:

{
  "id": "1.11.2-forge1.11.2-13.20.0.2282",
  "inheritsFrom": "1.11.2",
  "jar": "1.11.2",
  "libraries": [
    {
      "name": "net.minecraftforge:forge:1.11.2-13.20.0.2282",
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "name": "net.minecraft:launchwrapper:1.12",
      "serverreq": true
    },
    {
      "name": "org.ow2.asm:asm-all:5.0.3",
      "serverreq": true
    },
    {
      "checksums": [
        "2d9530d0a25daffaffda7c35037b046b627bb171"
      ],
      "clientreq": false,
      "name": "jline:jline:2.13",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "ed62e9fc709ca0f2ff1a3220daa8b70a2870078e",
        "25a86ccfdb6f6dfe08971f4825d0a01be83a6f2e"
      ],
      "clientreq": true,
      "name": "com.typesafe.akka:akka-actor_2.11:2.3.3",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "f771f71fdae3df231bcd54d5ca2d57f0bf93f467",
        "7d7bc36df0989d72f2d5d057309675777acc528b"
      ],
      "clientreq": true,
      "name": "com.typesafe:config:1.2.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "dfa8bc42b181d5b9f1a5dd147f8ae308b893eb6f",
        "8c9aaeeb68487ca519411a14068e1b4d69739207"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-actors-migration_2.11:1.1.0",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "56ea2e6c025e0821f28d73ca271218b8dd04926a",
        "1444992390544ba3780867a13ff696a89d7d1639"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-compiler:2.11.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "87213338cd5a153a7712cb574c0ddd2edfee0386",
        "0b4c1bf8d48993f138d6e10c0c144e50acfff581"
      ],
      "clientreq": true,
      "name": "org.scala-lang.plugins:scala-continuations-library_2.11:1.0.2",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "1f7371605d4ba42aa26d3443440c0083c587b4e9",
        "1ea655dda4504ae0a367327e2340cd3beaee6c73"
      ],
      "clientreq": true,
      "name": "org.scala-lang.plugins:scala-continuations-plugin_2.11.1:1.0.2",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "0e11da23da3eabab9f4777b9220e60d44c1aab6a",
        "1e4df76e835201c6eabd43adca89ab11f225f134"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-library:2.11.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "f05d7345bf5a58924f2837c6c1f4d73a938e1ff0",
        "a1cbbcbde1dcc614f4253ed1aa0b320bc78d8f1d"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-parser-combinators_2.11:1.0.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "6580347e61cc7f8e802941e7fde40fa83b8badeb",
        "91ce0f0be20f4a536321724b4b3bbc6530ddcd88"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-reflect:2.11.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "b1cdd92bd47b1e1837139c1c53020e86bb9112ae",
        "d77152691dcf5bbdb00529af37aa7d3d887b3e63"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-swing_2.11:1.0.1",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "checksums": [
        "7a80ec00aec122fba7cd4e0d4cdd87ff7e4cb6d0",
        "62736b01689d56b6d09a0164b7ef9da2b0b9633d"
      ],
      "clientreq": true,
      "name": "org.scala-lang:scala-xml_2.11:1.0.2",
      "serverreq": true,
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    },
    {
      "name": "lzma:lzma:0.0.1",
      "serverreq": true
    },
    {
      "name": "net.sf.jopt-simple:jopt-simple:4.6",
      "serverreq": true
    },
    {
      "clientreq": true,
      "name": "java3d:vecmath:1.5.2",
      "serverreq": true
    },
    {
      "clientreq": true,
      "name": "net.sf.trove4j:trove4j:3.0.3",
      "serverreq": true
    },
    {
      "name": "net.minecraftforge:MercuriusUpdater:1.11.2",
      "url": "http:\/\/files.minecraftforge.net\/maven\/"
    }
  ],
  "logging": {
   
  },
  "mainClass": "net.minecraft.launchwrapper.Launch",
  "minecraftArguments": "--username ${auth_player_name} --version ${version_name} --gameDir ${game_directory} --assetsDir ${assets_root} --assetIndex ${assets_index_name} --uuid ${auth_uuid} --accessToken ${auth_access_token} --userType ${user_type} --tweakClass net.minecraftforge.fml.common.launcher.FMLTweaker --versionType Forge",
  "releaseTime": "1960-01-01T00:00:00-0700",
  "time": "2017-04-10T12:34:09+0000",
  "type": "release"
}

Edit: switched to pretty printed version of content

 

[BantyRooster]

Unfortunately I'm going to have to switch back into UI mode as the little bit of work I've seen from the others is less than satisfactory, and I need to start playing with a tangible UI. I spent some time today recreating the header and planning out the body of the launcher. The body will be largely similar to the way the JavaFX one turned out, with a few modifications I was planning anyway.

I've drawn a crude example using an online tool, and will compare it with the current one. It's not easy to draw with a mouse so forgive me if this looks bad haha.

Okay, so the changes.

The first and quick one is that the electron launcher does not have a custom window frame. You can tell this because the JavaFX uses a custom red window frame that I built, while the electron one uses the default window frame. I may look into creating a custom one for the electron launcher, however that's low priority right now. There are tradeoffs between the two though. Namely, the custom one looks better, while the default one functions better.

The next difference is around the login box. The box will have two main states.
The first is when the user is logging into their account. This will be visible if they are currently logged into zero accounts, or if they wish to log into another one. That state will largely look similar to the login area on the bottom image.
When a user is logged in the login box will change to appear as it does in the upper image. The skin of the logged in profile will be shown in the smiley face box, and the blue lines to the left will contain information about the logged in profile. This will most likely just be something along the lines of: "Selected Profile \n <profile name>." Under the image will be a drop down box. From there a user can change their selected profile. All logged in accounts will be listed there, plus an additional "add profile" button. This will bring the user to the first state as described above.
I'm thinking about encapsulating the login area into a module which has a gray gradient background. I'll probably try that out and post how it looks on here for feedback if I think it's alright.

The next change will be to put the clients (production, test, etc) either into a dropdown or expandable pane. This will just be to save space.

The next change will be to stop showing the news page on the news tab and instead to build a custom viewing system on the launcher. That will function by reading the RSS feed of the enjin news module and constructing news modules from that data. The ideal way I'd implement this would be similar to how the news currently works on the site. The title of the article would be displayed along with a preview of the content. From their a user could use the expand button to read the full article. This could be done in two ways. First, the article could be loaded to fill the entire news section with the user having to hit a back button of some sort to check the rest of the news. The second (which I think may be cooler) would be to have the news module expand and then load the rest of the content right on the news page. We could probably add an animation to make that transition look smooth.

The final thing I want to touch up is the settings tab. I'm not sure that I 100% like the way it was implemented on the JavaFX launcher. I'm not sure how it could be changed, although I think it would be better to have the settings menu take up more of the window rather than packing it into a small tab space. Look at how discord and the battle.net launcher deal with their settings windows and you'll know what I mean.


[rule]

Again though, UI is not my favorite part of development. If any of you reading this are experienced at HTML, CSS, and Javascript (just for websites, not Nodejs as it's not needed) and are willing to contribute to recreating the UI please let me know! It will save me a lot of time and allow me to get back to work on the backend.

Other than the UI, I am working on creating an updated JSON distribution index. That includes handling the installation of forge and the required mods. Once that is complete, all that will need to be done on the backend will be settings management.

Just to reiterate, once the following four things are complete we can move ahead with alpha tests:
1. Forge & Mod installations.
2. Full hash validations (partially complete).
3. User Interface (UI).
4. Settings management.

What's done:
1. Mojang asset downloading.
2. Downloading and organization of required libraries and native libraries. (native stuff needs a polish, but it's pretty much done).
3. Basic authentication.
4. Launching vanilla.

If you are willing to contribute, please let me know. The repository can be found here.

 

[BantyRooster]

All looks good - I'm REALLY committed on the WesterosBlocks (and other 1.11.2 migration work), but will try to find some time to help once I've got all that work to an 'alpha' to 'beta' level (I want to get to 'first pass complete', so we can get folks evaluating the behaviors and start working the 'gaps' between where the code is and where it needs to be for a production migration). I'm going to try to cobble up a 1.11.2 test client on the existing launcher - both for convenience with alpha testing and for the sake of providing you with a more practical template of the 1.11.2 forge deployment definition.

 

[BantyRooster]

Still trying to get people on board for the UI.

Other than that I have a small update. This launcher will have a more native look and feel than any java implementation ever could. For example, I can display download progress via the taskbar icon on windows.

This is just one of many subtleties I hope to have included in the final product. Other things I can add are desktop notifications to let users know a download is done and badge icons (which I'm trying to get working at the moment).

I tried to get back into UI mode as I mentioned on my previous post, but I can't really bring myself to do that at this point. There's some excellent progress on the backend and I can't pull myself away from that. I am really hoping that someone will come to the plate and get some work done on the UI because I REALLY need some of that done soon. That being said I hope to have forge downloads and the hash validations done by the weekend. I'm writing some improvements to the download streams so that they can be more flexible. I will provide details on that in a few days.

If any HTML/CSS dev is reading this I'd love to recruit you to work on the UI

 

[BantyRooster]

As I promised, the new launcher's download module is nearly complete. All of the mojang asset downloading has been moved from my initial testing module to this new module. Hash validations are 100% implemented although the forge assets are still pending. In designing this new module I considered the properties and information that needs to be accessible on the fly by other code, such a download trackers on the UI, and have come up with a method that I hope will be simple for others and flexible for future updates. I am not going to explain it in depth in this post because it's quite late (actually early).

https://gitlab.com/westeroscraft/electronlauncher/blob/master/app/assets/js/assetguard.js

In order to preserve the longevity of this launcher I am making it a priority to document existing code. This is so that maintaining this project will be easier as maintainers will not need to comb through countless lines of code to figure out what's going on.

That being said, since this module is in a final form, for now anyway, I am adding JSDocs to it (ver similar to java docs). I was able to document about half of the module tonight so if anyone is interested in seeing what's been done information is in the module. If any other coders have suggestions for this I'd be happy to hear them.

Once the forge stuff is put into this module I'll work on finalizing a launch process module. That will simply entail converting the testing module I used to launch vanilla minecraft into a more final and stable, production grade design.

 

[BantyRooster]

Currently implementing the forge downloads and I'm 100% certain that the files we'll need to host are going to be reduced dramatically. All of forge's libraries are hosted on http://files.minecraftforge.net/maven/ meaning we can download the files from there. Several files are not given a download URL in forge's version index. This seemed problematic to me at first, but then I realized that these files are hosted on https://libraries.minecraft.net/ . The forge hashing is a little more complex for libraries containing a chechsums.sha1 file, although it's something I will have no issue implementing. If you look at the current distribution index, all of the forge submodules will no longer need to be hosted and listed in this file. All that will be needed is the forge module itself, because once the launcher downloads that it will extract forge's version.json file and parse it for the required libraries.

All of the mod files will of course still need to be listed there. Some mods, such as optifine, have direct download links so rather than hosting them we could supply those. Personally, I would recommend that for the mods we continue to host them so that "updating" client files will not fail if the mod's download site fails. I am neither concerned about Forge's nor Mojang's download site failing. Their installer and the vanilla minecraft launcher depend on those sites so I have faith that they will remain stable. Besides, we depend on mojang's sites anyway for the vanilla assets, and in the current distribution index we download the forge universal directly from the forge dl site.

Spoiler: forge module data

<Module id="forge" name="Minecraft Forge 10.13.2.1291">
<URL priority="0">
http://files.minecraftforge.net/maven/net/minecraftforge/forge/1.7.10-10.13.2.1291/forge-1.7.10-10.13.2.1291-universal.jar
</URL>
<Required>true</Required>
<ModType order="1" launchArgs="--tweakClass cpw.mods.fml.common.launcher.FMLTweaker">Library</ModType>
<MD5>e71e88c744588fdad48d3b3beb4935fc</MD5>

Since this whole system is being revamped, I am going ahead with constructing a new distribution index in JSON, replacing the current XML one. As mike previously said, JavaScript does have XML parsing although I prefer working with JSON. In my opinion the latter is more readable and easy to work with especially in JavaScript since it resolves directly to an object. I read that the 1.11.2 test server will soon be included in the current XML index. This is fine, I have no problem moving that over to JSON for the new launcher. Just note that in order for me to fully test the forge integration I will need some of our 1.11.2 client mods to be hosted on http://mc.westeroscraft.com/WesterosCraftLauncher/files/1.11.2/

I hope to have this all in a functional "test" state by tuesday, having it fully integrated by wednesday. After that I'll finalize the launch process code. From there I really need the UI done so I can begin connecting all of this stuff. I was able to contact the guy I originally asked to work on that and it seems like he's finally coming around but I'm not really sure if I can 100% rely on him. Hopefully I can as that will speed things up nicely.

At the current point I think we will be send out alpha builds to select members of the community who are willing to assist in finding bugs and flaws by the first of June, if not sooner. This is an ambitious goal and in order to meet that I expect that the UI will be lacking some features in the first alpha build. More details on that will come down the line if I feel that we can definitively make that happen.

 

[BantyRooster]

The existing files were available to be hosted from Forge in the past, as well, but we honestly hit problems with them doing some refactoring and with availability (we hit similar issues with refactoring by Mojang), which is why we made sure the 'golden' files we depended on were hosted on our own server. At this point, its probably low risk, but then again, who would have thought that 'Bukkit' would get DMCA-ed one day and never come back? If Mojang goes away, we're boned anyway, since that is where login lives, but the Forge download site ultimately depends on them paying their hosting bills and not getting DMCAed by someone.
Note: we still pull forge itself presently, but we're serving some of the dependencies (scala libraries and such). The situation can be handled, one way or the other, if something 'bad' happens (we just need to be able to check in our cached copies to our server, and switch the file manifest to point back there), so it's not a huge deal. That said, I would have to say that client download bandwidth is the least of our issues (given how relatively expensive clients cruising all over our huge maps are!)

 

[BantyRooster]

Forge stuff is moving along nicely. I am in the process of writing the code to parse the forge version index, as well as creating the new distribution index in JSON.

So far all of the code used to validate forge libraries has been implemented, the only thing is that it is kind of expensive. Forge's scala libraries declare a checksums.sha1 file which contains thousands of declared mapped hashes (the scala compiler lib specifically has 8207). Basically what this means is that when we try to run a hash validation on it, we need to do several things. First of all, locate, read, and parse the checksums.sha1 file into something we can work with (an object). Next we need to go through each file, calculate a hash for it, and compare it to the hash declared in the object. This took about 2.8 seconds to process. It's not terrible but then again I prefer calculations to be in milliseconds. The current launcher bypasses this because it supplies a MD5 hash for the entire file, so we only hash one thing instead of 8027.

A typical forge dependency is declared as so:

{
      "name": "org.scala-lang:scala-compiler:2.11.1",
      "url": "http://files.minecraftforge.net/maven/",
      "checksums": [
        "56ea2e6c025e0821f28d73ca271218b8dd04926a",
        "1444992390544ba3780867a13ff696a89d7d1639"
      ],
      "serverreq": true,
      "clientreq": true
    }

This particular file contains a checksums.sha1 within it, which is what it uses to validate itself. The second hash in the checksums array is the hash of the file checksums.sha1. I have no idea what the first hash is, it's not the bottom one in another algorithm (MD5) nor is it the hash of the jar file itself. If anyone knows what it is, let me know.

Another dependency is declared like this:

{
      "name": "jline:jline:2.13",
      "url": "http://files.minecraftforge.net/maven/",
      "checksums": [
        "2d9530d0a25daffaffda7c35037b046b627bb171"
      ],
      "serverreq": true,
      "clientreq": false
    }

This checksum is just the hash of the file itself, since it does not declare a checksums.sha1

Then other files are lacking a hash altogether:

{
      "name": "net.minecraftforge:forge:1.11.2-13.20.0.2279",
      "url": "http://files.minecraftforge.net/maven/"
    }

To be honest it looks like a mess. If we want to continue with it, that's fine as the code is complete and ready to go. If not, and you guys prefer that we host them and run simple MD5 validations, I can change the code to reflect that.

As for the JSON asset index, this is a preview of what will probably be used initially https://hastebin.com/igufesilam.json . The comments will not be present in the actual one, they are just there to explain some things briefly. Some things, such as launch args, are missing. That's simply because that stuff if declared in the forge version index.

I'm going to stop working on this for the night to see what you guys think about all this.

 

[BantyRooster]

Had to push out some damage control to the UI tonight --> progress https://i.gyazo.com/10ff96bf89c271ebe2c8fa91ff145d57.gif

edit: some more

https://i.gyazo.com/28de77d80dcc04e4858408be921d73d3.png

 

[BantyRooster]

Added functionality to extract .pack.xz files. The npm modules available to do this were a mess, being either outdated or refusing to build on windows. In order to achieve this, I wrote up a small java library which will extract these files. We simply pass the files we want to extract to the command line using a corresponding argument and it does the rest. This should be no issue as we will always have a JRE present with this launcher, whether that be bundled or already installed.

Check the commit here (the logging messages arent final).

I also made a repository for the library.

In addition to all this I'm starting to put some work into the UI. If I don't do it, no one will ':{ early progress on that

 

[BantyRooster]

So I was thinking that we could probably bundle the JRE with this new launcher. Since it is written in Node.js, it will not require Java to function meaning we have the capability to handle a lot of the java work ourselves. This would probably eliminate all of the "Launcher not working" errors caused by users installing an incorrect version of java. Of course the java path is configurable, so people will be able to use whichever version they want, with us providing a default one to turn to.

The issue is that I have no idea if we are permitted to do this, all I know is that the vanilla minecraft launcher handles java by default. They provide a 'launcher.json' file that acts as an asset index for the jre downloads. I'm also not sure if we are permitted to use those downloads. It might all be fine, but I want to make sure first.

If we do bundle the runtimes then I need to know exactly what we support and what we dont. I notice that in all of support threads we direct people to 64bit java. Is 64bit an actual requirement, or is it just one of those things we tell people to do because 64bit is better? I'm not expecting many 32bit computers to try to connect to the server, but I just want to cover all the bases. One other thing is that the launch.json file does not declare a specific jre for linux. I have never used a linux machine for Java related work so I'm not sure what its absence signifies. Is java already installed on linux by default? Or is mojang just trusting that if you use a linux you probably know what you're doing.

Anyway looking for some insight on this. I've attached the launch.json file below for ease of access.

 

[BantyRooster]

Distribution index parsing is more or less done, it's just pending some cleanup and further optimizations. Hash validations are not complete for the indexed files. This is because the current supplied hash values are for the packed libraries. We don't really want to validate a packed library because it only exists for an instant, being immediately unpacked. If we try to validate the unpacked version with the hash for the packed version, the validation will always fail. I will look into putting in validation code, the only thing is the MD5 hashes on the version index should be updated.

Also, the JSON format for the distribuiton index is pretty much finalized. There may be some things we change or add later but it's in a solid state at the moment. I've attached the current one filled in with all of the current data for 1.11.2. The hashes may be off because I havent updated them in a few days, and they need to be changed regardless. If you need me to explain anything about it I'd be happy to.

The current distribution code can be found on the repo, however it is likely to change somewhat as I add the hash validations and optimize it.

https://gitlab.com/westeroscraft/electronlauncher/blob/master/app/assets/js/assetguard.js#L626

Also, sorry this took a bit longer. I decided to get away from programming for a few days.

 

[BantyRooster]

The hashes for the current stuff is for the libraries after unpacking (I'd made the mistake of forgetting that when I first did the update for the 1.11.2 client, but confirmed it when checking the hashes for the old stuff), so the fact that the library is packed shouldn't impact you validation code (in both cases, comparing the hash in the catalog to the computed hash for the extracted file on the client should be the process).

 

[BantyRooster]

Thanks mike, but it looks like some of them still use the wrong hash value. If you check here http://mc.westeroscraft.com/WesterosCraftLauncher/westeroscraft.xml some of the .pack.xz files do have the correct hash (like scala-xml, akka-actor, etc), although there are still files without the correct one (for example scala-reflect, scala-parser-combinators, scala-continuations-plugin, etc). I havent checked all of them but it's worth a second look.

EDIT: Implemented the validations, and these are the files which failed. I will see if I can add the correct hashes and publish it to the json index.

 

[BantyRooster]

Okay I've went through the files and calculated hashes for each of them. Only two files fail to validate, simply because these two arent hosted currently.

Json index attached below.