Read about our automated cleanup systems and what you can do to prevent your ship from being deleted!
In an effort to provide better transparency as well as consistency in support experiences, we have built this list of example restore / no restore situations that both Staff and Players will be able to reference. Unless otherwise specified by a server cluster, restore policy of grids is as follows.
Note: Grid restores are only ever from server backups, *never* from a player provided blueprint. If a server backup does not exist, no restore can be provided. Players get a single “oopsie” restore every 30 days for player error. This cannot be used for combat (PVP or PVE) losses. “Oopsies” are per server cluster (IE: An oopsie in Expanse does not use up your oopsie in DI:Enduur)
If you are unsure if your scenario falls under one of the below you can always open a ticket and ask about a restore. We are always happy to at least look and confirm why a grid disappeared, as there is no way to learn from mistakes otherwise. We will work on evolving this list as time goes on to maximize clarity.
To reduce strain on the server, we restrict the Total counts of Some Blocks by Player and Grid across all servers in the cluster. This means player limits are cumulative across all servers. Currently, the player facing tooling we have only allows players to view per-instance limits, they will need to account for their limits - especially when sharing grids and limits with faction members. Staff has tracking methods internally, repeat offenders will have their grids removed without compensation / further discipline as needed.
These limits are unique from the 100 functional block limit
Blocklimits are listed on a servers specific rule page
To reduce server strain, grids belonging to someone that hasn't logged in for some time will be forced to the Garage for storage. Length of grace can vary by server cluster.
In the Draconis cluster, we strive to avoid limitations as much as possible. This is why we have unlimited world PCU available to players (though there are limits per grid / what can be stored in your hangar). With great creative power, however, comes great creative responsibility. There are a number of things we might do, completely innocently, that will unfortunately have an inordinate impact on the server as a whole. To keep the server fun and playable for all of us, here are a few things to watch out for as you get started.
The Respawn Ships are solely intended as a (generous) starting platform for beginner players to start their play in the Draconis Cluster.
As an example - Due to earlier exploitation of the mechanic by players, we were forced to increase the respawn timer to an almost obscene degree- at the time to prevent spawning of the rovers to throw them against PvP encounters.
Let's clarify a couple of things clear on it - but this is not an all inclusive list –
If you are unsure if your actions fit in this policy, the question to ask yourself is: "Am I using this as my generous starting platform to begin my play in Sigma Draconis or to help myself out of a bind where their existing grids are stuck (such as a medbay out of power and getting a new ship over to it, or having all your assets destroyed)?"
If the answer to this question is "no", a respawn ship should not be used.
Do not attempt to keep duped ships, just as lost ships and tracked and restored, duplicates are also tracked and removed. If you attempt to hide the duplicate ship you will be punished, including perma-banned. We do our best to quickly resolve ships lost to server issues and expect players to quickly remove duplicates they receive from server issues. You can use the !h save and !h remove # commands to easily remove them.
Indiscriminate Orbital Bombardment of planets causes a massive drop in SIM and inconveniences everyone. This would include dropping quantities of blocks, rotor/piston heads, other grid related bombing methods, etc. Tactical Targeting of strategic emplacements is allowed.
This is handled on a case-by-case review
Like most modded multiplayer servers for Space Engineers, many of our servers use the Torch Concealment Plugin. This plugin pauses the processing of grids (not physics!) that are not near active online players and stops them from affecting sim speed. This pauses blocks like antennas, thrusters, power generators, programmable blocks, prevents dampeners from functioning, and more.
Production blocks (assembler, refinery, etc)
Projectors have a *million* uses and are incredibly handy tools. Unfortunately, there are some very specific issues tied to Projectors that compels us to try and use them in a certain way.
For these reasons and others, we ask that Projectors are deployed as temporary tools, and be destroyed when you are done. This still allows for things like self-repair warships or PMW's, but please get in the habit of placing and aligning a fresh Projector each time you take your warship out, and grinding it down when done with your operation. We manually delete projectors as needed to help mitigate these issues. Don't use a projector block structurally to hold things together / hold your beacon on or you might get cleaned up after projector removal.
We currently employ a plugin to help aid in these projector issues that performs the following duties:
These conveyor junction blocks in vanilla are the only way to do anything other than a straight connection or 90 degree turn, as well as providing attachment on all faces. So, many engineers get in the habit of using a lot of them, or even using them exclusively. You will find many workshop designs *packed* with conveyor junctions. Unfortunately due to the way Keen decided to compute connections between blocks through conveyors, *every single face of every single Junction is being checked on every possible path every single tick.* This also means building cubes / bad conveyor networks can also have a hugely detrimental effect to sim. Here's a very extreme example of bad conveyor network
It is important to minimize the use of Junctions, using them only when absolutely necessary in your designs. Luckily, one of the mods we use (armored conveyors) vastly expands the conveyor options, including many full-block versions with 6 attachment faces just like a Junction. Make sure as you start your designs in Draconis that you take advantage of this mod and move away from Junction spam. Likewise, watch out if you plan to use Workshop ships, you will probably need to update their conveyoring!
Clustering has two sides to it – Grids that are physically too close to each other, causing excessive physics calculations; and the number of grids within sync range of each other. Both of these sides are highly important to keep in mind when making decisions on the server.
Every grid in the game, no matter how small or simple, is having physics and other calculations done for it every tick. Even if it is a small grid, 2000 PCU ship sitting completely still and idle, it is taking processing time from the server. 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. Beyond the physics being done between grids that are too close to each other, simply having an idle grid loaded in the world when it's not being used, when compounded across the number of players we typically see in our servers, can add up very quickly to a poor experience for everyone.
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, and any grids not being used within the next hour or more out past concealment range (>20km) or preferably stored in your hangar. 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 identifies a cluster 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.
In space by default (i.e. not modded jetpack), it only takes ~60 seconds to fly 10km in a suit to your grid - so spread your grids apart to avoid clustering.
Tip: if you have many grids of the same size (large/small), consider using merge blocks to temporarily make them a single grid and avoid clustering. You can always unmerge later.
Grids that are concealed still do physics calculations - so just because you are offline or your player is not currently near the grids, Grids still need to be spread out 1.5km apart to not impact performance for everyone.
It is important to remember that the server is simulating for multiple and perhaps many people at once. One of the implications of this, is that projects and builds that may have worked just fine when they were the only thing loaded into the world in your offline game are simply not a good or feasible idea in the multiplayer environment. Daisy-chaining subgrids is one common practice that while somewhat possible offline, gets much more risky in our server environment. When the game is at heavy load, things that would normally get full and accurate calculations start to use rounding out of necessity. These rounding errors, when present in a sensitive simulation such as a precarious drilling array of multiple rotors and pistons, can lead to the game believing something is somewhere it shouldn't be, and explosively "correcting" that issue.
Likewise, complicated subgrid arrays when coupled with the Concealment plugin can lead to some very-undesirable results.
While there are lots of cool, intricate, and complex subgrid-based creations out there in the Space Engineers universe, they are simply categorically inappropriate to attempt in the server environment.
The contraptions called 'clang drives' are banned on this server, attempted use of them may result in you being banned.
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 of grid within 500m of voxels (or into voxels). Servers may further restrict this in their own rule set.
In this category of creations and behaviors we find all sorts of neat ideas that, similar to Clang Contraptions, are unfortunately just not a prudent choice in the server environment. This includes but is not limited to things like "Clang Drives" that leverage merge blocks to generate "thrust,"; Mass-Shifting drives; Rotor-displacement-cannons; and all similar practices. Please lock rotors when not in use or not needed to improve server performance.
If you are about to attempt something that might fall into this category, stop, think, and please ask a member of staff about what you intend to do before you start.
To note, Gravity Drives are acceptable for use as long as they are well-made. As far as server performance, use less gravity generators and more artificial mass.
Using subgrids or connected grids for shields is also not allowed, this means you cannot dock or attach other grids with shields on (unless its a temporoary dock to reload/refuel) to your grid.. However, flying grids in a formation is allowed as long as you follow our clustering rules.
Scripting on the server is a privilege. We grant it to anyone that asks for it, but if we find someone impacting server performance with scripts and not responsive to requests to adjust what they are using, we will revoke it.
Additionally, we are running a server plugin that monitors the execution time of scripts. If they exceed a set amount (0.5ms cumulative of PB's owned by a player) per execution cycle, then the plugin will turn off the programming block and/or damage it.
We ask that if your programming blocks are 'overheating' that you step back and think about less impactful ways to get the result you are looking for. That may mean adjusting script settings, or looking for alternative scripts, or trying to find a non script method such as conveyor sorters.
Sometimes when we are investigating low Sim issues we may turn off programmable blocks.
Faction names and tags are typically unique to each group of players. However, we have seen issues with player history that has led to “hostage holding” of faction names for ransom or as a type of revenge against other players. In the event of this, it is recommended that players open a ticket.
Players may request the name or tag of an inactive faction via ticket. The players must state the reasoning for why they request the name/tag. If the tag or name is believed to be “hostage held” it is upon the staffs responsibility to push the ticket to a supervisor, CL, or green for review and handling.
Staff may, upon ticket request and validity of claim or inactivity proven, give the faction name or tag to the player(s) requested faction if the below criteria is met:
Factions may not request this more than once in a wipe. Please keep in mind that all of the above is up to the staffs discretion and does not entitle any players or factions to their name or tag.
We have not and will not spell out a list of all exploits that are forbidden. That is a game of whack-a-mole that we don't wish to spend the time or energy on. They are instead covered by other rules generally. Use of exploits is bullshit we will not put up with, use of them makes you an asshole, and some exploits take advantage of straining the server. We will touch on a few broad categories of exploits that there have been some confusion over in the past.
This is NOT an all inclusive list. Please do not waste time lawyering us.