Factorio Version 0.16.27 released |
| Posted: 28 Feb 2018 10:44 AM PST Minor Features
Changes
Bugfixes
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.  |
Factorio Version 0.16.26 released |
| Posted: 26 Feb 2018 08:47 AM PST Features
Changes
Bugfixes
Modding
Scripting
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.  |
Factorio Friday Facts #231 - Belt compression & Crash log uploading |
| Friday Facts #231 - Belt compression & Crash log uploading Posted: 23 Feb 2018 01:20 PM PST Belt compression The decision of how to approach the belt compression in 0.16 was not an easy one, we were basically facing two possibilities:
But we weren't really sure how to do it. The problem is, that once the items are pseudo-randomly added to the belt, with lot of gaps not big enough for another items to fit, it is not clear how should the additional inserters compress it:  The solution was, that whenever there is any gap bigger than the standard distance between items on a belt, item can be inserted there and for a (usually) brief moment, the items are squashed together closer than usual. But once the belt starts moving, the gap between the two squashed item extends to the standard size. This change required us to do some fundamental changes to the belt logic, which could introduce a lot of new problems, but since we just wanted this to be resolved in 0.16, we had to do it now. The result is, that the same setup in 0.16.25+ results in perfectly compressed belt:  The belt mechanics are now easier to use, but the game also flows more nicely. The belt flow still needs to be controlled and belt balancers are still needed. As that feels to be the more interesting part of belt handling to me, I am happy with the final result. Crash log uploading Introduction Since 0.16.24, Factorio uploads its crash log to us whenever it crashes (This can be disabled from the options menu). For a very long time we wanted to be able to do this. I would often say that the crash reports we get in the Bug reports forum[forums.factorio.com] are a very small percent of the actual crashes, and that we don't really know what is important or not unless there is a major bug that many people report. This was proven to be true after releasing 0.16.24. We had received hundreds of crash logs but nothing was posted in the forum and we quickly found a major problem and fixed it. The way it works is that when Factorio crashes and a crash log was generated, in its dying moments it starts a new process that tries to upload factorio-current.log (and in some rare cases factorio-dump-current.dmp). Once on our server, we parse the stack trace from it and organize it with identical crash logs into folder. This way we can know which crashes occur more often, and allow us to prioritize more effectively. Our interface looks something like this[eu3.factorio.com]. So far it has proven to be very useful. In just 2 days Rseding fixed about 12 crashes that were found by our reporting tool, none of which were reported on the forum.  This does not mean you should stop reporting crashes on the forum. If anything it means you should report them more often. We very often need more information about the crash, such as steps to reproduce or a save game, but we have no way of contacting the person that uploaded the crash. So please continue to report crashes in the Bug reports forum[forums.factorio.com]. Privacy concerns Of course you can't mention the words "uploads data to our server" without some people being concerned about privacy. So I will try to address any uneasiness and apprehension about this new system by being completely transparent. The log only contains basic system information (CPU, GPU and free memory), game display settings, operation log, crash stack trace for the main thread and in some rare cases a minidump[msdn.microsoft.com]. We send that information (if you didn't opt out), in our binary format, securely, through HTTPS to one of our servers. In the next version we even sanitized the log a bit so it does not contain anything that might be seen as a privacy breach, such as IP addresses. We also updated our EULA and included it in the game to mitigate any legal issues. Even will all of this some people think that we are doing something wrong. To paraphrase what kovarex said: "The games I played send all kinds of data and they don't allow me to opt out, now we do it and are transparent about it and we are the bad guys?" A few people mentioned we should make it opt-in not opt-out. Unfortunately this won't work, since very few people will actually check the options and alter the default behaviour, this means we will be back to square one where we rarely know what crashes happen and how often they happen. Another idea was to have a prompt asking if you wish to upload the log or not, after every crash. Apart from the extra implementation time, players will still often click "Don't send", either because that's what they have been doing for many years[eu3.factorio.com] or because they just want to quickly get back in the game or because they feel that the crash was somehow their fault. This is an invaluable tool that helps us make the game much more stable and provide a great experience to everyone, while sending very little information to us. If you don't trust us you can of course opt out. The mysterious Ryzen issue (aka memory corruption/cpu corruption/bad hardware/not our fault for sure) The second most common crash that was reported in 0.16.24, with 61 unique crashes, was a mysterious crash in EntityRenderer::prepareRow[eu3.factorio.com]. It's one of those crashes that pops up on the forums every few months, we are unable to find the cause, so we end up not fixing it. Some of us often blame it on memory corruption or CPU error, but I'm often the sceptical person saying that we can't use this excuse every time we can't find the cause of a crash. Now that we have the crash uploading tool, we can do more. First of all we noticed that 100% these crashes were on an AMD Ryzen CPU. Even with all the crash logs we would still not figure out what was going on. So in 0.16.25 we started uploading minidumps when the EntityRenderer::prepareRow crash occurs. The few minidumps we received are still very strange and we are unable to figure out what is going wrong, with the easiest scapegoat being to throw the blame on bad hardware. This will probably be one of those bugs that will haunt us for some time... As always, let us know what you think on our forum[forums.factorio.com].  |
Factorio Factorio 0.16.25 released |
| Posted: 19 Feb 2018 12:59 PM PST Changes
Minor Features
Bugfixes
Scripting
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.  |
Factorio Factorio 0.16.2 released |
| Posted: 14 Dec 2017 04:15 AM PST Bugfixes
Modding
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.  |
Factorio Friday Facts #220 - The best Friday Facts ever |
| Friday Facts #220 - The best Friday Facts ever Posted: 08 Dec 2017 02:09 PM PST Christmas is coming early for Factorio fans. We have a lot of exciting things to show you and announce this week, so hold on tight. The artillery train Some of you might remember we said there is an artillery train planned, well we now have a playable version of it, so we can show it to you today. The artillery train (or more correctly, the artillery wagon) is an end-game wagon you can add to a train. It fires artillery shells over large distances, either automatically at nearby bases, or at manually designated targets.In automatic mode, when the train isn't moving, the artillery wagon will automatically scan for enemy buildings (biter nests and worms) and shoot at them. Manually designating targets is very simple, you click on the ground (or on the map or zoomed map) using a special targeting item. For each click, an artillery wagon in range will fire once at the target. Firing at the biters from far away isn't all consequence free, as they will come running to your train, so you will have to make sure there are some defences nearby, or are prepared for a quick getaway. Currently it has a range of 7 chunks (224 tiles) when firing automatically, and a range of 17.5 chunks (560 tiles) when firing manually. The main reason for this range difference is to incentivize players to use manual mode, since it is quite a fun way to use the artillery wagons, and it gives the satisfaction of blowing up biter nests remotely. Albert is working hard to finish the graphics, but here's a untextured work in progress preview. https://eu1.factorio.com/assets/img/blog/fff-220-WIP-artillery-wagon.mp4 Projectiles are slow and are shown on the map. They explore every chunk they travel across. https://eu1.factorio.com/assets/img/blog/fff-220-auto-shooting.mp4 Since they explore the area before exploding, you can zoom in and watch the impact. https://eu1.factorio.com/assets/img/blog/fff-220-manual-shooting.mp4 New terrain/Transitions As we proclaimed in FFF #199[www.factorio.com] we wanted to move grass-to-water transitions, from the grass tile to the water tile to make it impossible to build on tiles that visually have water on them. Moving the transition created some new problems. First we had to change rules for building offshore pumps, as they would be placed too far into land. Walking or driving around water felt very wrong suddenly, as player character would get stuck on corners that looked like they should be walkable. So we had to adjust player and vehicle collisions to account for that. We also wanted to allow transitions from any terrain type and water. With some adjustments to our new alpha-masking capabilities[www.factorio.com] we were able to create few sets of transition sprites, most of which are shared by multiple tile types. The new problem now is that the transitions are screaming for animated water now. Oh, well...    Official Factorio t-shirts Its been a long time in the works, and we've been asked about it countless time, but the Factorio T-shirts are finally happening, and will be available next week.It has been tough to find a printer who can meet our requirements. After many different companies, tests and iterations (such as the batch for the party), we have an order booked for 2,000 T-shirts scheduled to arrive on Monday. Once we check them and make sure everything is alright, we will open up to orders through our new Eshop on our website: https://factorio.com/store. The T-shirts are grey unisex, available in sizes XS to XXL, with the Factorio logo printed on the front. It was especially important to us that the silkscreen was of a high quality, and we are happy to say these are better than your typical print shop. The price is $20 USD per shirt plus shipping. There are some limitations on the countries we will be shipping to.  If everything goes according to the plan, we will send the first shipment on the 13th of December, and subsequent packages every Wednesday after. Packing the orders is all going to be handled by us, and since we are expecting a large initial demand, we hope that you will be understanding if we don't mange to get them to you before Christmas. For now we will be limiting orders to a maximum of 3 per person, so we can make sure they end up in the hands of fans, and won't all be scooped up by some scalper/reseller. We also reserve the right to cancel any suspicious/large orders to further this goal, and will be looking through the recipients to make sure nobody is taking more than their fair share. We have the full terms of service on the store, so please check it out before you make any order. We won't really appreciate if we see anybody reselling the shirts, as we aren't really making any profit from this venture, we are just trying to do a good service to our fans. In any case, once we have a good gauge on the demand, we will be able to produce some more batches early next year, so we can keep the supply flowing. Factorio 0.16 experimental We had some discussions some weeks ago about when we should release 0.16. Because of the approaching winter holidays, we realized we have two choices, either to release before the winter holidays or some time in January.We decided that Factorio fans would really like to play during the holidays, so we plan to release 0.16.0 next week. This date is quite tight, but this week's internal playtesting went well, with only a few bugs and desyncs. It does not include everything we wanted but a smaller and quicker release is probably better. Please bear in mind that this is an opt-in experimental release of an early access game, there will be bugs, especially since the release is a bit premature. We will have just 1-2 weeks of bugfixing before most of us will go on holiday, so it might not be perfect, but we will make it as playable as possible. Plus some of us (like Rseding91) will be fixing bugs during the holidays. The next few weeks will be a bit crazy for us, working overtime to fix bugs and pack t-shirts, so let us know how excited you are about the news at the forums[forums.factorio.com]. Level designer needed As an unrelated footnote to this weeks FFF, we are looking for an experienced level designer to help us develop the mini-tutorial and campaign levels. For more information, see the job description[www.factorio.com] on our website.  |
Factorio Friday Facts #219 - Cliffs |
| Posted: 01 Dec 2017 01:17 PM PST Cliffs - introduction and gameplay Several months ago TOGoS (Dan) half-jokingly mentioned that what Factorio really needed was mountains and cliffs. This was also suggested many many many times[forums.factorio.com].Albert immediately got very excited and they started having some discussions about how to make it happen.Fast forward a few months, and Ernestas had made some cliff graphics that looked really nice when layered onto pretty much any type of terrain. Fast forward a few more months and add a few months of programming and polishing, and cliffs are almost done, so we will be showing them to you today. Cliffs, together with the other map changes[www.factorio.com] TOGoS did, should make the map look much more diverse and interesting compared to 0.15. Hopefully it will make exploration more fun, since you will be finding more diverse and unique areas in the world. Since cliffs block your path, they can affect gameplay significantly. To not make this annoying, cliffs are never too long and often have gaps. We tried to balance the length so they will be long enough to create interesting combat situations, or with some modifications serve as a natural wall against the biters, but so long that they block your path when you want to get somewhere. Cliffs will also not appear in the starting area, to give you plenty of space for your initial base. Finally, in Factorio nothing should stand in the way of automation, so if you don't like cliffs, you can always blow them up using a new mid-game item called "Cliff explosives". Cliffs - graphics Map generation is hard mainly because it is procedurally generated. That means that the computer is mixing all the pieces to create the terrain on the fly. This leads the artists to a very difficult situation,because it is very hard to guess in which conditions the tilesets will be used. Factorio terrain 0.1 We started the generation of terrain in Factorio with very basic rules, mainly mixing clusters of 32px tiles. But obviously that wasn't enough.  Factorio terrain 0.3 With better looking tiles, transitions from one terrain to another, and variations of tiles, terrain looks much better. But this technique was a pain for the artist to generate an interesting and detailed tileset. The 32px grid was killing any attempt to have a natural looking terrain.  Factorio terrain 0.12 New technique: Instead of having only variations of 32px tiles, we produce a tileset with different sizes (x32, x64, x128, x256) in order to break this squary sense of grid, and even being able to render more detail in bigger sized tiles. So terrain looks much more natural. The visible tile-grid is almost gone, and we start spreading a new concept for us: the doodads. These are little sprites of plants and rocks randomly spread throughout the map in order to provide more variability and an organic feeling.  Factorio terrain 0.15 Things are getting better, the doodads were optimised and we're able to place much more of them, creating more interesting patterns and mixtures. It is also worth it to mention that the introduction of the high resolution graphics does a lot to help the look of the terrain.  Factorio terrain 0.16 After all those iterations, the next terrain generation integrates a couple of new concepts: the decals which are "just" doodads but ground-related. Decals are meant to generate terrain accidents and details without being oppressed by the rules of "tileability" and size. Basically decals are patches on top of a tileset that are very rich in detail. In combination with the doodads, the absence of the tile-grid and the high-res, we start to have a natural looking terrain. I have to add that the good and fast work of Ernestas, our environment artist, made possible the evolution of this new state of terrain. Now with our new techniques, the creation of a new tileset is very smooth.  Even with all the improvements, terrain still looks too flat, so another addition to 0.16 are the cliffs. Finally we can break the flatness of the Factorio surface, without having to change the mechanics of the game.  This new feature can add a bit to the fun of designing a factory by taking advantage of the topology of the map.  Or can lead combat to more interesting situations.  There are more additions to the terrain, and we will dedicate more time to this subject in future posts. Cliffs - Programming After seeing a graphical mock-up, I was tasked to figure out how they would be integrated into the game.We had some thoughts about making them tiles, or even a new kind of terrain layer, but in the end decided the simplest way forward was jut to make cliffs entities. The "cliff" entity prototype type has some smart logic in it about how all the different cliff orientations work, and that if a cliff gets destroyed, its neighbours need to be fixed up. There are also some special cases about how they interact with projectiles, but for the most part, cliffs just act as walls. The other aspect to cliffs is how to generate them on the map. Since we already have an elevation function[www.factorio.com], we can just place cliffs wherever we have a steep slope, right? Well, it is not quite that simple. Because of the way the cliff entities were designed, we can't just place them anywhere, we need to make sure they get placed many segments in a row. The rows of cliffs also need to be spaced apart (in cases where there's enough of an elevation change to have multiple rows of cliffs), or they don't look good. The first approach I took was to look at the change in elevation on each side of each 4x4 tile (the size of one cliff segment) cell. If an edge crossed a certain elevation and was steep enough, then we'd say that edge crossed a cliff, and select an appropriate cliff segment to put in the cell based on which edges crossed the cliff elevation upwards or downwards.  A couple of problems became apparent:
To prevent impossible situations, the cliff generator now builds up map of cliffs for an entire chunk at a time, and then, cell by cell, removes edges marked as cliff-crossing until no cell has more than 2 'cliff-crossing' (this concept becoming more and more removed from the original elevation function) edges. Of course edges shared with neighbouring chunks are off-limits to the edge removal algorithm, since they have to match whatever cliffs are generated (independently) for that chunk. As always, let us know what you think on our forum[forums.factorio.com].  |
Factorio Factorio 0.15.39 released |
| Posted: 27 Nov 2017 11:56 AM PST Bugfixes
You can get experimental releases by selecting the 'experimental' beta branch under Factorio's properties in Steam.  |
Factorio Friday Facts #218 - Import bpy, Export player |
| Friday Facts #218 - Import bpy, Export player Posted: 24 Nov 2017 08:35 AM PST Hello dear biters and related species from unexplored planet full of life and natural resources. Recently I have been working on several high resolution graphics for your best friends - the tank and the player character. In this article I would like to show their updated visuals to you, as well as a sneak peek at how they are produced. The following text may contain traces of automation. High Resolution Tank Like most biter stories end, this story started with the tank. I just took the 3D scene that Pavel made in 2014. There was quite a bit of work required to make it all render correctly, but eventually I arrived at the desired result. However there was one thing that really bothered me in the process - making the colour mask look good was rather impossible.  In general this is an issue that we already encountered earlier with the locomotive, cargo wagon and train stop. The cause was the RGBA values set for player colours, so I went ahead and changed all of them, I even added a "default" colour, so you can easily revert back to the single player default colour in 0.16 (which is also "Orange"). The dynamic colour algorithm (we call it tint) works in very weird ways, where if Alpha is set to 1.0, it kind of multiplies the mask by some selected colour. Alpha 0.0 somehow makes the whole mask sprite draw additively while colorized by the selected colour.  Regardless of the technical magic, the final verdict is that unless you are doing something extremely specific, the colour mask values should always be at 0.5 Alpha. You might have already noticed that the train colour sliders only allow you to change RGB values and not Alpha. That makes the colour much more stable - any RGB value you pick is going to work, once you start touching the Alpha it can look wrong and broken. I would like to take this opportunity to ask modders to keep this in mind, as I have noticed multiple mods using 1.0 Alpha values in colour mask tint. The Alpha is black magic, keep it at 0.5 please. Player character colours The tank and the car colours are both much nicer now, but the player character colours seem a bit off... The whole mask-works-with-0.5-alpha has one big condition - both the mask and the masked area of the sprite under it have to be desaturated. And the player graphics are already made to be orange. This is especially visible in the image above on colours like gray.This was never an issue since the player colours were using 1.0 Alpha, apart from the problem that all of the non-default colours looked horrible.  It might have been possible to do some quick hacks and just desaturate the player sprites where needed, but we found it more appropriate to take the opportunity to bring the player character into high resolution and fix it along the way. High resolution player character We were already aware that the player character is a very special task. Just the amount of spritesheets and Blend scenes already screams madness. Basically, the player character was split across many Blend files that Albert produced in 2015, each of them having one animation sequence. I honestly didn't even ask how much work and time did it take for him to create all of this. The game currently uses:
 From past experience we already know that re-rendering an entity in high resolution is almost never "just make it have more pixels". Shaders and details start working differently, and it's always necessary to do some changes. However, editing 21 Blend files at the same time does not sound very appealing or efficient, so our plan was to merge all of the animation into one huge Blend file. The aim is to have:
Graphics workflow Making the player character in high resolution would have been utterly insane without the use of scripting. In the following part of the article I will show you a few of the most useful Blender scripts that I wrote and used in the process.1. Copy objects between Blender scenes The first task sounds simple - copy-paste the objects from the source Blend file to the new one - until you try to do it. In Blender you can Copy + Paste objects between scenes easily, the catch is that in the destination, they are all pasted to the same layer, depending on which layer is active. However the objects forget which layer they are from in the source scene. This is a big problem, but after short thinking I wrote a new object transferring tool.  It is a set of two scripts, the first one prepares objects in the source scene (it changes their names to have a prefix with layer numbers). The second script processes them in destination by reading the name, moving the object to the appropriate layer(s), and cleaning up the name as if nothing ever happened. 2. Link mesh data of identical objects The copy pasting is great, but every new paste creates a set of new unique objects with unique materials. If you do this 21 times, the amount of duplicate data which is supposed to be the same goes up like a rocket. Generally 3D software has a way to create duplicates which are linked so if you edit one, you also edit the other. However once you break the link, it's not so easy to bring it back, because the program isn't sure if the two objects are really the same. In Blender this is possible, but doing it one by one would be way too much work so it's time for another script.  This one reads every object's vertices one by one, and saves them to giant lists. It then compares it to another object, and if the other object is identical, it makes a link between them - if not, it keeps both of them unique and adds the new one to the list of vertex data to be compared with. It's actually surprisingly fast, considering that it filters through about 5 million vertices, but it still takes several minutes to process. The result seems good except for one problem - some of the objects have identical mesh data, but special materials that we used for rendering shadows, which is solved by running another script, which searches for objects with the shadow maker material and removes them. This has to be done before linking the mesh data to make sure that our mesh data ends up with the correct materials. 3. Clean material slots The next step is to unify materials. This is already mostly taken care of because the mesh data already carries the used materials in it, but going through all of them and manually checking was required. It wasn't helping that every object had defined about 20 material slots, even if it was using just a handful of them. Whenever you have a mesh with multiple materials being used on different polygons, and you remove some polygons, chances are that you aren't using all of the materials any more.  So I made myself a script which removes the unused material slots so I wouldn't have to manually check so many of them. It's not only more work but it's also much easier to spot errors when you see only what you need to. 4. Generate Render Layers and Compositor Nodes With all of the objects correctly linked and materials properly editable, it's time to figure out how to output this whole thing into sprites. As we already hinted in FFF-146[www.factorio.com], we are almost always using Render Layers going into Compositor nodes to output many different passes of the same scene. Since we are keeping the layer structure of the original source, it was possible to set up the rendering system to do the same again. It was still a lot of work because it was not always consistent and many of the scenes required small but hard to spot tweaks. One thing which helps at least a little bit, is pre-generating all of the render layers with their names and some basic setup, which is consistent between all scenes.  Render Layers aren't much without a way to save them to the final images - this is handled by the compositor nodes. There is a special case for Ambient Occlusion and Shadow passes, but in general it's absolutely consistent so scripting this part is great as it removes all need for manual attention to this. The script just reads the Render Layers and generates the nodes to fit them. 5. Rendering and final processing To render all this from the 3D scene, we are using a fancy system which allows us to render across multiple computers, as the animations would take over 40 hours to render on a single PC.  The rest is basically the same as with the combinators shown in FFF-194[www.factorio.com], so I won't go into details here. Result After all this, we get the player graphics in high resolution, with colour masks working correctly and also a lot of new Blender tools for ourselves to work with. And here is a preview of how the colour masks work for 0.16.  All the things in this article combined took a lot of time to make, especially the high resolution version of the player character. In the long term we are likely going to do some more changes and adjustments to the player character models and animations. Thanks to the new source files we will be able to do that, and for now we are satisfied with how the player looks for 0.16. Razer Chroma Razer contacted us quite a while back and asked us if we could add Razer Chroma support to Factorio. Razer Chroma/Chroma Link means that the game can take control of any supported RGB devices (from mouse and keyboard to LED strips and chairs) and control the colors of the lights.We implemented the following:
 People already want to control their light using the circuit network and Lua, so something like that could be cool to add in the future if there is demand for it. Normally we wouldn't add features to 0.15 after it was marked stable, but since there will be some Razer events, we thought it's good idea to have Factorio in the list of supported games. So the feature was added today to 0.15 as an experimental update but it will be marked as stable next week if nothing is broken. If you have anything to say you can let us know on our forum[forums.factorio.com].  |
