# Server Performance :::info If anything you are doing or have built has been identified to be significantly impacting server performance, you will be contacted by staff and given a reasonable timeline to address the issue. For more information, see [Server Rules](/doc/e5a06237-78e8-41fe-837d-1c34db4084ce) ::: To keep sim-speed high, we ask that players remain considerate of server performance. This page contains details of features and settings designed to improve performance that you should be aware of, along with tips for avoiding performance pitfalls. # Performance features ## Concealment When a grid is more than 25km away from any player, it will be *Concealed*. Updates for the grid will be paused to reduce server load, causing blocks such as thrusters or programmable blocks to freeze in time and stop working. When you return to the grid or respawn on it, it will be unconcealed and updates will resume. :::warning Physics may continue to be simulated when a grid is concealed, causing it to continue moving. If your grid is in a gravity well, dampeners may not function and it may fall and crash. ::: If a grid has been converted to a station and has one or more active refineries (but not basic refineries), it will remain exempt from concealment to enable offline refining. Abusing refineries to keep a grid out of concealment is considered a breach of performance rules. ## Selective physics Physics simulation is split into *clusters*, with each cluster containing grids or physics objects in close proximity to each other. When a cluster doesn’t have a player nearby, selective physics means it will be frozen to save resources. ## Auto-hangar If a player is offline for more than 24h, any grids they own will be removed from the world and put into their personal [Hangars](/doc/9d4e7e8d-2e28-4fc1-a53b-1375bc763b85). Grids being auto-hangared that were freshly pulled out of Faction Hangar will go back into FH. This feature resets after server restart. # Performance pitfalls ## Clustering Grids that are physically too close to each other can cause excessive physics calculations. Even a small collection of 3 or more grids can start to create a ***big*** impact on the server as a whole, bringing sim down by 10-30% *per instance of clustering.* It is very, very important for server performance to keep ***any and all*** grids that are not ***currently, actively needed in that very moment*** at least 1.5km away from any other grids and voxels. There is no hard limit that can be applied to number of grids clustered: we have seen players with clusters of 6 have a smaller impact on server performance than a player with a cluster of 3. If staff identify a cluster as a potential source of impact to simspeed, you may be asked to spread the grids out. While converting a Large Grid to Station, or using landing gear or connectors to dock ships together reduces these calculations somewhat, it is often not enough of a reduction in calculations to prevent impacts to server performance. It only takes \~60 seconds to fly 10km in a suit to your grid, so spread your grids apart to avoid clustering. ## Subgrids Rotors, pistons, hinges and wheels all create subgrids - a secondary grid that is physically anchored to a parent grid. Subgrids are *terrible* for performance, as they are in proximity to another grid at all times, causing passively expensive physics calculations. While we do not entirely prohibit subgrids, we request that they are kept to a minimum, and strongly recommend avoiding multi-subgrid contraptions. On Expanse, the static sun means there is no need for rotor-mounted solar panels. Wide-area welders also mean there is no need to make complex welder arms. ## Projectors Please disable projectors when not in use. Active projections require the game to load and maintain a separate copy of the projected grid, which will regularly check to see whether any of the projected blocks need repair or update. For large grids these costs add up fast. ## Conveyor junctions and networks When calculating the conveyor network for a grid, Space Engineers checks every connectable face of every conveyor block. This makes the 6-sided vanilla conveyor junction terrible for performance if used en-masse. For best performance, always use conveyor blocks with the minimum number of sides possible, and use long conveyors rather than a line of short ones. We have provided a set of custom conveyor blocks with all possible combinations of faces and a variety of lengths to make this easy to achieve. ## Ramming Ramming near voxels generates a large amount of strain for the server as it tries to calculate physics, which can cause other bugs and issues (such as sinking into voxels or more) to present themselves more readily. Due to this it is heavily advised to not ram a grid within 500m of voxels. ## Physics shapes The physics engine checks collisions using *shapes*, which are simple 3D objects such as cubes, cylinders, or low-poly meshes. Every block on a grid contributes to the total shape count of the overall grid, which is visible in the Info terminal. The higher the shape count, the more expensive it is to simulate the physics for it. Certain blocks such as beams are known to have a high shape count, and can cause significant performance issues if used in large quantities. This is especially true for miners, where their frequent proximity to voxels causes a lot of expensive collision checks. Where possible, we ask that you keep physics shape count in mind while designing grids, and avoid using large quantities of high-shape blocks.