We believe this major overhaul of Stationeers was a necessary investment to help the project reach the wider audience it deserves. However, bringing this update to you meant taking a huge risk: pausing our regular 2-3 week updates. This has a direct financial cost, as player numbers and revenue taper off immediately without them. This project has always been more than just a job; it's taught us so much about development and, most importantly, how to build a meaningful relationship with you, our community. We've always strived to be transparent, and you've repaid us by being incredibly active and supportive. We believe this update can bring in many new players and this is where you can make a huge difference:
Spread the word: Make some noise on socials like Reddit and recommend Stationeers to everyone you think might enjoy it.
Welcome new players: Continue being the engaging and welcoming community that you are.
Leave a review: If you haven't already, please consider leaving a review for the game!
Support us directly: If you want to support us in the most impactful way, please consider purchasing our DLC.
Simon Brown - Project Lead
Your support makes these updates possible
https://store.steampowered.com/bundle/2624/Stationeers_Complete_the_Set/
The Terrain
We had to rewrite the terrain system to resolve some extremely buggy behavior as well as performance issues caused by even small amounts of exploration within the game. We did this by moving a lot of the terrain tasks to make better utilization of your GPU and have frontloaded a lot of the ram usage.
There are a number of new or changed settings. Two of the major ones that have an impact on performance are Tessellation, Shadows, and Distance Shadows.
This Stationeers update completely redefines the how terrain looks, how the game performs, and how connected you feel to the world while playing. Pictures below will do the speaking, but the new terrain looks amazing, and blows the previous worlds away. The maps are now hand authored with meaningful thought put into kilometers of expanses to explore. Yet at the same time, with this new approach performance has increased, terrain hitching has disappeared, and save files are a tiny fraction of what they used to be.
{STEAM_CLAN_IMAGE}/28304711/b027244ba8ef9f89063a6b8f8b844797a167ab64.png
A New Look
The terrain is rendered with a completely new material that supports a range of features. The largest improvement is the ability for multiple sets of textures, representing multiple voxel types, to dynamically blend together. This is leveraged in many different ways and is a powerful tool for creating new and interesting planets. For example, on Vulcan there’s glowing rocks around the lava, while on Europa there’s a thick layer of ice and snow contrasting the black rock that lays beneath.
{STEAM_CLAN_IMAGE}/28304711/44be34d835f98de8dc5df9cbbbb9de1ee345b075.jpg
Regions
The maps are layered with regions that are used for different things, including names to help you become familiar with the maps and navigating. Additionally, points of interest add flavor, and more functional things such as deep mining regions and playarea bounds.
{STEAM_CLAN_IMAGE}/28304711/801597cfa3f572d875b24ab36f54ad39a10ef115.jpg
View Distance
The new terrain system can render kilometers of voxel landscape. Multiple voxel types can create mountain vistas with contrasting rocky peaks and snow layers. The voxel system also allows us to create several layers of perfectly integrated LoDs of decreasing resolution. With the old system the view distance was limited by the culling system and terrain loading requirements. This previously resulted in a short terrain rendering distance which was stitched together with a very low resolution distant terrain mesh.
{STEAM_CLAN_IMAGE}/28304711/572a839bb41233dc46df6d43435f8244cbe13445.png
Looking about 1.5km along the mars canyon
Underlying Data Structure
At the core of this update is the shift from a 8x8x8 voxel chunks to a voxel 'octree'. While the old system required data for every single voxel, data in the octree is only present where it needs to be. Large solid underground or open-air areas result in very little data needing to be stored. Only where there is actually complex topology does the data storage get more dense.
Multiple data structures are used to achieve the final terrain while avoiding performance problems. The world voxel data, which is a fixed size in memory and never changes allows for quick access due to its static nature. This is combined with another ‘delta’ octree, which starts empty and records the changes in the terrain. When the terrain is modified, we only dirty the delta octree. When we render or interact with the terrain we read first from the delta octree, and if nothing is there, we read from the read-only world data. Additionally, ore veins are now defined in their own tree-like data structure to not dirty the voxel structure unnecessarily. This provides us with definitions and controls to make them generate in continuous structures that subtly make mining different ores feel unique.
{STEAM_CLAN_IMAGE}/28304711/54e943e2cc84fcfc307b1e19e934d86a5afd1483.gif
A visualization of how an octree segments the data
Moddability
A foundational goal for this overhaul was to make the entire world-creation process moddable and data-driven. We built a toolchain that allows anyone to create a world without ever needing to open the Unity game engine editor. We used this same process for our official maps; assets were generated in external tools and then imported directly into the built game. This opens the door for the community to use free tools to create and share entirely new worlds. However, be aware that generating a world is a memory and CPU-intensive process, so powerful hardware is recommended for it to complete quickly.
{STEAM_CLAN_IMAGE}/28304711/44ea12617c917068189b26f27775975bf688c95e.jpg
Worlds With Meaning
We’ve always wanted Stationeers to invoke a sense of exploration. Landing on a hostile planet and needing to construct systems to stay alive makes the planet the core antagonist. However, the previous terrain system just wasn’t up to task, as we discovered with our attempts to make Loulan an interesting place. Greater stress placed on the terrain and exploration would functionally remove performance that was needed for the base game. But with the new approach to world creation, we had the ability to make each map much more its own character.
Instead of the map being generated from random noise, each mountain can now feel unique. When you travel, you get a sense of position, and recognize far away features as points of reference. There are now vast frozen lakebeds, map dividing canyons, or towering ridges for the player to see and traverse. Additionally, we’ve used the opportunity to create biome like regions, named points of interest, and unique areas with ore distribution changes. This all contributes to you feeling much more connected to the map, and actually feeling like you are going somewhere else when you travel.
The Maps
We needed to redesign each of the planets in this new paradigm, but we didn't want to lose what made the old worlds unique. Rather than trying to replicate any specific elements of the old terrain properties, we used the mood that the old planets invoked to define the baseline for the new planets. Instead of trying to cram too much into one map, we made each world’s terrain interesting, believably consistent. The choices of terrain features didn't have to be the definition of the planet, since there are so many intriguing map ideas for us to make. This decision allows us in the future to create even more maps for planets without having to completely change what already exists.
Mars: The Canyon
We identified early on that one of the things that made the worlds feel different was the silhouette of the horizon. For Mars we wanted to maintain its characteristic rolling small hills that build into larger ones. With the new voxel types we were able to give it rockfaces and cliffs that gives it an open epic vibe. On of the test maps we used initially was a height scan of the Grand Canyon which we really liked and we decided to integrate a massive canyon into the Mars map as well.
{STEAM_CLAN_IMAGE}/28304711/0489b64ab7b584b1f7d3ebb838f4428a7e97972f.png
Moon: Great Mare
The Lunar map was the first map we tackled and felt like it was an easy choice as there was not a lot of unknowns. We knew we wanted it to be a relatively flat surface cluttered with craters. To make it more interesting the map is set on the edge of a mare with some dramatic height elevation that cuts across the map.
{STEAM_CLAN_IMAGE}/28304711/4993de942017e0134a2731a5868c700fbbdccefc.png
Mimas: Impact
We considered the old Mimas felt a bit like a ‘Moon 2' but were not going to just replicate the moon for the new one. At its core it’s still a crater-ridden terrain but Mimas's point of difference is dramatic craters that rise much further up, and it features a crater so large that you barely know you’re in it if you’re standing near the center.
{STEAM_CLAN_IMAGE}/28304711/36d2b968cdcbd7179db627b8af56a49194e8068e.png
Europa: Colosseum
This is an example of us taking a dramatically different route. Europa is completely covered in snow with rocky, exposed mountainous ranges. Initially we wanted to create some areas that were representative of the original Europa with massive ice spikes, but it did not feel right and was hard to make work technically. This was a good example of us working to the limitations of what we built and playing and iterating with the world building team until we were satisfied. We had an awesome time playing on Europa for over two weeks and we only saw a fraction of the map.
{STEAM_CLAN_IMAGE}/28304711/5ae60407d4bb87abb913a5f7e8ce900bf88b7295.png
Venus: Miasma
When looking at the old version of Venus the core feeling was best described as oppressive. We leaned into that with steep, towering, hostile ridged mountains permeating the map. The only respite from these mountains are the occasional shallow basins with toxic looking terrain colors, as well as dried up sulfur flats.
{STEAM_CLAN_IMAGE}/28304711/47c1b8386481fb3f8ce5679615b9a63345bc2a23.png
Vulcan: Foundry
The old Vulcan map was probably the most unique of the old planets and invoked a feeling that we wanted to fully capture in the new map. Everyone on the team felt that it was important to get this one right, so we slowed down and decided to expand our world building feature set to allow for more interesting lava and the ability to add fractures. The map itself went through many iterations until we landed on a craggy landscape covered in fractures and giant volcanoes. The lava means you can’t dig down too far, while the hostile landscape and environment make it hard to traverse on mining missions.
{STEAM_CLAN_IMAGE}/28304711/6a494e5650f372ee3db1bf5cfdf28d04a09f0b31.png
Out with the Old
Our previous terrain system had a critical flaw: it never unloaded parts of the world from memory. The more you explored, the more RAM the game would permanently consume, leading to unavoidable performance degradation. This functionally limited how far you could travel before the game became unstable. This core inefficiency led to other problems, such as bloated save files with long load times and noticeable in-game 'hitching' when actions like mining or explosions occurred.
Creatively, the system was a dead end; while the worlds were procedurally-generated, they were also homogeneous, with almost no meaningful variance. Traveling in any direction presented more of the same landscape, which limited the feeling of true exploration and prevented us from creating the unique, authored experiences we envisioned.
{STEAM_CLAN_IMAGE}/28304711/0cc9366b1b215c22170e2baddbbe97631868abf3.png
{STEAM_CLAN_IMAGE}/28304711/d4b649258cbdc3e4244ed75b0729517f42b3975c.png
New Save System
The old save system was often described as unintuitive. It had confusing components, such as the backup system, which didn't always behave how people expected. A single save file misunderstanding could ruin hours of work and sour a day-long play session. So, there are two main new concepts to understand about the new save system - save files are now compressed into a single .save file and the save file structure has been changed to be a lot clearer.
The different kinds of saves we have are:
{STEAM_CLAN_IMAGE}/28304711/bdfc9f84e457cc02758f090be75719e412587061.png
The save menu has been significantly updated, and each of these save types are displayed visually differently in the expanded save menu, to help you better understand your saves. In normal practice when restarting the game, you don't need to even expand this advanced save information, and just pressing the load button will continue your game.
{STEAM_CLAN_IMAGE}/28304711/b8ccada6e66834f8439e8abfeb8847e0ead43033.png
Save Transformer
With all the changes to the terrain and save systems all previous saves are broken. The community has already created various tools for porting your old saves. Here's a link
to JacksonTheMaster's(Discord Handle) tool. There's also a workshop mod that you can find from this website.
Stationeers Save Transformer by
JacksonTheMaster
{STEAM_CLAN_IMAGE}/28304711/f61cf4b3b4f6222bc26a859727c20971cfa56368.png
Multiplayer
We highly recommend not connecting using Steam P2P for multiplayer as it can cause desyncs and is not nearly as reliable. If the game tries to connect via Steam P2P you will be warned in game.
A major cause of client-side hitching was fixed: a bug that caused unnecessary waiting for atmospheric network updates. In our tests on large bases, this eliminated a 20-30ms frame spike that was occurring twice a second.
{STEAM_CLAN_IMAGE}/28304711/0a67f00f696052a8ffe68c46b0bc3c396d59e463.jpg
You may have caught EJ playing Stationeers with up to 20 players recently. Check out his Twitch here.
Beyond this, we made dozens of small changes and fixes that massively improve the multiplayer experience. Connecting to and disconnecting from servers is now much smoother and more reliable. During our internal playthroughs, once we had made these improvements, we regularly had up to 10 players online at once without any issues.
Community Walkthroughs
Three excellent walkthroughs using our tutorial system (Airlock, Smelting, and Manufacturing) made by community member,
BigFootMSR(with his approval), have been officially integrated into the base game. Give him a big thanks for helping explain some of the more advanced parts of the game to new players.
Project Clinic Improvements
At RocketWerkz one of the most important things we do is play our games. Once we had our first new terrain complete enough to play, Europa, we stopped our regular development for over two weeks to simply play. Playing the game the same way as customers allows us to see where the game actually needs work. This is the core foundation for what we call project clinics. So, besides the Terrain work we have done a massive amount of bug fixing, adding content, as well as hardening and improving systems.
Beyond bigger stuff like the save and multiplayer improvements bellow you can quick fire list of all the things we’ve added or changed:
Move All Inventory Actions
You can now hold Left Control while dragging to move all items in a container, or hold Left Shift to move all items of the same type.
{STEAM_CLAN_IMAGE}/28304711/8e76876df2e53404f18b9dafba2b3bd16f875d4f.gif
DensePool
A common cause of stuttering in complex bases is the process of adding and removing objects from large lists. To solve this, we implemented a new high performance data structure we call a DensePool. This system uses a "swap and pop" method, ensuring that our lists of objects are always kept tightly packed and efficient. We've refactored nearly every major system in the game to use these DensePools, resulting in a significant reduction in stuttering and memory usage, especially for large bases and busy multiplayer servers.
Multi-block Pipes and Chutes
Something that has been long requested, and during the construction of a big and spread-out base we once again saw a need for long pipe segments. While this is handy from a station construction point of view, it significantly helps reduce the number of things in the world which has a non-trivial performance impact. We then expanded this to also include chutes, which have a higher performance cost than pipes.
{STEAM_CLAN_IMAGE}/28304711/01480267d2ec6b423a6a880d849dcab42df1f759.png
Logic System Upgrades
For our dedicated IC10 architects, this update delivers one of the most significant expansions to the logic system yet. We've focused on making your code simpler to write, more powerful, and far more intelligent, allowing you to create robust scripts that can dynamically adapt to their environment without throwing errors.
Streamlined Code with Direct Addressing
We've fundamentally streamlined how you reference devices. Previously, to read a variable from a specific device, you often had to load that device's ID into a register and then use a dedicated instruction like
ld.
Now, core instructions like
l (load),
s (store), and all device branching instructions have been upgraded to support Direct Addressing. This means the instruction itself is smart enough to know if you're giving it a register, a device screw (like
d0), or a raw Device ID. In short, you can skip the middleman, which makes your code cleaner and more intuitive.
Here's a practical example:
# THE OLD WAY
# You had to use 'ld' after moving the ID into a register.
move r0 123456789 # Move the Reference ID of a switch into r0
ld r1 r0 Open # Load the 'Open' state
# THE NEW, SIMPLER WAY
# The 'l' instruction now does it all.
# You can use the ID directly, or an alias.
alias myswitch 123456789
l r1 myswitch Open # Load the 'Open' state directly
Smarter Scripts with Dynamic Device Checking
We're also introducing powerful new branching instructions that allow your script to ask a device a question before trying to interact with it: "Can this variable even be read?" or "Is this variable writable?". This prevents your script from throwing an error and halting, allowing you to create universal scripts that can intelligently check what a device is capable of.
bdnvl
Branch if Device Not Valid to Load: Jumps to the specified line if the logicType on the device is not readable.
bdnvs
Branch if Device Not Valid to Store: Jumps to the specified line if the logicType on the device is not writable.
New Tools and Helpers
We've also expanded your creative toolkit with several new instructions. You can now create smooth value transitions using
LERP (Linear Interpolation), and perform highly efficient data packing with
EXT (Extract Bit Field) and
INS (Insert Bit Field).
To assist with complex calculations, the Universal Gas Constant (
rgas) and Tau (
tau) are now available as built-in constants. In the IC Editor, these constants and all your variables will now display their live numerical values in yellow text, making debugging much easier.
A New Lander
A lander replacement has been implemented that replaces the old one and bring it in line with the drop pod you spawn in.
{STEAM_CLAN_IMAGE}/28304711/ef88207ec917275846086b7d9b884d174539469b.png
Planetary Mapping System
{STEAM_CLAN_IMAGE}/28304711/27fdc3c87556717a458b5203f4156b81845eab9b.gif
A new gameplay loop has been added that allows you to scan and view the entire map. By building a Map Motherboard and connecting it to deep scanners, you can launch a rocket into orbit to slowly reveal the planetary surface on screen. This also allows you to toggle the deep ore region overlay, so you can find new regions with different deep ore mixes.
New Computers
To better display your new planetary discoveries, two new computer variants have been added: a standing and a wall mounted version. These provide an excellent canvas for the new Map Motherboard, which connects to your rocket's deep scanning head to reveal the planetary surface as it orbits.
{STEAM_CLAN_IMAGE}/28304711/1bc69291aa4d56ce6766e6746b39836b6cd06232.png
Rocket Gas Filtration Kit
This new machine is designed for harvesting resources directly from the atmospheric gas clouds of planets like Jupiter. To support this, you'll find new cloud mining nodes appearing on the space map.
{STEAM_CLAN_IMAGE}/28304711/6252fa854fa41b18303105f40bd9fa1fb084a6cb.png
Large Rocket Tanks
Two new large landing pad tanks have been added: a Gas and a Liquid variant. Each is 3x2x4, and holds 3000L.
{STEAM_CLAN_IMAGE}/28304711/a392d8b0303e05a9f1b76f99560db7464a94e2cb.png
Wide Airlock
A new, fully functional double-width (2x1) airlock, constructible from the Airlock kit.
{STEAM_CLAN_IMAGE}/28304711/b8b76378fe43463c401685a5e50a17293529866d.png
Logic PID Controller
A PID (Proportional-Integral-Derivative) controller is a powerful tool for automation. It constantly works to minimize the error between a desired setpoint and a measured variable, making it perfect for tasks like precisely regulating temperature or pressure.
{STEAM_CLAN_IMAGE}/28304711/fb0c6751407c1d8c9b3223afeb26367d66a6cdae.png
Compact IC Housing
A new, smaller IC housing variant with combined power and data connections for tighter placements.
{STEAM_CLAN_IMAGE}/28304711/d79b8089692300f99f89280f101b86dcb25d4251.png
Hard Hat
A new helmet that contains a built-in light.
{STEAM_CLAN_IMAGE}/28304711/579f19cef56a85e9dc0f1ca7f76ef740ee05e85f.png
Ice Crusher Rework
The Ice Crusher has been significantly reworked to be more intuitive, especially for new players who found the old version's lack of feedback confusing. It now features a new status panel that clearly displays what the machine is doing and any error states, a color-changing heating indicator light for at-a-glance feedback, and a physical temperature dial for direct and easy control over the heating process.
{STEAM_CLAN_IMAGE}/28304711/e975f24a624484c27221b1b550062a6905b25550.png
Cryotube & Sleeper Rework
The Sleeper now features a status panel that clearly shows how it works and if it's functioning correctly. The Cryotube has received a more significant overhaul and now requires a piped supply of cooled Liquid Nitrogen to operate. To make this new requirement clear, it includes an improved info panel that not only educates you on what's needed for it to function, but also displays critical medical data, including the organ damage values of any occupant.
{STEAM_CLAN_IMAGE}/28304711/d5c9f220210a160e2562c04d6bc48357abe269b6.png
Tracker Cartridge Upgrade
The functionality of the GPS Cartridge has been merged into the Tracker Cartridge. The old GPS Cartridge is now deprecated.
{STEAM_CLAN_IMAGE}/28304711/7501c55cc580df61daf6b80e34c3763e2249bd0f.png
LED Display Upgrades
LED displays can now be set to show units (Kelvin, Celsius, Pa, etc.) and can display short strings of text sent from an IC.
High-Speed Mining Drill Buffs
The mineral drill's speed boost has been increased from 120% to 150%, and the ice drill's boost has been increased from 20% to 50% to better justify their high energy costs.
Improved Computer Interaction
You can now use
Alt + click on computer screens, which makes UI interaction much smoother. This also allows you to open the IC editor while holding the laptop in your hand.
Emote Commands
You can now express yourself in-game with a range of new facial expressions, controlled via the emote console command. This system also includes automatic expressions for 'Death' and 'Unconscious' states for added immersion. The available commands are:
{STEAM_CLAN_IMAGE}/28304711/69370683b99d33da123cb74554f06d603bae2595.gif
{STEAM_CLAN_IMAGE}/28304711/3c666558849f43d440d45df20e904d6f6834c7f0.png
Known Issues
- Some explosions, such as canisters, do not destroying terrain
- The use of dr in IC10 scripts is not fully supported yet
- Some rich ore deposits are not working correctly on the moon map
Pre-Terrain Branch
We've locked of a branch on steam called 'preterrain'. You'll always be able to go back to this if you choose.
Change Log 0.2.5903.26007
This post is too long to display the change logs so we have create a pastebin containing all the changes:
pastebin.com/LsbVNS7X
