The beacon is one of the last entities left to convert to HR. As always, before 'just re-rendering' we take the chance to re-think the concept and modernize it. This post will try to go a bit deeper in the process of redesigning such an entity.
The old beacon
At the beginning of the project, the style of the game was less or more clear: nothing looks brand new. Everything looks dirty and DIY. The machines need to be full of details, if possible trying to explain its mechanics. The colors are provided by the raw materials. The bounding box is everything. And some other rules that I don't even remember now.
The main handicap at that time was that we didn't have the experience of how the average player is composing the factories. So we produce a nice looking model but once it is placed in the factory, it doesn't look that nice due to the lack of context.
The process for the new beacon
The beacon is a very advanced late game entity. Usually placed very close to each other in long rows, horizontal or vertical. Its function is to provide extra power to other entities in its surroundings through the air.
One of the main objectives for the redesign is not only a better coverage of the most common needs of the entity (shape recognition, working good in its context, and total integration in the world of the game) but also its expressivity.
It would be really good to understand the use of the machine just by looking at it.
In this early sketch the main concepts are already defined.
It needs to be a tower in order to transmit the effect. But the tower has to be transparent, otherwise it will occlude the other entities behind, creating a problem of readability.
It has to look modern. That's why the conical shape with rounded windows. It reminds of a soviet space capsule. The blinking lights inside will help not only to look more technological, but also will help for visibility.
Due to its normal usage in long rows, the plan was to create an extra tileset of cables connecting the beacons to each other. So the composition would look much more interesting and organic with the player moving under this network of beacons.
The idea is cool and it works on paper, but once we get to work, we realise that it's needed to fill a square of 3x3 tiles. Once in the 3D viewport, this concept changes too much to not think of different solutions.
Connecting the entities with cables. It looks like the beacons are interacting with each other creating a more powerful net of beacons, and this is sending the wrong message.
Save the good stuff and solve the problems in a new version
The main problem was the need of stuffing the tower in a squared area. This rule of the collision box forces every entity to be some sort of a blocky box on top of the ground, always, and for this entity we really needed the tower.
To solve this issue a new concept appears: Let's create a hole in the ground that covers the collision box area, and build the tower inside. It looks higher than what it really is, and the occlusion with the tiles behind is in the acceptable limits.
The beacon looks modern, colorful, tall, high tech, and integrated in the world of Factorio. It even solves the collision box issue and is easy to recognize from afar. But it has something wrong: it doesn't work fine in an array, and the center of the entity is too complicated. It creates a chaos of pixels that is hard to see, especially when overlapping with another beacon vertically.
A better beacon
To solve the ultimate complication for the array situation, a few changes are relevant to do. Cleaning up the center of the entity in a way that works as a background with himself when overlapping in vertical (or any other tall entity, like a pole).
In the so common array situation, it's going to be really nice seeing the beacon with some variations. This will make it look more natural, and pleasant to the eye.
We would like to use this sort of variations for every entity, but the amount of work and VRAM needed would be just insane.
This is still a work in progress. Right now I’m working on the animation of the beams. I’m trying to make it much more subtle, because the way it is here it calls too much attention and saturates the screen very easily.
The layer of the beams and the light will be separated and tintable in a single spritesheet. Probably the yellow rounded light also. It will be available for any modder to make a modified beacon just by changing the RGB values.
There are many things I didn't say about this process of redesign, but I had to keep them out because this post is already very long. I hope it was interesting to you.In future releases, very soon, you’ll be able to play with it.
Personal logistics has been moved to a separate tab. Logistic requests and auto trash have been merged into one panel.
Using quick inventory transfers in the player inventory of the character gui will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.
Updated the look of filter, item and circuit signal selection GUIs.
Changes
Personal logistics are now unlocked by a single research. This unlocks personal logistic requests and auto trash(unlimited count), plus 30 character trash slots.
Removed the restriction of not allowing to have two identical blueprints in the blueprint library or blueprint book.
Allowed to delete blueprint/books/upgrade planners/deconstruction planners also when opened in other inventory.
Removed the utility slots (to create blueprint, book etc) from blueprint library as it is now available directly through quick tools menu.
Allowed to edit blueprints in the blueprint library the same way as when it is an item.
Allowed to export blueprint books in blueprint library (it was only possible in inventory before).
Allowed to choose whether train fuel should be included in a blueprint.
Bugfixes
Fixed that 3rd last row of 4th sheet of gun turret shooting had duplicate frame. more
Fixed desync when changing recipe that was outputting large amount of fluid per crafting cycle to recipe that outputs low amount of fluid. more
Fixed sprite button would not respect draw_shadow_under_picture style property. more
Modding
Added main_menu_background_image_location to utility constants.
It was 11 months ago when we first mentioned the new Character GUI, in FFF-289. After all that time, it's finally getting ready. Since you can expect to see it released sometime in the next 1 or 2 weeks, we would like to present a quick recap of the features and changes, and some real in-game screenshots. The Character window is now split into 3 tabs. Logisitcs and auto-trash were moved from the central frame into a tab and a new tab called Character was added. Using inventory/stack transfers in the player inventory will transfer the items either to weapons and armor slots or to trash slots depending on the selected tab, regardless of item type.
Logistics and auto trash are now merged into 1 panel. Using a double slider you can set an interval. If you have less than the first value, robots will bring more, if you have more than the second value, extra items will be auto-trashed and taken away by the robots. The double pop-up and extra confirm might seem strange, but it's made this way to solve the problem of robots bringing you items before you finished setting up your request.
With the merging of requests and auto-trash, we also made it so you can now set an unlimited number of requests, regardless of research. Furthermore, everything is unlocked in one research: unlimited logistic requests, auto trash, and 30 trash slots are all unlocked by the "Logistic robotics" research that is at blue science.
Searching now not only searches the recipe GUI, but also the inventory and logistic requests.
By popular demand, we also added a switch to quickly turn personal logics on or off. Turning off personal logistics will stop logistic robots from bringing requested items. It will also stop items from automatically being moved to the trash slots. Logistic robots will continue to empty the trash slots.
Since the recipe GUI has a new style, we also updated the look of the filter, item, circuit signal, and upgrade selection GUI styles. Some of the other GUIs in the game will have some visual issues due to the mix of old and new styles. My next step will be to fix these issues as soon as the Character GUI is released.
Looking back, this GUI took 13 months and 3 programmers (working alternatively) to implement. This is excluding mockups and UX design. It's a long story, but one thing that's obvious is that the GUI scope has grown far beyond what our codebase is capable of. For this reason, we won't be <s>focusing</s> obsessing that much on the GUI in the future. We will finalize the transition of styles, fix obvious issues and low hanging fruits, and try to get everything at a consistent level of quality for 1.0.
This new Character GUI and changes will likely affect some mods, especially those relying on logistic technologies, logistic slot related APIs, old style definitions, etc. Thankfully a lot of mods will be unaffected, so we hope it won't be too much disruption. Still, we wanted to give some forewarning.
Community spotlight - Krastorio 2 (Bilka)
Over the past two weeks, an overhaul mod called Krastorio 2 has been going through closed alpha and beta testing. Krastorio 2 is an overhaul mod that aims to provide a vanilla-style experience with an expanded post-rocket game and updated recipes. The mod will be released later today, so I wanted to take the opportunity to spotlight it.
My factory, grown over the two weeks of testing, showing off the custom mod graphics. Click to view full resolution
The mod changes almost all recipes without introducing many intermediates, making it close to vanilla while still being a new experience. One of the bigger changes is that late-game technologies do not require the starting tech cards (science packs). Combined with the tech cards mostly needing intermediate products, you can reroute the ingredients of the tech cards into other production as the tech cards become obsolete.
Post-rocket tech cards are consumed in the lab area on the left in the image, the pre-rocket tech labs stand disused in the bottom right.
The biggest feature of Krastorio 2 is that it adds a significant amount of content beyond the rocket launch, including a new win condition. After automating rocket launches there are three more tech cards waiting to be researched, two new resources waiting to be harvested, and many more useful items to be crafted. All that production and the win condition take a significant amount of power but thankfully the mod adds an effective power generation option to fulfill the factory's needs.
Fusion power
All in all, the mod can be described as a great mix of updated recipes and fresh mechanics that are kept in line with vanilla. This means that the mod is not as overwhelming as overhauls that really focus on certain mechanics such as many additional resources, fluids or intermediates. Instead Krastorio 2 strikes a great balance between old and new. The mod has many more features that I did not mention here; so if I made you curious, check out the mod for yourself and have fun playing!
The statistics GUI (electric network stats, production stats, etc.) is one of the GUIs that has been in the game for a very long time, and has had its functionality fleshed out reasonably over the years. It was not long ago when Twinsen added hovering and highlighting to the graphs.
Given that, and the relatively short timeframe for 1.0 release, the update of the statistics GUI has really just been a style update, no new features or heavy logic rewriting. Oxyd has most of the work done, so we are happy to show some real in-game screenshots of how it looks:
A notable change with the electric stats is that the Satisfaction/Production/Accumulator charge are next to each other in a single row, as opposed to each in a separate row. The label for the exact amount has also been moved to inside of the progress bar, which itself is much thicker.
The production stats are pretty much the same functionality wise. One new button you might spot is the search button.
However there are some problems with the search feature. As you can see, production and consumption frames have a different search box independent from each other. The main problem is when pressing CTRL+F to perform a regular search: How do we know which frame to open? Of course this could lead to different solutions like the use of a cycle for the focus of the search, in which the second time you press CTRL+F the other frame gets the focus. Or both of the search boxes open at the same time but only one gets the focus. Or only one frame gets the focus and the other one works only by pressing the button. But let's face it, these "solutions" are not solid at all and create inconsistency in the main design.
To solve this issue we decided that the simplest way to go is the use of just one search box on the header of the panel. This new location works as a general feature for the entire panel. One single search gives you 2 results, one on each frame. This solution is used in the new character window -to come soon- making it consistent with the whole design of the GUI.
You can also see we took this opportunity to integrate the Kill statistics in with the rest, instead of being its own window with its own hotkey.
The Statistics GUIs will need a few tweaks and polishings here and there before it is ready for release, but unless something unexpected happens you can expect it coming out in a release soon.
Community spotlight - Mod Debugging and Instrument Mode (justarandomgeek)
This topic is a guest post by our community member and mod maker justarandomgeek.
Historically, while developing Factorio mods, you just had to write some code and try it, until you get one of these:
Then you go back and find that spot in your code and try to figure out what went wrong. If the error is particularly confusing, you start sprinkling <tt>log()</tt> or <tt>game.print()</tt> around to try and figure out what the heck is going on. And, of course, when you find the problem, you inevitably forget to clean all of these up, and now you're spamming the log or chat forever.
Well there's your problem! Perhaps a bit constructed...
For the last few months I've been working on a debugger to improve this experience. The first step was to spend some time with the Lua debug library and VSCode's Debug Adapter Protocol making introductions to get them talking to each other. Factorio doesn't give me many options, but Lua's <tt>debug.debug()</tt> and <tt>print()</tt> functions are enough to interact with the (normally invisible) console.
VSCode can launch Factorio and attach itself to this console to inject commands as needed to read and manipulate the state of the running code. This gets us VSCode's debugger interface, with all the pre-built tools for displaying variables, setting breakpoints and stepping through code. Wrapping some of the game's APIs like <tt>remote.call()</tt> and most of <tt>script</tt> to add a little extra special handling, we get nice labels on event handlers in the call stack and a first version of break-on-exception for when things go wrong. I even built some nice detailed variable views for the most common LuaObjects:
But there's a catch, and it's a big one: because of the way Factorio sandboxes mods, the debugger (which is itself a mod, in part) can't actually get to your mod to install all these hooks! The first solution to this is to simply add a line to load the debugger, but this puts us right back where we started with <tt>log()</tt> - you put something in for debugging and forget to remove it.
To solve this problem we need a little help from the API, a way for a mod to hook every other mod. Unfortunately, this level of hooks is too powerful of a capability to be generally available to mods, so it can't really be added to the normal mod API (it allows you to fairly trivially break nearly all assumptions about data lifecycle and mod sandboxing). After some discussion with Rseding, we eventually arrived at Instrument Mode (released with 0.18.10), a special mode which allows a selected mod to hook all the Lua instances Factorio creates, at the cost of disabling multiplayer and only allowing one Instrument at once. This also provides a hook for a better version of break-on-exception.
This gets us all the way to the rich debugger experience: When you run under the debugger, all loaded mods automatically get debug hooks installed for the session (but not permanently), and you can step through the code and examine all your variables!
While I was building tools, I also added some highlighters for locale and changelog files, and validation for changelogs:
And of course, it's a game about automation, so we need some modding workflow automation too:
Modders, please give it a try and let me know what you think!
As one of the last entities which do not have high resolution graphics, the time has come for the offshore pump.
The offshore pump is practically a 1-tile entity, but they must have a 1 tile gap between each other. It is also the only entity placed on a water tile at the moment.
When we changed the way how terrain to water transitions work, we moved the offshore pump to be placed on the water tile. This can result in the pump drawing over terrain in ugly ways.
With the redesign, we took the oppourtunity to move the offshore back onto land, and additionally the pump checks a 2x3 tile water area in order to be buildable.
The new placement rules only applies to newly built pumps. Offshore pumps on existing maps will keep functioning, they’ll just be shifted out from the shore.
There is no blue colour for water integration at the tip of the offshore pump, so the offshore pump will look correct even with unexpected water types (not a big problem in vanilla). The water integration is split to an underwater layer which does not show when the pump gets landfilled over.
In the basic concept, the offshore pump is another type of a pump, so it should be similar to the other pump entity Albert made a few years ago, including the animation and visible fluid in it.
The obvious difference is the connection to water. However we felt that is not different enough and needs more visual balance, so we added a pair of supportive legs.
We are planning to release the new offshore pump graphics with the next release, likely next week.
Mod spotlight - Built in beacons (V453000)
Beacons strongly motivate building in rectangular repeatable patterns. The results generally look clean, but also very predictable and boring. Furthermore, the differences between different recipe builds are only minimal, so the visual difference between builds is minimal.
The issue is, I like to build the opposite of clean and predictable. The factory looking increasingly complicated and harder to expand over time is what keeps me engaged to continue playing a map. When it starts looking easy, I lose interest.
I’ve been trying to solve this for myself by either restricting myself from using Beacons (which is a massive sacrifice of productivity and speed), or by putting the sub-factories with high Beacon counts outside of the starting area, as keeping the organic starting area is key for me.
Eventually I thought about creating a mod that makes machines behave as if they had the maximum possible amount of beacons around them - allowing me to upgrade the starting base, but that also causes higher demand on the throughput of logistics, which the most interesting part - snaking more belts, fitting in more rails.
The mod defines 3 tiers for every producer to simulate beacons with tier 1, 2 or 3 of Speed modules in them. These machines cannot be further affected by normal Beacons and only accept special productivity modules defined by the mod.
Creating the mod was a ton of fun. I rewrote it about 3 times as I was learning how to do it better. I hacked together some basic graphics for it from some special passes (height and Ambient Occlusion) that we use for postproduction in our gfx workflow.
I played with the mod and got some interesting results (imgur album) as I was able to continue building in the starting area instead of refactoring it for Beacons.
Lastly, I wrote a timelapse-screenshot tool. It can either be used by taking a screenshot each N ticks automatically, or in my case I give it a folder with savegames and it takes X number of screenshots, then moves to the next savegame. It's quite crude so I won't release it on the mod portal for now.
Making Beacons disappear into producer machines to allow for more organic bases fits my perverted playstyle, but Beacons actually do bring a lot of interesting motivations to the base game, and it can be a lot of fun to mess with the building rules that Beacons force.
You can find the mod on the mod portal if you are interested.