devtrackers.gg
Playtesting (kovarex)
We have been playtesting a few days this week. There were some things we had to fix on the fly, but we still were able to play quite a lot, so I would say that it went surprisingly well. We have been able to get 3 multiplayer bases into a late game stage.
Tile pollution tweaks
As we played 3 different games already, we discovered that the tile pollution absorption values are quite weird. Water was actually absorbing more pollution than grass, which in combination with the fact that water heavy worlds have less biters and more choke points, makes it way too easy compared to a desert world. In addition, grass and sand pollution absorption was brought closer together, as the difference between desert world and grass world when it comes to bitter attack intensity was way too high.Pollution absorb setting
In 0.16 one of the the map starting settings related to pollution is called Dissipation rate. Its tooltip says "Control how fast pollution dissipates naturally". Since the word sounds alien to many (I had to search it up), no one touches the setting, and we actually had to dig through the code to figure out, what the option truly does.
It was a modifier of how much pollution is absorbed by tiles. And the range is from 1 to 1000. You can't really set it lower then the default 1 and setting it to 100 for example basically removes all the pollution effectively, as tiles suddenly absorb 100 times more pollution. So we changed the setting name and description to absorption modifier, with a tooltip saying "Modifier of how much pollution is absorbed by trees and tiles." The values now range from 10% to 400%, so you can actually use it to make the game harder. This should suddenly make it understandable. Oh, and the Deathworld preset value is now 50% :)
Spawner pollution hoarding fix
As you might know, the Spawner/pollution/attack mechanics work this way: Spawners absorb pollution that reaches them, and after absorbing a certain amount of pollution, they send a unit to join an attack group. The amount of pollution depends on the type of unit, and later units need more pollution. There is also a cooldown limiting the amount of enemies sent to attack per time.
So far, so good. But there is a fundamental problem with the algorithm we use, as we randomly figured out by looking at the debug data of a Spawner next to our base.
As you can see, the Spawner needs 200 pollution to send a unit to attack, but it already accumulated more than 100k pollution, which is enough for next 500 units. Basically, the problem is, that the Spawner can accumulate an unlimited amount of pollution at a much higher speed then it can ever use. So the first row of biter nests can easily prevent the other nests from accumulating any pollution, which kind of breaks the difficulty scaling and the whole mechanic. Whether you make a little bit of pollution or a crazy amount, the amount of attacks might be the same.
The solution is simple, the Spawner now has an upper limit to how much pollution it can absorb, which is 3 times the most expensive unit it can spawn for the current evolution factor.
We made some basic testing after this change, and it seems that it is survivable enough for the release, but we might want to tune the default pollution/evolution/attack modifiers during 0.17 stabilisation.
Biters getting stuck in their own bases
One of the other problems we noticed with biters is, that they got stuck in their own base quite often. We discovered, that they can be trapped by the positioning of Spawners/Worms quite easily.
To solve this, we just added a new optional property into entity definition called map_generator_bounding_box which defaults to collision_box. It can be made larger to limit the placement of the entity by the map generator to keep the space around the entity clear. It is also used when biters are building new bases. Adding a 1 tile safe space around all spawners and worms forced the bases to have enough space for the biters to move through it.
In the future, we (or anyone) could use this property, to limit the density of trees in a forest, or similar things.
Biters getting stuck on belts
The strategy to put belts in the path of bitters to upgrade defense is a nice piece of emergent gameplay, but we noticed, that it tends to be little bit too strong. It was discovered, that biters have a small bug in their code, that affects their movement by belts way much more than it should.
Webm/Mp4 playback not supported on your device.
So posila went ahead and fixed that, and now, biters are still affected by belts, but it doesn't completely bug them anymore. How did we not notice it for like 2 years?
Webm/Mp4 playback not supported on your device.
Introduction Campaign (NPE/Tutorial/Demo)
With 0.17, we will be releasing the first public version of the new Introduction Campaign. Because of this, naturally, we will be removing the old 'First Steps' and 'New Hope' campaigns.
The 'Main Campaign' will be added to the game later, and we will be providing some more details on the Introduction and Main Campaigns next week.
The fluids
We were testing the algorithm, and there was a lot of back and forth, but the time was running by and there were some problems not that easy to fix. To prevent things from getting broken in a ways we couldn't anticipate and not to potentially delay the release any further, we decided to split the change.
So the fluid mixing prevention and fluid update optimisations are in 0.17, but the new algorithm was put aside for further research.
The Wiki plan (Bilka)
With the upcoming release of a new experimental version, a big question for the wiki is when it will be updated to that version. In the past we updated the entire wiki to the experimental version a few weeks after its release, but we are changing this up: The plan is to update the wiki to the experimental version immediately on release. I wrote some scripts to speed up this process, so the moment you see that the release is out, you can head over to the wiki and check out the new recipes and technologies without having to wait on some slow human to update that info. Furthermore, a clone of the 0.16 state of the wiki will be made and available as a read-only wiki at stable.wiki.factorio.com, for the players that prefer to stay on the stable version of the game.
Mod thumbnails (Sanqui)
Small news for mod creators. In the new in-game mod GUI (FFF-272) will show thumbnails for mods alongside mod description. Since you should be able to interact with the installed mod settings also in an offline mode, the thumbnails have to available in the mod package. To make a thumbnail show up, simply include thumbnail.png alongside your info.json. The resolution is 144×144 pixels, same as previously on the mod portal. From now on, the mod portal will only respect thumbnails provided in this way.
High Resolution Chests (Albert)
It’s common to think that the smaller is the entity the easier is to make it. Less pixels = less work. Well, not necessarily. Like an icon you have a very small space to express many concepts, material, use, style, etc. That means a lot of work in synthesis. I’ve been making drafts and 3d sketches for chests for a while, and this is the best version I’ve got for all of them:.
Wooden: Nothing much to change here, just a translation of resolution and details.
Iron: Before we had confusion between Iron and Steel. Now the difference is much clearer.
Steel: More modern and industrial looking. Like a shipping container.
Infinity: Not everybody knows this chest exists because it’s made for testing reasons, you will find it in the map editor.
Logistics: The design tries to emulate the style of the Roboport, and we introduce a new concept, an animation for opening/closing the doors.
High Resolution Rocket Silo (V453000)
There are not that many entity graphics remaining that we have not touched in the last few years, be it a conversion to high resolution, a redesign, or both. The Rocket Silo has several specific qualities that make it very intimidating, and now time has come to face them.
We recognized that the design of the Rocket Silo you can see in 0.16, has various issues we would like to address. On the first sight it is obvious that it does not fit into the visual style of Factorio too well anymore, and looks out of place. Not just because it’s very dark, but also because the giant 9x10 tile entity is completely filled into a rectangular shape. This majorly contributes to it looking like a rectangular sticker on the screen instead of an integrated entity in the world.
A lot of the elements in the old model were too blocky and artificial for the modern Factorio look. Over time we have basically replaced all of the areas of the model with new meshes. Albert helped me by creating the robotic arms and their housings in the concrete base of the rocket silo that you can see below.
Webm/Mp4 playback not supported on your device.
When we started working on the high resolution redesign of the Rocket Silo, the first decision we made was that it will now be a 9x9 entity so you could rotate the blueprints properly, and it was clear from the start that we want to make fit on the ground more. This would mean that the structure at the top of the original rocket silo would have to go, and the hole would be moved more towards the center of the entity.
The Rocket Silo without the rocket uses sixteen 8192x8192px textures which makes our 1080Ti run out of VRAM to render.. Luckily I have made the rendering as optimized as possible through python scripting as always. Worth noting that without our long-term focus on automation and proper workflow, this could have been a massive problem.
It would not have been normal if we did not need to edit things in the code or fix things, and since the Rocket Silo has an obscene amount of layers, layer switching and other crazy quirks in its animation, our beloved posila helped us fix all those issues, though he may have mentioned a few nasty words to himself along the way, and his commit messages contained words like 'black magic' more than once.
Last but very far from least, the Rocket Silo has one huge benefit - a lot of the animation happens procedurally which means the source images themselves are static PNGs. This allows for a lot of flexibility and power in Photoshop post-production that we cannot afford with heavily animated entities like for example trains. This made the end of the process extremely enjoyable and allowed us to finish it really properly.
0.17 on track
As you can see, there are a lot of things happening at the last moment, but it seems that there shouldn't be a big obstacle in the way of release next week.
As always, let us know what you think on our forum.