Friday Facts #368 - Steam deck, Ghost bugs, Docs improvements

Posted by Twinsen, Genhis, Therenas on 2022-02-25

Today is actually the 6 year anniversary of Factorio launching on Steam, and just recently too we passed 3 million total sales (and we're even past 3.1 million at this point), so it is quite a milestone. It is great for us that the game is still selling consistently year on year, even though we never take part in sales or bundles.

Steam Deck support Twinsen

Today is the official release day of the Valve Steam Deck, so it seems fitting to talk about how Factorio performs and what our plans are.

Valve was nice enough to send us a devkit early on, so here's a recent video of me playing the game a bit.

Technically, the game works great:

  • Since it's a native Linux build, you don't have to experiment with or deal with Proton related issues.
  • The battery life is great. In my test, I got 5 hours and 45 minutes of playtime on one charge, on an average base with average screen brightness.
  • Performance is good, any reasonable base should run at 60FPS/60UPS.

But, the problem is input. Factorio was designed always with only mouse and keyboard in mind. If you can connect and play with a mouse and keyboard, you are golden, but that kind of defeats the purpose of the Steam Deck.

To use the Steam Deck's input, like in the video above, you will need to make your own controller configuration using Steam Input, trying to map the Steam Deck's buttons to keyboard and mouse interactions. Making a good profile will require a lot of patience and a good understanding of Steam Input's action sets, layers, radial menus, etc.

As a proper solution, we are experimenting with bringing proper controller support to Factorio; this will not only benefit the Steam Deck but also those who want to play the game more casually with a controller. Work on the expansion is still the top priority for the team, and controller support is no easy task, so if it comes to Factorio, expect it much later this year. For now, the game will get some GUI fixes and improvements, so that it can be played on 100% GUI scale even though the small 1280×800 screen is below our minimum 1920x1080 resolution.

TL;DR: if you want to play Factorio on the Steam Deck, you don't need to worry about any technical limitations, but you will need some patience, either setting up Steam Input, or waiting to see if Factorio gets proper controller support.

Ghosts and PVP Genhis

Ghost buildings in Factorio are here to help players plan their builds and automate the construction. However, they can't be seen by other forces. The game usually doesn't care about forces, so a player's inserter can put items onto an enemy transport belt, or electric poles of different forces can connect and form a single electric network. Combined, this led to some interesting issues.

1. Block the power transmission

Electric poles are able to connect to everything, disregarding enemy forces. This also used to include enemy ghosts. So an enemy could place a pole between two of your power poles to make them connect. It would not only make the players confused and wondering why their middle pole wouldn't connect when they tried to place it, but could also cut off power to their defences. Stealing enemy power is still allowed but you can't use ghosts for that.

2. Block the supply line

When inserters see a ghost at their drop location, they wait until the ghost is built. If you used a line of inserters to transport items, an enemy could place a belt/container ghost to disrupt it.

3. Instant remote item delivery with transport belt ghosts

A long time ago, items on belts were physical entities which belts moved. Sometimes they could get stuck when players rotated a belt, so we added logic to collect them. It should have been removed as soon as items on belts had stopped being real entities, but somehow it wasn't noticed until recently.

The logic also ran for ghost transport belts, so one player could maliciously ask another to place an (expensive) item on the ground and steal it, or create an instant delivery system when they forget something. This would come in handy, as I bet all of us keep forgetting items which are on the opposite end of the base, but still, it is fixed.

4. Deconstruction of forceless entities

Normally, an entity can only be deconstructed by the force which built it, but forceless entities, such as rocks, trees or fish, are a special case – all players should be able to deconstruct them. With the current system, forceless entities can't be marked for deconstruction by two forces at once.

This is tricky to fix because we don’t want to worsen performance for the majority of our players who don’t play with multiple forces. At the same time, we don't want to make large changes in 1.1 as something else may get broken if we do.

Nevertheless, we value all our players and we are determined to fix this for 1.2, but that's a topic for another time...

Magical long range item pickup

Machine-readable Documentation Therenas

Hi! I'm Claude, known as Therenas in these circles, and I've been at Wube for close to a year now. My primary purpose in life is to take care of Factorio's modding documentation, both on the editorial and on the technical side. That means I improve what you read in the docs, and how it even gets there in the first place.

That first part basically boils down to a heap of tiny changes all over the documentation, which make it more useful and nicer to use, but which is not very interesting to talk about here. What's more interesting is one of the technical changes I've implemented.

Most notably (hence the title) a machine-readable version of the runtime docs. It enables development tools to present this context to modders while coding, which is great for productivity as it avoids constant switching between editor and the documentation website.

The initial motivation behind creating this format was just for it to be useful to modders. Once I had dug through the dirty details to create a machine-readable output though, there was now this nice and clean base upon which one could easily build new things. Sometimes, alternative uses reveal themselves for something that's originally made with a single purpose in mind.

Sanqui took the opportunity and built a new docs website, using modern web technologies like templates instead of Python string manipulation, which created a sturdy and flexible base to build on in the future.

So with this part of the documentation overhauled, there is still this other elephant in the room: The data stage docs. They are currently hand-crafted and maintained on the Wiki, which means there is a lot of effort with maintenance and versioning. I'm working on giving them the same treatment as the runtime docs, which means they will be parsed and collated directly from the game engine, and updated with each release.

As always, let us know what you think at the usual places.