Space Engineers Global Policies

• Community Rules apply to all areas of Draconis

• Global SE Rules: These rules should be included in each SE server-specific rule page. Please let your friendly neighborhood admins know if something is amiss.

SE Server Specific Rule Pages

• Draconis Expanse Rules 🧊

• DI:Enduur 🤬

• Draconis Remnants Rules 🪐
  

• Draconis Vanilla+ Rules 🛰️
  

Getting Help

🧊🪐🛰️

Guiding Philosophy:

At Sigma Draconis Games (SDG) we strive to treat our players with an open hand vs a closed fist. Our staff members aim to enthusiastically help you with issues you encounter. 

Self Help:

Prior to opening a ticket please read over our list of player commands that could help solve your issue by reading SE - Troubleshooting and SDG SE Player Commands or using the command !longhelp in game. The helpful SDG player base may also help with questions posed in game chat or on the relevant Discord channels.

If you are unable to solve your issue, please open a ticket with our Staff by visiting our #🎫sigma-support channel on Discord. When submitting your ticket, choose the appropriate category. There is a time limit during creation before the ticket closes automatically. In cases of complex issues, it's helpful to compose your submission elsewhere (eg Notepad). Then, when ready, open the ticket and copy/paste what you wrote. Most tickets request information as listed below. Concisely and clearly providing details enables our staff to better help you in a timely manner:

Server Name:
Instance(if applicable):
Grid name(if applicable): 
Time & Date(If applicable/grid related issues):
Purpose of the Ticket:

Support Tickets are generally required for assistance with issues such as:

• Scripter Role: Scripting on the server is a privilege. We grant that role upon agreement to abide by our usage terms of service.

• Oopsie Restores: Once every 30 days. If already used, still ask, there may be extenuating circumstances. Worst case we say no. Review our SE Global Restore Policy for specifics.

• Server Crashes: Grid restores on server crashes.

• Engineering and grid bugs: Client desync not resolved with a relog, inability to spawn, stuck in cryo, ship unresponsive not fixed with !fixship, grids lost to automatic cleanup, etc.

• Player privileges: One-Time Supply Drop (where/when available), Patreon supporter role, access to test servers, Wiki contributor role, etc.

• Discord needs: Access to post in restricted channels like SDNN and Faction Advertising, etc.

• Sensitive information: Have a question or concern you don't feel comfortable asking in public (be it an exploit you found, concerns about another player, or even concerns about Staff), please feel free to open a ticket.

• Other Situations: The above is not a comprehensive list. When in doubt, ask. The answer may be no, but do not say no to yourself without giving us a chance to say yes. In some situations the answer may vary depending upon a variety of factors (player experience, staff availability, low/high ticket volume, etc).

Cleanup/Grid Preservation

🧊🪐🛰️

To keep things smooth and playable for all, we have a number of Automated Cleanup Systems that run, as well as some manual cleanup practices. To ensure that the stuff you want to keep doesn't get "cleaned," be sure to do the following:

• Ensure the grid is at least 25 blocks in size. (20 blocks on some clusters)

• Ensure not a single block is owned by "Nobody"

• Ensure the grid has a beacon (ship cores are beacons where applicable) placed

• Ensure the grid is renamed from its default (e.g. do not keep “Survival Pod” or “Rockhopper Mk. X”)

• Ensure the grid does not have the word "grid" anywhere in its name (case insensitive)

• Rename your starter ships- we occasionally cleanup grids named the same as our respawn grids- to avoid them being cleaned up please rename them.

• Check that ALL SUBGRIDS follow these requirements. (They do not need a beacon if the 'parent' grid has one and do not need an additional 25 blocks). Wheel subgrids are automatically re-named via a Draconis exclusive plugin we have.

• Check that ALL ATTACHED GRIDS follow these requirements.

• Starter ships are removed each restart to avoid this use the !fixrespawn command whilst looking at your grid

Please note that when working with merging merge blocks, one or both grids may be renamed back to the default Space Engineering "Large Gridxxxx" or "Small Gridxxxx", so check your grid names every time you un-merge or merge.

In addition, if a block is welded or ground while you are trying to rename a grid, the rename will not work. Be sure that welders and grinders are off when renaming.

SE Global Restore Policy

🧊🪐🛰️

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 on another server) DI:Enduur currently does not have "oopsie" restores on its server.

General examples we restore grids for

• Grids lost to new, confirmed bugs we have not warned players about via announcement (except for scenarios listed in the no-restore section)

• If the bug is unavoidable even after announcement, we may still restore for it

• Grids removed due to server crash

• Grids lost due to sector transit

