Posts by V453000

Friday Facts #347 - New hope demo levels

Posted by Klonan, V453000 on 2020-05-15

New hope demo levels Klonan A few weeks ago we discussed the changes to the demo and tutorial in the game (FFF-342). One piece of feedback we received after publishing the news was about the old 'New hope' campaign levels, and specifically the 'Abandoned rail base/Broken rail map'. It seems a lot of you in the community really really enjoyed the new hope campaign levels, and several of the team here share the same feelings. After we scrapped the plans for a new campaign and reverted to the old demo, we had initially dismissed the idea to revive the New hope campaign... However due to popular demand... we have decided to bring back the favourites, the first 2 levels of the new hope campaign. This time though, they will also be included in the demo version of the game. This represents a very significant increase in scope for the demo, increasing the demo content to include research, red science, green science, trains, and much more. These levels should be ready for release within a week (but no promises).

Friday Facts #336 - Offshore pump redesign

Posted by V453000 on 2020-02-28

Offshore pump redesign V453000, Albert 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.

Friday Facts #332 - More sounds & Map color tweaks

Posted by Ian, Klonan, V453000 on 2020-01-31

Hello, We released 0.18.2 and 0.18.3 this week. In terms of major releases, this one has very few bugs, so we haven't had a lot of pressure to crank out the releases at lightning speed.

Friday Facts #331 - 0.18.0 release & Train pathfinder changes

Posted by Klonan, V453000, boskid on 2020-01-24

0.18.0 release Klonan Early this week we pushed the deploy button on 0.18.0 (patch notes). This was quite a surprise to many of our players, as more typically the time between major releases and the scope of the release is greater. However this isn't like the old days, we are trying to keep the size of releases as small as possible (FFF-314). What this means, is that what is currently in 0.18 is only really a small part of the work needed to be done on 0.18, and releases in the coming months will continue finishing off our 0.18 task list. Once everything on the 0.18 list is completed and the time is right, we will turn 0.18 into 1.0. What we have accomplished with 0.18.0: GUI Main menu redesign GFX Water animation Tree animation Color correction (LUTs) New explosions and damage effects Other Optimizations New Particle system First work on new sound design Steam login What we have left to do in 0.18: GUI Character GUI Blueprint library Statistics GUIs (production, electric network stats, etc.) Entity GUIs (Inserter, Assembling machine, chests, etc.) Main screen GUIs (Chat, minimap, etc.) Many more... GFX Offshore pump redesign Assembling machine redesign Beacon redesign High-res icons Final tweaks and polish Other Further sound design improvements Mini-tutorials Replace NPE with old tutorial Final game balancing and tweaks Finalised locale and proofreading With this in mind, it wouldn't make sense to mark 0.18 stable before most of the above is finished. We made 0.18 a major version because it will break mods with all the changes we are making, and while initially it hasn't broken that much, many things to come will have a bigger impact, such as the Character GUI.

Friday Facts #329 - Campaign reassessment

Posted by Klonan, Abregado, V453000, Wheybags on 2020-01-10

Merch store open again Klonan Our e-shop is now open again after taking a break over the holidays and new year. We have also restocked our new Factorio sew-on patches, so if you didn't manage to pick one up over the last weeks, now is your chance to order one.

Friday Facts #320 - Color correction

Posted by Albert, V453000 on 2019-11-08

Color correction Albert, V453000 Factorio is in a state that even though is not yet finished, it is very close to its 1.0 version. That means that most of the work is done and we are polishing the game in order to make it bright. That's what we've been doing for the past 2 weeks. Literally making it bright. Since years I wanted to do this post-production work. But I didn't dare to do it until most of the graphics were finished. I was afraid of breaking the consistency of the look and our production pipeline. Now it's different. There's only a couple of entities to re-design and some other stuff to do, but in general this missing details are not affecting the possibility of working in the post-production. Factorio is a dark game. I mean conceptually. All these things about industrializing a planet, polluting an entire world just for the sake of the factory, and killing all its inhabitants are not precisely happy concepts full of light. This old article could explain better my thoughts regarding this concept. But the look of the game was dark, too dark. So we cleaned it up without betraying its spirit. Like restoring an old painting. The difference can be subtle, but very effective. We added more light, and a little bit of color saturation. Adding these general changes to the entire sprites collection is not an easy task. Many sprites were badly affected by this general correction. V453000 was fixing individually the broken sprites and icons in order to keep the consistency with the new context. We took the chance to work on the terrain a bit further. Not only this color correction was applied, but the contrast and integration with other terrains was also improved. Also experimenting with the color of the trees, trying to achieve a more colorful feeling with the excuse of an alien planet. I have to say the Alien Biomes mod was opening my mind - a little - to experiment with the color a bit further. In order to break this general brown feeling, we added a more orange tonality to the sand biome. Here is where you can see the difference more. Going further to too saturated colors is dangerous, after all, the terrain is a background that should provide a good and comfortable contrast with the entities and the icons. Touching terrain colours means touching map colors also. We were very keen to keep the visibility of the map information and the similarity with the terrain. The result is a more vibrant look in the entire game. We tweaked the night also. Thanks to posila and Wheybags, we can use LUTs (Look up tables) to dynamically modify the colors. Instead of playing with the alpha channel of a solid black layer on top of the game. Now we can gradually move to a different color palette for night with more control. So the colors are losing their saturation and becoming more blue and cold. This is important, because part of the annoying darkness of the game comes from this black layer. We are still experimenting with this LUT, and the transitions of day/night cycles. I'm pretty sure also that I will have to touch the map colors for some missing details and fine tuning. Possibly there is some entity that is not in its best shape with these new color palettes, and maybe we keep tweaking the terrain. But I feel very confident with these additions and I'm very sure that these changes will improve the experience of playing Factorio. After playing with these colors, the feeling is good. I hope you see it the same way.

