Approved 2022/06/10 14:19

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 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 –

  • Spawning a respawn ships and using it to build your way through the tech tree. :: Ok!
  • Spawning a respawn ships 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!

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.

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.

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.

Players should avoid creating large counts of unwelded blocks - please finish as you go when possible.

Like nearly all modded multiplayer servers for Space Engineers, we 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.

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

Production blocks (assembler, refinery, etc)

  • We do not conceal grids which have actively working production blocks 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.
  • After the daily server restart, all grids are concealed again and production blocks will not resume by themselves. You just need to visit these grids again, so they get out of concealment and resume production, until the next server restart.
  • 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.

  • 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!

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.

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.

Note- 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 there is no ramming of grids within 500m of voxels.

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.

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, 4, and sometimes 5. 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.
  • Unintended interactions between plugins - Example: Using !fixship to clear the top grid marker
  • 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.

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

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