Hello, the office is slowly ramping back up after the Christmas and New year festivities.
Part of the final polishing and cleanup work of preparation for 1.0 is cleaning up and smoothing out some of the hiccups in the game. Many will remember FFF-266 where we talked about some of these upcoming changes and simplifications. One suggestion that came up was to adjust the belt throughput from its unfriendly 13.33 items/s.
Belt throughput is determined by 2 variables, how far the belt moves items each tick, and how much space there is between each item. There is a visual requirement that belts only move integer number of pixels every tick, so that is 1/2/3 pixels for transport belt, fast belt, express belt respectively. This means the only 'allowed' way to change transport belt throughput is by changing the spacing between the items.
The spacing currently is 9 pixels between items. The fact that each tile is 32 pixels, and that 9 is not a factor of 32, explains the odd throughput number. This spacing also leads to some undesirable behavior, such as when using the circuit network to read the belt contents sometimes the belt can fit 8 items, sometimes it can only fit 6, and the count will fluctuate between the two:
At this point it is quite obvious to reduce the spacing to 8 pixels, which is a factor of 32, and gives a nice even 15.00 items/second, which is what we have done for 0.17:
With a spacing of 8 pixels, belts now always fit exactly 8 items (4 on each side), so for instance, reading a fully compressed belt gives a reliable result:
The change overall gives a 12.5% buff to belts, provides nice round integers for calculating factory requirements, and removes a few oddities. A next step we are considering is tweaking the furnace recipes to match the belt speed, but that is a consideration for another day.
In the last few weeks I have been working on a system that allows mods to easily render geometric shapes, text and sprites in the game world. Like many modding features, the implementation of this rendering system was prompted by a modding interface request. When I first saw this request, I doubted the usefulness of adding a whole new API that needs to handle saving and rendering for just one mod author. A few months later, another mod author discovered a newly added method to create text that was only visible to one player and requested more features for it. Through further discussion with the mod author it became obvious that they were looking for a system to show some helper text and sprites to only one player. After other mod authors joined in to point out that the solutions implemented at the time were not sufficient, the idea of a script rendering system was dug out again and I picked up the task to implement it.
Of course, one does not simply invent a new system without first finding out what the system should be able to do. Here I want to thank the regulars in the #mod-making channel of the Factorio discord. They were a great help in suggesting features and always happy to answer questions about what they render in their mods. I also consulted old modding interface requests on the forums to find out what features were desired, amounting to a total of 12 requests that are now fulfilled by the new system. With this information I wrote a rough design document that listed the desired features without considering their implementation.
The current implementation of the script rendering boasts eight different object types. The basic geometric shapes being line, circle, rectangle, arc and polygon. Additionally, sprites, lights and text can be drawn. One of my main aims was to make the system as flexible as possible which I achieved by making every single property of the render objects changeable after creation. One example of this is that the size or orientation of a sprite can be changed without destroying and recreating it. This differs from the previous rendering that mods used. They would create many entity prototypes which had sprites with the desired orientation or size and then switch those out to change the orientation and size of the sprite. This frequent replacing of entities comes with a considerable performance cost which the script rendering completely eliminates.
Furthermore, the rendering objects are simply identified by numeric IDs which are much more performant to handle in Lua than LuaEntities. Another advantage of this dynamic system is that nothing in the rendering relies on the data stage. Unlike the mentioned technique of using entity prototypes, the script rendering does not need prototype data. This means that scenarios, the so called 'soft-mods', can also make full use of this new system.
The first big point in the design document was to allow any target to be either an entity or a position. This point with, the addition of entity offsets, works beautifully in-game. Objects can be 'attached' to entities or placed at static positions. Even a combination of the two is possible if an object like a line has multiple targets. Due to the attachment to entities, the render objects are deleted when the entity is destroyed. This leads to some very useful behavior: If mods for example want to simply place some text above all their entities, they don't have to handle deleting the text when their entities are mined by the player or eaten by biters.
The second big point was conditional visibility, this means that it is possible to restrict the rendering of objects to certain forces and players. This will hopefully see use by the helper mods that prompted the implementation. This conditional visibility had also been requested in the past where it was handled as something that simply 'won't be implemented'. The main reasoning for this was the predicted performance impact of adding the player whitelist to many entities that the base game uses. This performance concern is irrelevant when using the script rendering because it is a completely separate system from the base game rendering. If you don't use mods you won't even notice that it's there and it won't impact game performance.
In combination with other modding additions, the new render system opens a lot of interesting possibilities for mods to explore.
In general, this new system means that mods no longer have to abuse entities like beams, smoke or flying-text for rendering. This opens up a lot of possibilities of new rendering options that previously could not be considered, such as custom fonts for text or easily changeable scale and orientation of sprites. So, mods authors, please think about what rendering options would be useful for your mods and request them on the forum if they are not already implemented.
As always, let us know what you think on our forum.
