Hello. It has been a quiet week in the office, we are slowly arranging everything needed for the office moving, which (if all goes to plan) will happen 7-11th of May.
Factorio-data repository
We received a request a short while ago from one of our mod creators, sparr, asking permission to host a public repository of all the Factorio prototype data. This has many potential uses for our community of modders and content creators:
Online references, cheat sheets, and calculators; can use it to automatically update when new versions are released.
Link directly to specific library code and entity definitions when discussing such matters on the forums, GitHub issues for mods, Discord etc.
Browse diffs between the versions, seeing the implementation of prototype changes we mention in the changelog.
It seemed like a pretty good idea, but we decided it would be better if we did it ourselves. That way we can verify and validate that it is correct, and also add it to our deploy process so it is fully automated. Wheybags made quick work of the implementation, so now all interested parties can check out our Factorio-data repository.
Pipe fast replace
We added the belt-fast replace feature back in 0.16 (more), but as it goes with adding QoL features, it makes us see the deficiencies in other areas.
So a very similar feature request was passed along to Dominik, "Same thing with the underground belts, but for pipes". It was completed a while back, but only recently was merged into our 0.17 branch, so I can show it off:
As always, let us know what you think on our forum.
Fixed that changing force of a wall didn't update the connections, which could lead to a desync.
Changed that walls and gates marked for deconstruction don't connect, which solves some desync related problems with walls/gates marked for deconstruction with walls/gates ghosts on top of it.
Changed, that rail signals marked for deconstruction disconnect from the rails.
Changed, that rail signals marked for deconstruction are not blocking blueprint placement of rail signals. These changes should make it reliable to mark rail setup for deconstruction and build blueprint right on top of it before it is deconstructed.
Changed the logic of "toggle LUA console" key to only open and not close the console (exception are ` and F1-F12 keys). more
Fixed LuaEntity::splitter_output_priority read/write didn't work. more
Fixed malformed sprite path error would not trigger minimal mode when loading mods. more
You can get experimental releases by selecting the '0.16.x' beta branch under Factorio's properties in Steam.
The long fight with the elusive Ryzen bug (more and more) seems to finally have some resolution.
A few weeks ago I sent an email to AMD, filling them in on the details of the crash, and asked them if they could help us solve this. Very quickly I was put in touch with a member of their CPU engineering team, and they got to work with their investigation. After a few days, and after providing them all the information we have (log files, source code, crash dumps etc.), the cause of the issue was identified.
Some other developers in the industry also had this problem and worked with AMD to fix it, so it's unlikely that the CPU bug was fixed only because of us, but we are honoured to have contributed to this. Unfortunately we do not have any technical or deep insight into where exactly the problem lay, or what the fix was, as it was somewhere between the motherboard BIOS and the Ryzen chipset drivers.
So if you are running Factorio on a Ryzen system, we advise you to update your BIOS using the files and procedures found on your motherboard manufacturer's website, and update your chipset drivers to the latest version.
PAX East Report
Two weeks ago we travelled to Boston to showcase our game at PAX East. I really like games and game conventions, so I was the lucky one who got to go to PAX East, after having already attended the Taipei Game Show. I was joined by Rseding91, v453000, Klonan, HanziQ and Jiri.
Compared to Taipei, PAX was much larger, with a lot more players reacting positively to Factorio, and many more people knowing the game.
We had a 4 banners showing the base mentioned in FFF-236, a TV playing the trailers, and PCs with the first two levels of the campaign (the first one was shortened quite a bit). These worked well together. The trailer got people hooked, the demo showed them what the game is about and the banners showed them that the game is very deep and complex.
We noticed a few categories of people coming to our booth (in order of most frequent):
Fans who already knew the game and wanted to show their appreciation, thank us or get some merchandise (we really should have brought more pins and t-shirts). Many of them would say "I wasted hundreds of hours in this game, you guys almost ruined my life".
Groups of friends passing by our booth, with one of them telling his friends "Oh, Factorio! Man, this game is amazing you guys really need to play it!". They would then proceed to explain the game to their friends.
People who heard about the game and wanted to give it a try.
People watching the trailers and having a chuckle when the biters get hit by the train.
Every one else who sat down to play the demo, either stopping after the first short level or playing all the way to the end of the second, longer level.
Like last time, it seems that the event didn't bring us much sales, but it's hard to judge since we already had a spike in sales when we announced the price increase and 0.16 stable. Nonetheless it was definitely nice to be there and meet the fans, other developers and members of the industry, and to play all kinds of games that were being demoed. It was also a great learning experience for us, in both event management and the impression that the game leaves.
Special thanks to RaZer and Dell Alienware for lending us the PCs for demoing the game.
While there I filmed some short clips, including a few with our booth and edited them into a video. The quality is pretty bad since I accidentally set the camera to record in 640x480. You can see the video on my personal Youtube channel here. We also made a small album with some photos here.
After PAX, HanziQ and Jiri visited New York City, while Rseding91 and I went to Los Angeles where we visited the Blizzard campus, Six Flags and also had a small meetup with a few Factorio fans.
From left to right: v453000, Rseding91, Klonan.
As always, let us know the way you feel on our forum.
Today we will speak a bit about the work in progress of the Technology tree, and the main GUI style/philosophy evolution.
The visual style is evolving and becoming more mature. The aim is to be as functional as possible, and also be pleasant to interact with, always having in mind the limitations of making it work in our engine. This is why we bet for a neutral and sober look that helps to focus on the relevant elements, without the distraction of possible decorative elements. This is not easy to decide, because the tradition of video-games is very rich in decorative GUI elements, and I'm sure that many of you would prefer having screws and rust in the corners of the metal panels and cables hanging everywhere in the GUI. Me too. Sometimes. I believe that once the GUI is completely functional, there will be some minimal decoration and this kind of fantasy, but this will be another chapter if it ever happens.
We are paying a lot of attention to the readability in general, according to the AAA standards of the WCAG. So the contrast with the panels and the font is increased quite a lot compared to previous mock-ups by simply using a contrast checker. Also the font size is increased by 2pt so it is more comfortable to read. Anyway, the user will have control of the font size in the options menu.
Bear in mind that the next mock-ups are a work in progress, and we still developing our standards, so some colours and solutions can vary through further iterations.
Getting to the point - Research queue
This picture shows the actuality of the state of the technology tree:
As you can see in the top left frame we added a new functionality. In this panel you can organize the order of your researches and see the progress in real time. The player will be able to cancel a queued technology just by hovering the card and pressing the cancel button. This progress is attached to the card, and will also be visible in the tree itself. See the screen below. The fluid wagon has been researched and you can see this in the tree and in the queue. By using the principle that, when the GUI tells you about some element, it always tries to use this very element, not a representation of it in another frame of the screen.
Featured Technology
The index of technologies remains as it is, but the position of the Featured technology frame is now attached to the tech tree, next to the technology itself. The link between the type of technology and info or interactions related to it, are physically tied. We are trying as much as possible to interact with the elements in situ, trying not to open unnecessary frames or pop ups of any kind and lose our visual focus.
The same happens with the research/queue button. It is placed on top of the featured technology and wraps it with a color indicating it's state, and providing the possible interaction. When the technology is researched, or unavailable, the button appears pressed and the color changes. The color code of the cards remains as before, we have just added a new orange state. Yellow for available, orange for queued, red unavailable, and green researched.As said above, tonalities may change in future, but this is pretty much it.
The opposition
As this is a dev blog post, it might be nice to show you some internal part of the process. The thing is, that my domain is mainly programming and gameplay, and Alberts domain is graphics. GUI is often something in between, so the two views on the subject tend to be hard to agree on occasionally. In situations like this, and I can tell you that there were a lot of these over the years, we are able to argue for quite some time.
The proposal comes to me and the inevitable discussion about how is the GUI actually going to be implemented. I really love the overall change of the looks, it suddenly looks so much better and professional. But obviously, different people have different priorities, and are used to different things in UI. I personally had problem understanding, that the Queue button is actually a button on a first glance. I'm used to the standard (not only in Factorio), that a confirmation button is in the right bottom corner of every window. I am also used to the fact that text button just looks the same everywhere, so I can recognize that it is a button instantly.
As a reference I would like to show the blueprint confirm.
It was never designed by Albert, and will be touched by the UI changes in 0.17, but it might be a good lesson about standards for us anyway. It is the confirm like window, that doesn't have the confirmation button as a text button in the right bottom corner. It has a sprite button in the top right corner instead. We have it in the game for quite some time, so we should be used to it, but I still feel like I'm lost for split of second when this window appears and I would actually prefer if it was standardized.
I understand that there is very good reason to have the proposal done this way, both graphically and logically, and I'm aware that Alberts understands the importance of standardisation more than me. We might just have different views on what is the more important principle when these come into conflict. It might be interesting to see what has the reader to say.
Epilogue
As you can see, the GUI re-design tries to be very respectful to the current one, making changes only when is very clear to us that is for the best of Factorio, and not for the sake of changes. I'd like to talk about more subjects, like multi-resolution, HR tile-set, modularity, animations, other mechanics and some more GUI philosophy, but it's late and there are more Fridays.
I'm very curious to see what you think about it in the forums.
Hello, since 0.16 is stable we can assign more of our effort into the work on 0.17. One of those features planned for that release is the Rich & interactive text.
Having more text formatting options was one of the things we wanted for quite some time, and it is finally starting to become reality in the 0.17 branch.The initial motivation was to have more possibilities in the tutorial related texts, but it proved to be useful having it available globally in the game.
The current format for any text markup we use is [<type>=<value>], but it might change somehow before 0.17 hits the public. This feature is being developed by wheybags, and it is progressing forward quite steadily.
Basic text formating - font and color
The obvious option is to allow changing text color:
and to allow to change font:
Images - icons
Since we already have a system to specify icons by the SpritePath, we can use it as well:
The cool thing about this, is that all these concepts work on basically all places where text is used, so you can use it in the station name for example:
or even save names (although, I needed to add a possibility to use "." instead of "/" in sprite path resolution to make it possible):
or blueprint names:
etc.
Element references
The next planned step will be to make it possible to allow this not only to be used as icons, but as references to the actual items, so the syntax would be something like:[item=straight-rail] or [recipe=advanced-oil-processing]. When used in the chat, it should allow the reader to hover over the icon and get a tooltip of the corresponding game element. When used with technology, it could allow the user to open the mentioned technology by clicking the reference icon.
More advanced usages
This brings us to the more advanced possibilities, like linking a map position as a clickable icon in the text (something like [gps=<position>]), referencing your armor, so other's can just hover it in the text and see it. Specifying target to specific train you want to mention and mainly, being able to reference blueprints this way, something like [blueprint=<blueprint string>] can you to show some specific setup in a chat, and others could be able to get the blueprint by just clicking on the icon if they want to.
I would be quite curious to see what other type of usages of this can you come up with, let us know on the forums.
Hello, since 0.16 is stable we can assign more of our effort into the work on 0.17. One of those features planned for that release is the Rich & interactive text.
Having more text formatting options was one of the things we wanted for quite some time, and it is finally starting to become reality in the 0.17 branch.The initial motivation was to have more possibilities in the tutorial related texts, but it proved to be useful having it available globally in the game.
The current format for any text markup we use is [<type>=<value>], but it might change somehow before 0.17 hits the public. This feature is being developed by wheybags, and it is progressing forward quite steadily.
Basic text formating - font and color
The obvious option is to allow changing text color:
and to allow to change font:
Images - icons
Since we already have a system to specify icons by the SpritePath, we can use it as well:
The cool thing about this, is that all these concepts work on basically all places where text is used, so you can use it in the station name for example:
or even save names (although, I needed to add a possibility to use "." instead of "/" in sprite path resolution to make it possible):
or blueprint names:
etc.
Element references
The next planned step will be to make it possible to allow this not only to be used as icons, but as references to the actual items, so the syntax would be something like:[item=straight-rail] or [recipe=advanced-oil-processing]. When used in the chat, it should allow the reader to hover over the icon and get a tooltip of the corresponding game element. When used with technology, it could allow the user to open the mentioned technology by clicking the reference icon.
More advanced usages
This brings us to the more advanced possibilities, like linking a map position as a clickable icon in the text (something like [gps=<position>]), referencing your armor, so other's can just hover it in the text and see it. Specifying target to specific train you want to mention and mainly, being able to reference blueprints this way, something like [blueprint=<blueprint string>] can you to show some specific setup in a chat, and others could be able to get the blueprint by just clicking on the icon if they want to.
I would be quite curious to see what other type of usages of this can you come up with, let us know on the forums.