Friday Facts #311 - New remnants 3

Posted by Albert, Dom, V453000, Bilka on 2019-09-06

Hello, Another week has elapsed, which brings us another week deeper into the declining weather of autumn.

Friday Facts #305 - The Oil Changes

Posted by Rseding, V453000 on 2019-07-26

Lua Mod GUI additions Rseding Mod GUIs have been an interesting part of Factorio modding since I started working at Wube. They allow scenarios and mods to add GUIs that look and feel like the base game. When someone new to Factorio modding is introduced to how they function, they almost always have the same questions: Why is mod GUI part of the game state? Why do mod GUIs need to be deterministic? How can I edit the base game GUIs? And then comes the explanation: The actual widgets are not part of the game state and are not deterministic. The part that mods have access to however is. In an environment where mods have to operate deterministically, if a mod is allowed to read some data that data must be deterministic. In that simple bit of logic; if a mod can read the checked state of a checkbox then that checked state needs to be deterministic. If the mod didn't have access to read that state it would need to store the last-known state and update it every time it got the changed event. Try to imagine that: every single mod implementing their own system for remembering last-known-state about GUIs they're using. Instead of leaving that entire mess to mod developers we decided long ago that we would manage that "last-known-state" for them. The basic data about what a given mod wanted to show on screen is recorded so mods can read and change it as they want and not need to be concerned with constantly updating it every time some changed event happens. Additionally it means that the game can use that "last known state" to restore what the player sees if they save, quit, and load the game. That still leaves the last question: "How can I edit the base game GUIs?". Using the above example it's much easier to explain that: as a mod - you can't. The base game GUIs are not implemented using this same system - they're just pure collections of widgets. None of the "last known state" is saved anywhere and it's all lost when saving, quitting, and loading. However, that leaves a divide: we need to implement each widget type through the "CustomGui" system in order for mods to be able to use them. With this latest release I finally figured out a way to do tabbed panes since they're special in how they work compared to everything else. Additionally I figured out a semi-friendly way for mods to put things directly on the screen in a way that the player can drag them around - instead of being limited to some fixed area (left, top, center, etc). Another system which I've been thinking about for quite some time is some way for mods to position GUI elements relative to base game GUIs. For example: a mod wants to add a pane which shows on the left of the character inventory GUI. Currently it's not possible - the base game GUI isn't readable by mods so they can't do anything with it. My idea is some system where a mod can say "I want to add this GUI, and I want it to be shown relative to the character GUI on the left side" and then any time the character GUI is shown it would also show the mod GUI. There are some critical parts to this new system. It needs to: Be easy to expand (either automatically works with all new base game GUIs or works with minimal effort). Not break with simple refactoring. Not cause other programmers trouble by existing. Not prevent base game GUIs from working how they need to work. So far none of it seems impossible. I don't know when I'll have it working, but I'm looking forward to what mods will do with it.

Friday Facts #304 - Small bugs; Big changes

Posted by Klonan, Sanqui, V453000, Posila, Twinsen on 2019-07-19

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.

Friday Facts #301 - Crash site: First state

Posted by Ernestas, V453000, Albert, Rseding on 2019-06-28

Crash site: First state Ernestas, V453000, Albert For many weeks now the GFX department has been focused on preparing replacements for the placeholder graphics of the campaign crash site. The subject as usual is not that easy because we had to first solve the main concept of the crash site. It happens that those new entities belong to the Factorio universe, but they come from a different reality than the usual DIY/diesel punk of the game. So we had to invent a new way to design machines that look like Factorio but that are not too familiar. Here a proof of concept of the look: The concept is that the big (medium) spaceship broke into pieces as it crash landed, and lost many components that the player, during the introduction, will repair and use for his own profit. The look of the spaceship remnants are a little bit based on the designs of the 60’s/70’s pulp Sci-Fi. Fortunately we can keep the look of Factorio due the accident, which allows us to destroy and dirty up the machines show many inner mechanical details. It is also part of the concept that all the machines that the player builds, are based on an existing technology from his home planet. So the machines that we see in the regular game are like 'cheap' versions of the original ones. For the lab, we keep the dome shape and the beams inside in order to keep consistency with the regular laboratory. So slowly the player gets used to the meaning of the shapes. The generator is similar to a substation -more or less-, connectable like a pole but it also produces electricity. Sometimes we really have to invent. This works like an assembling machine. The design is more based in the (yet unshown) redesign of the assembling machines, rather than on the actual 'classic' ones. These cylinders are like chests. We decided to make them cylindrical instead of a box for this difference in technology level that we are speaking about. The player will recognize them for the shape, color, and they also always have a number printed. You don’t really want to know the meaning of the numbers. All this new content is a work in progress, and we made these new entities first for the testing of the campaign. Based on feedback with testers we will have the chance to tweak and adapt whatever is necessary. In the case of the introduction, the positioning of the entities can have a large impact on the flow of the gameplay. Once we are more sure of the final placement, we can see how all the pieces will fit together. The next round for the crash site is the main crashed spaceship, and some other assets that converts the scene into a full composition, more proper for the introduction of the game.