introduction:about_performance

Gameplay Restrictions and Performance Considerations

To reduce server strain, grids belonging to someone that hasn't logged in for 72h will be forced to the Garage for storage.

In the Draconis cluster, we strive to avoid limitations as much as possible. This is why we have unlimited PCU available to players. 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 Rovers are solely intended as a (generous) starting platform for beginner players to start their play in the Draconis Cluster. Due to earlier exploitation of the mechanic by players, we were forced to increase the respawn timer to an almost obscene degree - in order to prevent repeated spawning of the rovers to throw them against PvP encounters (Largely KOTH, but witnessed in other cases too).

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

  • Spawning a rover/pod and using it to build your way through the tech tree. :: Ok!
  • Spawning a rover/pod 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 rovers/pods over and over to harvest their resources. :: No!
  • Spawning rovers/pods over and over to throw them at your enemy. :: No!

Indiscriminate Orbital Bombardment of planets causes a massive drop in SIM and inconveniences everyone. This would include dropping quantities of partially build blocks, rotor/piston heads, etc. Tactical Targeting of strategic emplacements is allowed.

There are several balance - and performance - related concerns regarding “unbuilt” blocks - that is, blocks that are only placed, with no further welding or completion. In order to prevent undesired gameplay environments as well as performance impact, the following is required.

Players may not fly at speed and place an unbuilt block intended to pick up the player’s momentum and ultimately impact an enemy grid or other target. If you are going to bombard your enemy, you must build a payload of some type and launch it or otherwise use gameplay systems to attack. Placing a block while moving at speed to produce a destructive payload is prohibited.

Players may not “spam” a large number of unbuilt blocks, either as free-floating grids or voxels, for any reason. This includes building a “wall” of 1-block unbuilt grids across an area, producing a “debris field” around your station, or other similar practices. Building a single structure of unwelded blocks is permissible, as it doesn't create a multitude of new grids in a confined area.

Like nearly all modded multiplayer servers for Space Engineers, we use the Torch Concealment Plugin. This plugin pauses the processing of grids that are not near active online players and stops them from affecting sim speed (EXCEPTION: Physics are not affected!!!). This pauses programmable blocks, antennas, thrusters, dampeners from functioning, and more.

  • Concealment checks for players within 20,000m of the grid every 5 minutes of server uptime.
  • Grids are revealed again 2 seconds after a player is within 19,500m of the grid
  • PHYSICS are not paused, but thrusters/dampeners are. 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
  • We do not conceal grids which have actively working assemblers/refineries to allow for always-on production. This is not to be abused to prevent random grids from not concealing - this is to help players better progress without having to AFK waiting for resource refining.

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 and you will need to use a Contract Block with a Search Contract to track them down yourself.

  • 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.
  • Please do not overlap Build and Repair working areas or use Welder or Grinder blocks within them. When using tiered welders and grinders, do note the *massively increased* range that they boast and do not overlap their effective areas. Once you have the budget, a single elite welder or grinder is plenty for pretty much any job. The exact ranges on these tiered blocks can be found HERE
    • A good example is Proficient Welders have a working *radius* of 16m (6.4 large grid blocks) and Elite Welders have a working *radius* of 32m (12.8 large grid blocks). That means, between two welder tips, you need to leave 12-13 (approx 32m worth) large grid blocks between Proficient Welders, and 25-26 (approx 64m worth) large grid blocks between Elite Welders.
  • 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 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.

We currently 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

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!

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.

So, 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, and any grids not being used within the next hour or more out at concealment range or stored in your garage. 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.

It only takes about 60 seconds to fly 10km in a suit to your grid.

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.

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.



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.

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 (1ms at the moment) 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.

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 rules 1, 2 and sometimes 8. 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 three 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.
  • 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 by cramming small grids in, or building hooks to try to keep yourself stuck in the safe zone and more.
  • Unintended interactions between plugins - Example: Using !fixship to clear the top grid marker

This is NOT an all inclusive list. Don't lawyer us.

  • introduction/about_performance.txt
  • Last modified: 3 weeks ago
  • by kontu