Locale plan update Klonan Earlier this week I received the English proofreadings from Altagram, and overall I integrated over 500 suggestions into the game. Most were small, such as replacing "can't" with "cannot", things like that. It was the exact sort of external scrutiny we really needed, as it showed some areas where we were quite inconsistent. It feels like things are in a better place now, even if the majority of changes are relatively unnoticeable. However it was very noticeable to our great community translators on Crowdin. When we update the English strings, the translations have to be updated on Crowdin. For the last few days I've been working through the issues raised on Crowdin, and there was a lot of good input on that last 1% of the changes. So this concludes the 'English proofreading' phase. Starting on Monday, Altagram will start proofreading the target languages, and filling in any missing strings where needed. This should take about 3 weeks. Since Altagram has their own translation system for their team, it isn't really feasible to include Crowdin in this part of the work, they will just take the content from Crowdin at the start of the process, and after 3 weeks, push what they have back to Crowdin. So any translation work by volunteers on Crowdin for these 3 weeks would be wasted. So we ask that, if you want to volunteer your time, save it for a little while. Any work done on Crowdin this weekend will be included. We deliberately made this buffer between the English corrections and the Target proofreading so that the players on Crowdin have an opportunity to contribute before Altagram starts. After Altagram has pushed their corrections back to Crowdin, we will start the 'Community review' part of the process. This is when the work that Altagram's team has done is reviewed by players and feedback is given to Altagram via Crowdin issues. This helps us make sure the terms of the translations are consistent with the established community usage, and ensure there are no contextual issues or misunderstandings.
New website Sanqui Over the course of the past year, you have seen the team put a lot of effort into polishing the game to get it ready for a full release. There's no doubt this is the most important effort here: we're all here to play the game. At the same time, the website is often the first thing people encounter—and in for many, return to every week! Unfortunately, until this point the looks of our websites have been neglected. The current set of websites are a complete mishmash of styles that are not coherent and do not fit with the look of the game. Which website am I looking at again? We set out to rework the looks of our websites last year to make them harmonize with the final game. Albert and Aleš worked together to design the new website and make mockups in a process not too dissimilar to the GUI work in the game. Of course, web technology is a different beast from anything the game uses. My task was to take the mockups for each page and implement them as closely as possible (my own creative liberties notwithstanding). The process from original page to mockup to the new version My approach to creating websites is conservative, and in a way mirrors the philosophy we use when developing the game. The Factorio website doesn't use a fancy modern JavaScript framework. I'm not a JavaScript hater. There is no harm in using JavaScript to make parts of the website interactive, and of course many web applications wouldn't be possible with it. But for a website like ours, avoiding the use of bloated JavaScript frameworks helps keep everything load and render quickly, and of course the website can be browsed without JavaScript as well. To get the looks right, I set out to create a CSS framework to visually mimic the Factorio GUI style. Where possible, I avoided the use of images. This keeps the page fast and ensures it stays sharp on all resolutions and levels of zoom. For instance, the buttons match their game counterparts closely, but are made only using shadows. The only exception is the arrow facing to the right, which simply isn't possible to reproduce using CSS (I tried!). However, even then the performance is kept slick because the graphics for it are embedded in the stylesheet. The layout for new pages with sleek grids is enabled thanks to modern CSS technologies like Flexbox and CSS grid (no floats, no tables). At the same time, the mod portal also received the new design. I also took the effort to unify login sessions between the main website and the mod portal, so you no longer have to log in twice. This Friday Facts is the last time you're seeing the current (old) style, so enjoy it while it lasts! The new website will go live sometime next week. Once the new design is out, don't forget to click on the rocket!
It's been over 4 years since we planned the infamous GUI update. If all goes well, next week the game will get the last big GUI update for 1.0. While the state of the GUI is not close to our crazy plans we recently had for the GUI, it's above what we initially planned 4 years ago. The update you will see next week includes: A visual update to over 100 game GUIs New high resolution icons for all game items (visible both in GUI and in the world) New GUI sounds for most interactions
New hope demo levels Klonan A few weeks ago we discussed the changes to the demo and tutorial in the game (FFF-342). One piece of feedback we received after publishing the news was about the old 'New hope' campaign levels, and specifically the 'Abandoned rail base/Broken rail map'. It seems a lot of you in the community really really enjoyed the new hope campaign levels, and several of the team here share the same feelings. After we scrapped the plans for a new campaign and reverted to the old demo, we had initially dismissed the idea to revive the New hope campaign... However due to popular demand... we have decided to bring back the favourites, the first 2 levels of the new hope campaign. This time though, they will also be included in the demo version of the game. This represents a very significant increase in scope for the demo, increasing the demo content to include research, red science, green science, trains, and much more. These levels should be ready for release within a week (but no promises).
He who does nothing, breaks nothing posila In the recent patch notes, there was a line "Fixed landfill spawning under player when building landfill elsewhere. More" and some people on Reddit were wondering how did this bug happen in the first place, and asked for the long version and even suggested we could even use it for Friday Facts, and I thought: "Yeah, if I am going to spend time writing this, we should consider using it in FFF so someone else doesn't have to spend time writing something else." ... but I am going to stretch it out. The landfill bug reported after the release of 0.18.21. Disclaimer: I have not been around during the ancient parts of this story (speaking of which, it's my 5 year anniversary at Wube, yay!), and changes I have been around for, or even done myself, I might not remember correctly. So this might not be accurate. In fact, let's say the story is purely fictional and any resemblance to real world events and people is just a coincidence.
Unit group collision mask Last weekend, a bug report came in on our forum. The issue was that the groups of biters were trying to path over the water, but the bugs can't swim. It seemed like something quite typical of a mod being funky. I looked into it, and it seems the Hovercraft mod was playing monkey business with water collision masks to make his vehicles ride over water. One thing involved setting water tiles to be walkable, and then adding an additional collision layer to all players and biters. What this modder didn't realise though, is that unit groups have a fixed collision mask. It used to be hardcoded, but a while ago it was added to the utility constants. So we just say "hey its a mod problem, here's a quarter, call someone who cares"... right? Well it didn't sit right with me, because deep inside I knew that the unit groups shouldn't have a fixed collision mask, it doesn't make sense really. Lets say you add flying units to the game. If you give individual commands to the flyers to go attack the base, they will happily fly over the water and attack without issue. However if you put them in a group together, a group of flying units, the group will path around the water, because the unit group still has a fixed ground collision mask. So this week I decided to fix it once and for all. It turns out it wasn't so hard in the end. As we mentioned somewhat in FFF-340, unit groups already have logic in place to recalculate their properties based on their members. I hooked into that logic to also make them recalculate their collision mask. The way that made sense to me, is that they should add the masks together, so that they only path where all of the units can path. A group of only small biters, they can't walk on water, so they walk around it. A group of 'water biters'. They can walk right over water, so they go straight through. A mixed group of small biters and water biters. They add their masks together, so only go where all the units can go. You can imagine it quite intuitively I think, the group will try to stick together, and that will mean the group can only path to places that all the members can reach. It feels quite nice to make fixes like this, as they are relatively small in scope and risk, but cleanup a lot of potential problems, and open a lot of interesting possibilities.
Tile transition collisions Klonan We first mentioned a change to our tile transition logic back in FFF-199, and not long after in FFF-214. These two posts focused more on the visual side, and how it makes the game terrain look so much better. In short, the tile transition logic overlays an additional sprite over adjacent tiles, so that where the two tiles meet has a much more natural look. Left: Tile transitions on; Right: Tile transitions off. So while the looks were taken care of, we also had to deal with the 'feel' of the tiles. The easiest example of this is the 1x1 landfill 'stepping stones'. It really looks like you should be able to walk/drive across the 1 tile of water. So we added in an additional layer of collision checks, which will consider the transitions when performing the logic of what can go where. Now some of the cheesier among you will know that biters don't know how to get across these 1 tile gaps. That is because simply we never enabled the biters to use this collision check logic. One reason is that more checks means more UPS usage for the biter pathfinding, another is that we didn't think it was necessary. However it was available in the engine, and any mod could enable it if they want. That is exactly what I did with my Mining drones mod. Initially this seemed to work, and I thought it might make them walk around lakes a bit more naturally (like the player character does). However quickly I noticed that people were reporting on the forum that the game was crashing with the mod installed. I quickly reverted the change to my mod and we started looking into it. It turns out that the new abstract pathfinder we added for better unit pathfinding (FFF-317) was not set up to consider units using this tile transition collision logic. This same crash was happening sometimes without any mods installed, but the case was more difficult to reproduce, so this is a nice situation where mods help us work on issues in the base game. Recently I have been working on another unit heavy mod, Transport drones, and the principle design behind the mod heavily relies on the tile collision logic (the units don't even collide with entities). It turned out to be a really nice test of our new pathfinder, but also highlighted some of the issues that not considering the tile transitions can bring. By not considering the tile transitions, the drone takes an awkward path along the diagonal road. This week Oxyd finished his work on an upgrade to the pathfinder, so we can enable the tile transition collision logic with units. The change is immediately noticeable with the above example. By considering the tile transitions, the drones path much more naturally. With the logic now in place, we are debating whether to enable it for biters or not. We probably won't, it is only a minor change and would have a non-zero performance impact (a rough test puts the worst case at about 5%), but then again it is a fun way to surprise those who thought the 1 tile of water would stop the biters attacking, and it kinda makes sense they can walk over it just as the player can. Well we will see if there are any issues with it in the modded cases before any further consideration. As a bonus fact (this is Factorio facts after all), I spent a bit of time benchmarking some late game Transport drone based factories (screenshot), and found a few nice performance gains.
Environmental particle effects Dom Since the particle optimization we did for 0.18 (FFF-322) and the introduction of new explosions (FFF-325), we were able to push our vision even more. It always bothered me that the grenade and other explosions would emit the same type of particles regardless of the context. In most cases it isn't that bad, and somewhat okay, but when you throw a grenade into water, it will still emit stone particles, which breaks the illusion. Another problem is that we have the nice decoratives on the ground, but they don't really 'interact' with anything that goes on, and can feel like fake flat stickers instead of something 'real'. You would expect that when there is a massive explosion 2ft away, the bushes might have some reaction to that. The explosion effect currently in 0.18
Not mentioning it would be weird I really think everybody has heard all about this and nothing else over the last few weeks, but yes, the Coronavirus. For now, with Factorio, everything seems okay. We are all working from home, the team is still going, and so far we are following our plan quite well. We released the Character GUI and Statistics GUI last week, and some improvements such as new water splashes and leaf animations this week. Things are still moving along. However it is still early days, we haven't really had any experience having the whole team work remotely, so there may be some challenges we need to tackle as time goes on. At the moment we don't know whether this will affect our 1.0 release date, I guess it will one way or the other, but for now we aren't announcing any changes.
