Public Service Announcement
Before we dive in to this week's Technic news, I just wanted to remind everyone that if you're having problems logging in, using all or most official packs, using the platform or launcher, or creating or administrating a Platform pack, that the best place to get help is http://support.technicpack.net/ There are some articles you can read up on and if they don't help, "Make a Request" will let you open a support ticket and get direct help from a Technic staff member. A lot of people have been reporting packs or users as a way to get ahold of us, and that isn't a great way to do it. We don't have a good way of responding to you when you use a report, but on http://support.technicpack.net/ we have a whole ticket system where we can see when you get back to us and you can see when we get back to you. Your tickets will also help us refine the available articles so future users will get help even easier. Please use the new support site, it's really great and it's been tragically underused!
So with that out of the way, let's talk Technic Tuesday. This week, our new launcher build is 4.272 and while there will be a full changelog at the end of the post, I don't want to bury the lede: there is a major fix for Mac users that will drastically increase the number of packs that work on many Macs. This weekend, we were alerted to an issue with the changeover from Java 6 to Java 7 on Macs that has been negatively affecting our users- when Java 7 came out, the required file extension for JNI libraries changed. That sounds confusing, but the upshot of it is that Mac users on old versions of Java can't play new versions of Minecraft, and Mac users on new versions of Java can't play old versions of Minecraft. Dealing with this was a simple hack, but it's going to make a huge difference if you're playing on a Mac!
Let's Talk Uptime
Here's the stats for Technic's servers this past week, from Tuesday, February 3 through Monday, February 9-
- Platform Uptime: 99.95%
- Launcher API Uptime: 97.0%
- Launcher API Estimated Satisfaction (T=0.2 seconds): 93%
- Launcher API Usage: Over 46 Million Requests
- Official Solder Uptime: 100%
- Official Solder Estimated Satisfaction (T=0.1 seconds): 92%
- Official Solder Usage: Over 18 Million Requests
So if you've got a trained eye, you probably notice that that Launcher API Uptime is a lot lower than last week- 97% is not a very impressive number. I've got a lot to say about this, so if all you want to hear is "we're working on it", we are, so feel free to skip to the next section.
A large part of the low uptime is due to a large outage we had on Saturday- in fact, when you remove Saturday from the equation, our uptime for the week was 99.6%, slightly better than last week. What it comes down to is that even though we've now dealt with the most obvious issues in the API, there still seem to be some problems that cause our API workers to gradually slow down when under load and stop responding. Since they are not technically crashed, our robots don't reboot them, we have to be around to do it manually.
This weekend, we added an awful lot of logging and diagnostics to the API to allow us to investigate, and it's already yielded some results- it told us that an issue we were previously aware of is much more serious than we thought. That is the issue of unupgraded launchers.
As you're probably aware, we had some issues during the rollout of the new site and launcher, the API had some bugs in how it handled traffic, but just as importantly, the launcher had bugs in how it used the API. While the site has long since been fixed, there are more than a few users who are using launchers over a month old and they are using far more than their fair share of our resources, sometimes in sharp spikes that make it harder for us to find a cost-effective way to provision our servers. To deal with this, we're going to be adding a simple parameter to all API requests where the launcher will pass in its build number, and requests that are missing that parameter (or include a rather old build number) will be rejected. It won't stop someone who's determined to bust our chops, but this is intended as a defense against well-meaning users accidentally hurting us. It should go live on the API in the next week or two, once we feel confident that almost everyone has the change. If you are a pack author who is using the Platform API to show pack data on an offsite page, please be aware of this change and realize that you can get the correct build number to use for your requests from this API request. Do the right thing and cache your data.
It's a little extra work, but it's going to go a long way toward allowing us to keep our traffic stable and provide a good experience for everybody. In addition to this change, we're going to be adding a feature that will cause launchers that have been open for 24 hours to check for a new build and alert the user to restart, just like Chrome does. We believe that this combination will protect our service from old, buggy launchers while supporting people with unusual usage patterns better.
Reports and The Modpocalypse
When the new Platform first launched, it included a new feature allowing you to report people, comments, modpacks, and other objects. For the first time, our users could collaborate with us on keeping garbage off the Platform and improving the overall quality of your pack search results. It only had one problem- the administration interface for handling reports was a real pain! Last Monday, we rolled out a new report administration interface that allows us to process user reports much more quickly. At the time it rolled out, we had over 1500 reports waiting in our queue! On Friday night, that count hit 0, and it's been kept near 0 ever since. So now we can safely say that we are listening! Your reports are getting processed and garbage is being removed from the Platform as it is pointed out to us.
The big reason why we had to roll out the new reporting interface is that this week is the MODPOCALYPSE. A few weeks ago, I posted a news item saying that starting on February 9th, any pack which is not compatible with Java 8 will be disabled as non-functioning. That's already begun. If you've waited too long and had your pack disabled for Java 8 incompatibility, all is not lost! Update to Forge 1230 or include LegacyJavaFixer in your pack and report your pack requesting to be reinstated. We will field your report in a day or two, verify that the pack is functioning again, and reinstate you.
Launcher Changelog v4.272
This week was heavy on news but light on updates. The only major change to the Platform is that we fixed a bug that would allow users to access packs that had been disabled, causing some confusion. In the launcher, the big headlines are the Mac fix previously mentioned and a small feature: if you'd like, you may now pull up a pack by pasting its Platform URL instead of its API link. The launcher changes for this week are the following:
- Mac users will now be able to launch LWJGL on different java versions than what LWJGL was built with.
- Pasting a pack's Platform URL will now pull up the pack the same as if you'd pasted the API link.
- Added Polish language support.
- Your launcher's build number will now be sent to the API when attempting to query. We will soon be rejecting API requests from old launcher builds.
- Adding java versions from a file will no longer fail on windows.
- Unzip failures will now have additional information logged to the console where necessary to diagnose issues.
- Changed the color of the selected modpack.
- Improved the look of the search and filter bar.
- Limited the search bar input to 90 characters.