• Grids that die immediately upon being loaded from Hangar (loaded into another grid, or loaded from hangar into voxels for example)

• Grids lost for cleanup reasons (1 per 30 days permitted)

General examples we DO NOT restore grids for

• Grid chunks cut off an auto-cleaned for being 2 blocks in size or less will not be comped/restored in any way

• Grids cleaned up for being <20 blocks in size can not be restored as no backups are created of grids that small

• Grids lost in a PvP encounter (exception for server side issues upon staff discretion)

• Grids lost in PvE encounters

• Grids lost in high risk area's (Example: KotH, exception for server side issues upon staff discretion)

• Player Inventories are not restored/comp on loss as we can not validate them in any way

We will usually not restore the following, but they are eligible for an “oopsie” restore, one per player per 30 days

• Grids lost to clang (physics issues, falling through planets, etc)

• Grids lost to crashing (hitting voxels, whether they were visible client-side or not)

• Grid jumped into an object (asteroid/trade station/other ship)

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.

Block Limits

🪐🛰️

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

• Only grids in the world count against limits (IE: Things stored in Quantum Hangar do not count)

• Limited blocks vary by server cluster

• Both player and grid limits apply at all times.

• Blocks must be owned by an active player.

  • If a player is not online for 10 days, any blocks they own on grids they are not the main owners of will revert to the grid owner. Grid owners are responsible for their limits still when this occurs.

• These numbers are cumulative across all blocks of their type

  • For example, if a grid is limited to 30 production blocks – 15 assemblers and 14 refineries and one O2/H2 Generator would hit the limit.

• Due to performance constraints, grids with a bounding box length greater than 1,000 meters in any direction are not permitted. This applies especially to attempts at extended conveyor systems and space elevators, which also may not be comprised of smaller, daisy-chained grids to achieve the same effect.

Blocklimits are listed on a servers specific rule page

🧊

SDX has its Block Limits enforced via the Ship Core Framework.

• Only grids in the world count against limits (IE: Things stored in Hangars do not count)

• Both player and grid limits apply at all times.

• Blocks must be owned by an active player.

Check the Expanse Server Rules for more info.

Gameplay and Performance Considerations

🧊🪐🛰️

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:

Exploits

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.

• Physics glitches. If you are doing something funny where you cause blocks to interact in a physically impossible way, such as phasing through each other or two pistons pressing on each other to create thrust in a direction, you are glitching. If you are caught doing it, you are subject to being banned.

• Bypassing server configuration values. Example: Creating unsupported stations in natural gravity when the server configuration disallows it

• Lag glitches. If you are intentionally planning to take advantage of the lag surrounding high speed impacts or the like to bypass game mechanics such as shields, you are glitching. Do not take advantage of the fact that the game needs a few moments to calculate your impact with a shield and figure out where you are to do something like detonate a warhead inside of a shield that is still up. Being caught planning or executing this glitch leaves you subject to being banned.

• Safe zone glitches. We have removed player safe zones very intentionally due to the sheer number of bugs around them as well as their impact on gameplay. This means every remaining zone has either been placed there by a member of staff or was placed by the game itself. This makes using bugs and exploits around safe zones an extra dangerous endeavor. If the safe zone stops you from doing something inside the zone, do not reach a line of blocks inside the zone from outside, taking advantage of your blocks not being correctly disabled. This includes trying to permanently leave grids inside of NPC safe zones, including by cramming small grids in, or building hooks to try to keep yourself stuck in the safe zone and more.

• Building under the voxel mesh. If you want to build underground, dig a cave. Undermeshing, Meshing, undermapping, call it what you want just don't do it. Any functional blocks (those that use computers) must be hackable with a hand grinder/welder and can not be fully built underground using grid welders.

• Unintended interactions between plugins - Example: Using !fixship to clear the top grid marker, or using hangar save right after crossing instance boundaries to avoid combat

• Setting any of your functional blocks to share with all during a combat scenario is considered an exploit of weaponcore targeting. Any use of this during any combat situation PvP or PvE will result in a ban.

Respawn Ship Spam

The Respawn Ships are solely intended as a (generous) starting platform for beginner players to start their play in the Draconis Cluster.

Let's clarify a couple of things clear on it - but this is not an all inclusive list –

• Spawning a respawn ships and using it to build your way through the tech tree. :: Ok! ✅
  

• Spawning a respawn ship and using it go get to your base when the medbay isn't working. :: Ok! ✅
  

• First spawn and ran out of Hydrogen, need a second one to keep progressing. :: Ok! ✅
  

• Using whatever ship you happen to be in as a kinetic weapon to ram into someone. :: Ok! ✅
  

