Let's Talk Optimization.

[War Dog]

As good as the game will get, one of the biggest detriments to game experience is LAG.

In this thread we players can attempt to come up with ideas that will reduce both the load on the server and the amount of space needed.

A couple of suggestions in the previous thread I made about economic rebalancing has a few changes that reduce server load. Namely, fewer shops to keep track of means reduced resource usage and no more planet salvaging means planet eaters are mostly out.

Collisions are THE biggest sources of lag, so I propose a mechanic:
1. When a collision starts to cause significant lag, instead of teleporting them out, give the smaller of the colliding objects the ability to ignore collision temporarily.
2. When undocking objects, temporarily give the undocked object the ability to ignore collisions.
3. If several attempts do not work, THEN teleport the objects away from each other.
4. If that doesn't work after multiple attempts, teleport players away so the offending sector unloads.

The next is gigantic ships, there should be a server setting to limit how big a ship can be bought from the catalog. In blocks, as I can simply buy a 100,000,000 block ship made out of dirt to lag the server intentionally if the limit is credits.

To a lesser degree, salvaging. Depending on whether planet salvaging is still possible; give salvage lasers an AOE to encourage smaller amounts of big beams instead of dozens of smaller beams. It also makes debris easier to clean up and hopefully puts an end to ugly floating debris blocks.

Finally, object bloat. As a server continues the number of ships and objects start building up to ridiculous amounts. Not everyone is as fastidious as I am and clean up their cores after all. So I propose:
1. Undocked and unfactioned ships are deleted by the server after some time passes.
2. Overheating ships are deleted 5-10 minutes after the sector they are in is unloaded.

Is there anything else one can add?

 

[montecristo]

War Dog I agree that optimizations are critical for the game, and I think this is an important point to consider. However, are you sure that the biggest performance issues are coming from the economy and the number of entities in view distance? Correct me if I am wrong, but it seems as if the largest/most significant gains in game performance come from mostly under-the-hood fixes and code rewrites by schema like object rendering, entity data loading/offloading, and collision calculations (specifically: how all the FLOPS are carried out on each colliding entity every game tick) -- things that we common folk don't really see or have access to..

Collisions are THE biggest sources of lag, so I propose a mechanic:
1. When a collision starts to cause significant lag, instead of teleporting them out, give the smaller of the colliding objects the ability to ignore collision temporarily.
2. When undocking objects, temporarily give the undocked object the ability to ignore collisions.
3. If several attempts do not work, THEN teleport the objects away from each other.
4. If that doesn't work after multiple attempts, teleport players away so the offending sector unloads.

I worry that these server action items would increase gameplay instability as a trade-off to better server performance stability. For instance, how long would you expect the ignore collisions effect to last in #2? 0.1 seconds? 0.5? 5? 10? At any period greater than 3 seconds, a very agile craft could probably tunnel (aside: always have hated how "tunnelling" gets thrown around so casually as a term, but that's how it's labelled in the server config...), or, "phase", through almost 150 m of solid hull.

Perhaps, instead, you could have the smaller craft only ignore collisions in a small local radius (i.e. (entityLength/2)+Cx along the x-axis). That way they would avoid collisions enough to move before attempting to recalculate collisions. But then, you may see the collision getting worse as a smaller craft uses the multiple attempts to burrow deeper into trouble... it's a difficult situation to resolve.

Also, in #4... just how far away is "teleport players away?" Would this involve teleporting players out of the sector they were just in? Or farther? I'm not sure a sector unloads if you are still in a bordering sector... does it? And, if players were teleported more than one sector away...well, if it were me, I'd be so terribly disoriented!

 

[War Dog]

I'd probably settle for 2 seconds, though 1.5 should be more than enough. Note that this would only affect collisions causing significant lag.

Getting a few players disoriented is preferable to being lagported 100 sectors away, forcing everyone to 5-digit ping, or crashing the server. The server load radius is 3 sectors I believe.

 

[montecristo]

Getting a few players disoriented is preferable to being lagported 100 sectors away, forcing everyone to 5-digit ping, or crashing the server. The server load radius is 3 sectors I believe.

Point taken.

 

[Iskandar]

1. When a collision starts to cause significant lag, instead of teleporting them out, give the smaller of the colliding objects the ability to ignore collision temporarily.

A common tactic I've seen used by griefers was to repeatedly ram a ship core into the side of a larger ship (or planet or station) until they lag glitch into an interior space, allowing them to bypass the shields and get direct access to the core and faction module. The recent changes to factions and auto-war made this tactic a little less viable, but allowing small ships to completely bypass collision detection for two seconds would open the whole can of worms right back up again I'd rather see it cut straight to teleporting the smaller vessel to an empty area in the next sector.

 

