Lag Avoidance

Hello,

Welcome to the lag guide for the SI server. See the disclaimer on the left-side menu. This post has nothing to do with the happy-pvp guide, but in order not to start another blog, it is posted here.

We will discuss a bit of theory, some causes of lag, and a few tools you can use.

Note that the author is not an expert and relied heavily on the input of others. Please point out errors.

Theoretical Stuff

Lag is how fast you experience the game world. Realtime.. or delayed.

Latency or ping is measured in milliseconds and is the time data takes to get from your PC to the server, and back again.

Simspeed is how fast the gameworld is (re)generated. Realtime (1.0) or delayed (<1.0).

Both latency and simspeed affect how you experience the game world. You can press shift-F11 in game, and see all those stats. If we assume that you and the server have a great connection, simspeed becomes the most important.

Simspeed

Both your PC and the server create their own game world. Your PC uses data from the server to do it, but also local data from your harddrive, like texture files, to generate your local visual game world. How fast your pc can rebuild your local game world each time something changes, determines your local simspeed.

The server does not need to make a visual game world, but it does need to make one consisting of the data needed to be able to keep all connected players informed of what is going on. So like, where asteroids are and stuff. But more imporantly, what stuff players have out there, and what that stuff is doing. How fast the server can build rebuild its gameworld after each change determines server simspeed.

In order to give that 'real time' experience to all the connected players, the server is only allowed a finite amount of time to do this, before a new update needs to be send to the players.

The time that the server has for each update in SE, is about 16.6ms, which translates to 60 updates per second.

The 16.6ms is like a pie, and each player takes a piece with the grids that they have active.

Even if other players are not in visual range right then, the server still needs to include your stuff in the 16.6ms in order to keep its game world up to date. While the server can be selective in what it processes, with smart stuff like concealment range, it can't afford ignore all your stuff and wait until someone is near, and only then process it. That would mean a lot of processing all of the sudden.

Obviously there is a difference between a simple miner and a complex base in how much time they consume. And between an active grid, doing stuff, and a inactive grid in concealment.

If the server needs more than 16.6ms in order to simulate the game world, players start experiencing delays. The question then becomes, how much of the pie are you hoarding?

I hope it is now clear to you that anything you do can have an impact on other players. So let's see which practices cause the most lag and what best to do.

The grand list of Stuff That May Cause Lag or STMCL for short

STMCL

Having a lot of X, instead of a few.
Using X for a long time, instead of a few seconds.
Keeping grids in the game world while not in use.
Clustering grids close together.
Voxel bases.
Conveyor networks.
Has-inventory blocks.
Huge grids.
Ships versus stations.
Lights, LCDs.
Rotors/pistons.
Projections.
Grinders/Welders/BAR.
H2 generators / H2 tanks.
Refineries / Assemblers.
Roachers.
Med bays
The few versus the many.

Examples and explanations

1. Having a lot of X / using X for a long time. Daisy chaining 4 cargo containers on your miner won't kill the server. Doing the same with 40 cargos on your base will. Using one projection briefly to print a ship is not an issue. Having multiple projections on for hours while slowly building them with a BAR is.

3. Grids not in use --> hangar them. Perhaps pretty to look at, but you are adding lag.

4. Clustering grids

For every grid a calculation needs to be made what its relation is to other grids within visual range. If you keep multiple grids owned by multiple players within visual range (15km), that means a lot of calculations, and depending on who is online one or multiple recipients of data. That puts unnecessary stress on the server.

Any single player action, or grid operation, then has a snowball effect. The server will spend even more time calculating and then sending data to you and any friends, to update everyone on every change, and thus has less time handle the actions of other players.

There is nothing wrong with visiting friendly stations. Or working together on something. Admiring some of a friends ships. Just try not to permanently cluster grids. Hangar what you do not use.

You can also build a community center somewhere, but try to keep your bases far apart.

5. Voxel bases

Don't. Ehmm.......well... voxels are not well handled by the game. The deeper your base is, the bigger it is, the more issues it will generate. You can build on top of voxels but try to avoid building inside them. And remember, any voxel damage is permanent if a grid is near, and will cause both server and client side lag when a player goes near. Voxels of course mean solid stuff, asteroids and planets.

6. Conveyor networks

Conveyor networks are best done as simple three structures. One main trunk with branches, and limited sub-branches.

Example good vs bad:

click to enlarge

Stuff that has to travel from block A to block B is confronted by your conveyor network. The more paths that are possible to get from A to B, the laggier your network will be. All possible paths will be calculated.

The same goes for the amount of choices needed to calculate a single path (go left/go right). Best to avoid loops and too many sub-branches.

Another cause of lag is the lenght of a conveyor network which can kill a vanilla server when approaching 1km.

7. Has-inventory blocks

Various blocks have an inventory. They have the so called Has-inventory-tag. This can be space for components, ores, ice or ammo. Examples are cargo containers, connectors, sorters, refineries, assemblers and h2-generators.

Each time an item has to travel from block A to block B, it will 'stop' at every block directly in between that has an inventory-tag. This creates a little bit of lag. Imagine you have 5 cargo containers daisy chained, with a refinery at one end, and an assembler at the other. The ingots requested by the assembler will 'stop' 5x extra times.

This type of lag can build up quickly depending on the number of requests a block makes per second for stuff, which is virtually all the time for h2-gens/refineries etc.

It does not matter if the block can't process the stuff that is travelling. As long as it has the tag it will be checked.

Therefore it is best to avoid daisy-chaining any type of inventory-block.

8. Huge grids