• Spawning respawn ships to harvest their resources. :: No! ❌
  

• Spawning respawn ships to throw them at your enemy. :: No! ❌
  

• Spawning respawn ships to scout areas new players may be likely to spawn in :: No! ❌
  

Grids duplicated due to server issues (Dupes) 

Do not attempt to keep duped ships, just as lost ships and tracked and restored, duplicates are also tracked and removed.

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 hangar the dupe and delete it from there.

To clarify how dupes are created, as an example:

Indiscriminate Orbital Bombardment

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.

Concealment

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.

• PHYSICS are not paused, but thrusters/dampeners are. A ship in motion remains in motion. So if Concealment triggers while you are in natural gravity in a ship, the ship WILL crash into the ground. Please make sure that before server restarts, or before logging off, that your ship is not hovering in natural gravity

• On restart all grids are stopped from moving; so unless planetary gravity or thruster override causes it to start moving again; it will remain still in concealment.

• Be careful while moving across servers with concealment, due to what was previously mentioned ships will sometimes fall out of the sky or crash while the player is loading due to them being concealed, prepare for that ahead of time!

• Concealment also means things such as PAM Autominers and other script ran grids will fly off into the unknown if they travel more than the concealment range from an active online player. They will continue flying in the direction they were when concealment triggered.

Production blocks (assembler, refinery, etc)

• Whether production (Refineries/Assemblers) running will prevent concealment depends on the server.

• This is not to be abused to prevent grids from concealing - this is to help players better progress without having to AFK waiting for resource refining.

• Production blocks will keep working as long as they keep producing. If they are missing input items, they will stop producing, be concealed, and be unable to pull items later to resume production. To avoid that, make sure to always fill your assembler/refinery before leaving, or use blocks like conveyor sorters to keep them stocked.

Building tools

• Welders, Grinders, and the Build and Repair System

  • Some of the awesome extended tools we have available to enjoy are "Tiered" welders and grinders, and the Build and Repair system. These godsends help remove a lot of the tedium of getting our creations moving. However, they also carry the potential to *majorly* impact the sim speed in certain situations. Essentially, there's a lot of calculations going on when something is getting built or ground. Parts are getting moved around, many blocks are being created or destroyed and filled with, or emptied of, components, etc. As a result of this, when these effects overlap, it can bring the game grinding to a halt.

• While common sense might tell you more = better, in fact you will slow the entire process far more due to sim hit than any possible benefit you will gain from overlapping. If you have doubts about your grid please open a ticket and ask us to inspect it.

  • It takes drastically longer to weld 100 small ship blocks at once, than small 10 ship blocks. This is because the welder evenly builds all blocks inside its radius. So when the 100 small ship blocks are inside its radius, even though they are small ship blocks and require little resources to build, it will take 10x longer. The best solution is not more welders, but to slowly bring the welder across the object. It is faster to build 10-20 small blocks at a time, than 100 blocks at once. Same concept applies to large grid blocks.

Projectors

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.

• Firstly, the Blueprints that they store contribute significantly to the game's overall filesize. This leads to massively increased saving and loading times, possible crashes, as well as the threat of save corruption.

• Secondly, certain strange edge-case uses such as a Projector rapidly cycling between on and off either by grid issue or design can potentially cause *immense* problems for the server overall.

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.

On some of our clusters, we employ a plugin to help aid in these projector issues that performs the following duties:

• Blocks the projection of "Problem blocks" that cause grid bugs when projected (the NPC Boost Consoles for example - Production, Engineering, Combat)

• Drains tanks/batteries/inventories/jump drives/etc to prevent exploits

Conveyor Junctions and Conveyor Networks

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, most of our clusters vastly expand the conveyor options, including many full-block versions with up to 6 attachment faces just like a Junction. Make sure as you start your designs in Draconis that you take advantage of these mods 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

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.

Clang Contraptions

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

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 (or into voxels). Servers may further restrict this in their own rule set.

Advanced Engineering

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.

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. (No Artificial Mass Blocks on SDX = no grav drives)

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.

Programmable Blocks / Scripting

See SE - Scripting & Programmable Blocks .

Faction Names and Tags Reclamation

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:

• Inactive faction last player login of 8 months or more (must be verified by !lastlogin “player name”, with all faction players being checked and proof posted in ticket)

• If the faction tag or name is verified as previously owned by the requested faction (must still meet inactivity requirement, subject to green review and approval)

• The tag is being held as a ransom or maliciously upon server wipe (push to green for review and approval/denial, this is not to be handled by anyone otherwise)

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.