[War Dog]

When a collision starts to cause significant lag

We're talking about collisions that cause the lag message to come up repeatedly. Tiny ships don't do that.

But honestly, I'd just be happier if the server just teleported them out immediately instead of screwing around and hoping the problem fixes itself.

 

[rece ktore leczo]

Collisions have been optimized in the next update and do not cause such big lag anymore.

But yes, the game should be more optimized and i believe that Schema would keep working on it

We definitely do not need so many stations, shops, planets and asteroids. And i really liked the idea of not disappearing planet's blocks while salvaging it (for the ores).
The custom block (mass) limit for ships on server may be useful, but i don't think that trolls buying 100 mil blocks ships are often seen Also there might be a limit for number of turrets/docked ships, some servers have this limit, but i think it's not in config file.

 

[Visitor]

In all honesty, I am not sure whether one can effectively consider optimization, at least as far as performance goes, without a look at the code. Most of the things that cause lag right now, don't do so because they do some X action that by universal law is lagging, but because X is coded in a way that causes lag (whether it can be avoided is a different matter).

I do agree with the sentiment as optimization is one of the most important parts of development for me when it comes to this game, especially since it already started to be demanding with system resources in certain situations.

While we can brainstorm all kinds of different workarounds for those situations (limiting frequency of situations where lag occurs, as in mentioned case of planet eaters), however, the only really surefire way is to give the devteam time to take a look at what they've made so far and think if they can make it work better.

I understand that there are certain limitations - some programming languages are simply more demanding than others and some things are tricky to code but I am quite sure that a lot, with enough time and effort, can be improved upon. A belief reinforced today when I checked some tech demo of another voxel, minecraft-inspired space sandbox game, one that is way behind - at least for now - Starmade, but which surprised me with quickly and smoothly generated planets and ability to plant powerful explosives allowing to punch enormous craters hundreds blocks big without any lag, despite water flowing in the area, vegetation etc - a thing that so far, in any other voxel game is more than a hickup on my computer.

Devteam already spends quite some time to make the game run smoothly despite ever-increasing amount of 'fireworks' - shaders, special effects and so on. I am grateful for that but I suspect that if we want more than this, Schine will just have to take a month or so every few bigger versions to go through the code and try to optimize the thing. Something I actually wouldn't mind if only to avoid uncertain future when at the rate of the game growth, should performance be not regularly improved, some players would be limited to playing single player games in tiny worlds on minimal settings.

 

[Viridis00]

In all honesty, I am not sure whether one can effectively consider optimization, at least as far as performance goes, without a look at the code.

This.

Don't get me wrong OP, we can talk about this all we want. But without having the code ourselves, we might think we know how SM works, but we don't. A couple of things people said, like asteroids being a significant source of lag were proven to be untrue when Schema said otherwise. We just have to leave it to Schema and company to come up with ways to optimize more. Which I'm not worried about because they're all some kind of wizards seeing as we get optimizations and bug fixes quite frequently.

 

[War Dog]

Perhaps instead of "Optimization" I should use "tweaks". True optimization would need direct access to the code, which we obviously do not have.

I'm looking for tweaks that change common causes of lag and object bloat in the game.

 

[MrFURB]

In all honesty, I am not sure whether one can effectively consider optimization, at least as far as performance goes, without a look at the code. Most of the things that cause lag right now, don't do so because they do some X action that by universal law is lagging, but because X is coded in a way that causes lag (whether it can be avoided is a different matter).

Speaking with the dev's on the topic of optimization a while ago, I was quick to infer that the real cause of poor performance is due primarily to the code underlying the activities that commonly create lag. Collisions wouldn't be a pain if physics updated quick enough to prevent 'tunneling' into other entities at high speed and didn't completely derp and have a rave every time a block overlaps with another block. A while ago Schema was adding in features at a quite rapid pace and I bet if you asked him he would say that those features no longer meet his expectations. That's why I think he's going through the entire game piece by piece and upgrading it to be professional quality material; not only does he get to give people new features on a semi-regular basis, he can thoroughly search and modify the code of that specific portion of the game and optimize the heck out of it. Remember the graphics update? Well that was also the data-structure update. It also had over 300 bug fixes, most pertaining to the portions of the game which were changed in that update. If this continues, the game will become naturally cleaner every update while still-

Oh, crap. I'm going off topic... *Ahem*

I think that setting a proper speed limit for your server is a good way to avoid many of the problems that normally plague multiplayer. Smaller servers can usually handle higher speeds, as there's inherently less interaction going on between objects at one time, but for any server with a lot of folks fighting and crashing all over the place, you're going to want your speed to be around 120-80 depending on how safe you want to be. 100 seems to be the average that folks aim for.