Hello, We are down to 28 bugs on the forum. The last bugs are often the ones we have been putting off for a reason, they generally require some more meaningful changes and decisions. That is why this week we have a lot to discuss.
G2A got back to us this Monday, nothing much has happened so I will keep it short. They asked if we would agree to an audit to verify the money lost to chargebacks, we said yes, and they said they will start contacting some audit companies, and that it will 'take some time'.
Kovarex was convinced by members of the forum to add someway to use the obstacle avoidance mode of the rail planner. Now when planning a rail path, holding CTRL will make it use the obstacle avoidance ghost planning.
Dear server owners: the server description field is being enlarged from 120 to 5000 characters, and it now loads immediately. As soon as the next release is out, you may stop abusing the "tags" field for your colorful descriptions.
We decided to change the Basic oil processing recipe so that now it only outputs petroleum gas.
Normally this recipe change would mean all 3 outputs would be petroleum gas, but we added a new feature so that a recipe can specify a specific fluidbox to use. We also used the same system so the future water input (for advanced oil processing) is closed.
We believe this contributes to make oil a bit less of a difficulty spike, and also means we no longer need to remember which side the water goes in.
This means that light and heavy oil is only available after Advanced oil processing is researched. The biggest issue this introduces is that worker robots require lubricant made from heavy oil.
Click to see more technologies.
The solution we chose to apply is to move worker robots behind chemical science pack. This change does delay how quickly you are able to get worker robots, but the difference should not be too drastic as in order to get robots operational you already need to set up a complete refinery, advanced circuits and 2 upgrades of engines - which is already most of the science pack done.
Basic oil processing now produces 25% more petroleum gas to offset the loss of light and heavy oil for solid fuel.
Technologies which newly received chemical science pack now require less science packs to research them so the total resource price is not too far off either.
We prefer to keep flamethrower as it is, but flamethrower ammo now requires petroleum gas instead of light and heavy oil.
For a long time we have felt that there aren’t really enough useful technologies unlocked by chemical science, and laser turrets are a big game changer so we’re moving those to chemical science pack along with the worker robots.
There was a bug with laser turrets, the shooting speed upgrade didn't actually increase their firing rate since we switched them to use beams. Posila fixed it, so that more turret shooting speed actually results in more damage per second, not just for laser turrets but for personal laser defense too.
Now that the shooting speed bonus works properly, we decreased the base shooting speed of the laser turret and personal laser defense by 50%, and with all the upgrades the shooting speed will be 160% of what it used to be.
Another result of this bugfix, we decided to change the initial damage of the personal laser defense from 40 to 30. However with full shooting speed technologies the DPS is much higher (at the cost of more energy).
After fixing that laser beams didn't glow in dark, OwnlyMe releases a "Glowing Laser beams" mod that makes laser beams illuminate ground under them. Vaclav requested this to be base game feature, but there was a catch: Beam graphics didn't tile properly.
We were aware of issues with tiling of beam graphics ever since we added laser beams, but Vaclav was able to workaround the problem by decreasing intensity of a glow on sprite edged and make the overlapping almost invisible. Almost.
Vaclav tried to workaround the tiling problem by adjusting edges of sprites again, but it quickly turned out it was not possible to do.
After going through code that draws beams I realized that we calculate the exact position of each beam tile, but then pass it to drawing functions which convert the position to MapPosition, which uses fixed-point coordinates with only 8 bits for fractional part. Because of this, the tiles didn't align properly and they sometimes created a gap or overlapped. To cover gaps, the sprites were drawn scaled up by 1%, which resulted in them overlapping even more. Originally, when electric beam was made back in 2015, this did not create any visible issues.
So fixing the accidental rounding of rendering position was easy, and the body of the beam started to tile properly, but there were still visible seams at the head and tail of the beam. I was reading up on how triangle rasterization works on GPUs, so I figured that it must be due to head and tail sprites having different sizes than body sprites, so they don't share an edge exactly, which causes some pixels on the edge to be rasterized by both quads and some by neither quads. After spending some time on fixing this problem I found out that the problem was not in rasterization of edges, it was caused by texture filtering.
The head and tile sprites that I was using to test the issues were larger than they should have been, and were overlapping the body sprites. Lights are almost always gradients spanning over large area and are rendered using bilinear filtering. So the edge of body tile was aliased because that's where quad ended, but edge of head sprite was bilinearly filtered, because that's where the edge was drawn in the sprite, not the actual edge of the sprite quad. So I changed how the head and tail sprites are drawn, in order for them to always share an edge with body sprites, and that fixed the issue. As a bonus, we were able to turn on trilinear filtering on beam sprites, we didn't use it on them before because it used to make tiling issues even worse.
Now the beams and the glow are as close to pixel perfect as we can get them. The glow really does make the scenes look that much nicer.
I did some improvements to Inserters during some releases of 0.17. I made them faster by removing what I thought were pointless pauses where the Inserter would do nothing for 1 tick in some situations. But after 0.17.50, this started happening:
In some specific situation, the Inserter would aim for an item coming towards it, but because the item was too fast, it would overshoot the inserter head. If this is timed in a certain way, it would happen indefinitely. Before 0.17.50 this didn't happen because the Inserter would pause for 1 tick after failing to pick up an item, breaking any timing loops, but it also meant that an Inserter would potentially wait up to 10 ticks during one swing (since the Inserter tracks items on moving belts throughout it's entire movement).
So I didn't want to revert back to the previous logic. Many more complex solutions were not very feasible either since Belt<->Inserter interaction is a performance critical part of Factorio. So the final solution was to pause for 1 tick after failing to pick up an item, but only if the Inserter head is on top of a belt. This is should be the best compromise all things considered.
We plan to do a release on Monday, so you will have a chance this weekend to share your thoughts regarding any of these changes over on our forum.