A big grid is more data intensive than a small one not only when it comes to physics processing but also depending on the blocks used. You can make quite big things with low impact as long as you keep the conveyor network simple, and the use of laggy blocks to a minimum. Hangar your grid if not in use.

9. Ships versus stations

Stations are usually the main cause of lag in PvE sectors. This is because they are permanent, usually bigger, more complex, and perform constant actions such as refining.

However stations are the most lag friendly environment for production blocks such as refineries, assemblers and h2 generators, because they do not move. Furthermore, stations will keep working until the next restart in partial concealment mode while you are out doing other stuff, like roaching. This means they add less lag than any production blocks on the ship you are using would.

Try to build all your production on a station. Keep the conveyor network as simple as possible. Try to limit anything on your base that may cause lag. LCDs, lights, the size, etc. After all, theoretically, you will spend most of your time doing stuff away from your base. Mining, roaching, running away at KOTH, etc.

10. Lights / LCDs

The author of this text does not know how exactly server lag works in relation to lights and LCDs. If you do, please send a DM. They are however a known cause of lag when used in excess.

10 LCDs is fine, 20 maybe too, 50 is pushing it. Spotlights are much more harmful than corner lights. Blinking takes more server time than steady lights.

Create on/off buttons on your grids to enable lights and LCDs when there is an opportunity to show other players how fancy your grid is.

Example good vs bad:

click to enlarge

11. Rotors / Pistons

The author of this text does not know how exactly server lag works in relation to rotors and pistons. If you do, please send a DM. They are however a known cause of lag when used in excess.

It is not hard to imagine that an object that is moving constantly, like a bunch of drills on a rotor, can cause a lot of extra updates the server has to send and receive, besides the ones from the moving ship.

12. Projections

Basically count as an extra grid, and thus more lag. The lag spikes when the projection is interacted with, such as by a welder or BAR.

Do you like showing off multiple grids via projectors to your friends? Don't.
Do you like building the old fashioned way, with welders? Don't. Use the build grid button found on the projector in the K-menu or the BAR.

13. Grinders / welders / BAR

Grinders and welders can affect multiple blocks at the same time due to their range. For all these blocks caculations need to be made, along with stuff like cargo inventories filling or draining etc. All that data is work for the server !

If the ranges overlap, it is even more intensive for the server to calculate what affects what.

Some stats:

Proficient welder: 6.4 large block radius, 13 blocks distance needed between welderheads.
Elite welder: 12.8 large block radius, 26 block distance needed between welderheads.

If not absolutely necessary, use the BAR to build blocks, or the build grid option on projectors.

Typically, the more of these blocks you have on, they more they overlap, and the longer you use them, the worse the server sim speed becomes.

Informative example:

click to enlarge

14. H2 generators / H2 tanks

H2 tanks do not have an has-inventory tag, and do not lag the conveyor network... However, they do constantly update if there is incoming or outgoing H2.
If there is ice available and there are unfilled tanks, H2 generators create a lot of lag, similar to refineries.

Best to use as few tanks as possible, as few ice cargos as possible on your base. Goliath tanks and T3/T4 containers are very lag friendly.

The vanilla practice of having H2 generators on ships is obsolete on the SI server. Tiered tanks have huge volumes and it is unlikely you run out of H2 before you can dock with your base, or a tanker.

Besides, the extra weight for carrying ice offsets part of the fuel gain.

Example good vs bad:

click to enlarge

15. Refineries and assemblers

Needless to say, these create a lot of server lag due to their constant actions. With a proper conveyor network they can work just fine.

Example good vs bad:

16. Roachers

Best roaching practices

Simple conveyor network.
Limited amount of h2-tanks.
0 h2-generators.
0 h2-engines.
0 refineries and assemblers.
0 drones when multiple players in sector.
Welders on/off button and used as briefly as possible and only to repair critical damage.
Grinders on/off button and used only when eating.
BAR continually on. It will repair stuff lag-efficient.
Projection on only when repairing out of combat.

16. Med bays

We use medical bays or survival kits to spawn on. The more you have of these in multiple sectors, the more you add a little lag to nexus-processing. Open spawns are the worst. Please keep your spawns closed to the public at all times.

17. The few versus the many.

(this is just a bit of text for the inevitable smart guys)

The smart player: ''I know what I am doing. You can build bases in asteroids just fine. You can daisy chain some stuff with no problems. One projection is not going to make any difference. I know rotors really well and never had an issue. My base does not lag. I got experience with...X. I am smart enough to.....Y. There are exceptions to....Z. These posted recommendations are just silly.''

Response: ''Yes... maybe this all does not apply to you. However.. have you ever been to the old planet Gea where 5 dudes built a huge underground base, had multiple defense stations in orbit, a bunch of miners at their base and cratered their whole base area with the impacts of racing grids? No? Never experienced 5 minutes loading time and a 0.3 constant simspeed they caused?

Well... I suppose you have not. After all, that particular issue was taken care of by unknown parties by means of orbital bombardment.

The point is that many players lack knowledge about how the game operates and what they can safely do in multiplayer. Although there might be many exceptions that you are aware of, by sticking to these general recommendations they can avoid causing issues for others.

In conclusion:

These recommendations are made to help nice players that have no idea but are willing to learn. Goodluck out there, please send DMs with any feedback, errors, spelling mistakes, and smileys.

Tools

shift-F11 - display lag stats on your screen
!lag inspect - lists how much lag your grids cause. Try to keep them below 10%.
!lag profile - lists which blocktypes lag the most from all your grids put together.

Ok, that's it. Have fun out there and keep your grids lag free!