Meteors and singularity produce unbearable amounts of lag

[CPTANT]

Both sing and meteors cause so much lag that the round basically becomes unbearable.


No feature is worth this amount of game destroying lag.

Features that produce this amount of lag should either be removed or put on inactive until the lag they produce becomes tolerable again.

[Amelius]

There was a shortish period of time, around a few months, wherein the singularity hardly caused lag. I believe the server was upgraded, wherein coderbus believed the server could take more punishment, and introduced fastmos, singuloth changes (I'm not privy to the details, but I believe it had something to do with object collisions) and object collision from explosives.

The result is that we're almost worse off than we were before.

[Scott]

It's being worked on.

[MisterPerson]

It's mostly fastmos.

[CPTANT]

It's mostly fastmos.

Not really sure this is true, the destruction of tiles themselves seems to also generate a lot of lag.

[Luke Cox]

Singulo was fine for quite some time. Just revert it to how it worked back then. I don't know why codebus felt the need to mess with something that worked perfectly fine.

[Miauw]

Singulo was fine for quite some time. Just revert it to how it worked back then. I don't know why codebus felt the need to mess with something that worked perfectly fine.

MORE DESTRUCTION

[Jacquerel]

Singulo was fine for quite some time. Just revert it to how it worked back then. I don't know why codebus felt the need to mess with something that worked perfectly fine.

I think it was actually changes to other systems that weren't then singularity tested which broke the singularity, the singularity itself hasn't really changed much so there's no state to "revert" it to.

[MisterPerson]

It's mostly fastmos.

Not really sure this is true, the destruction of tiles themselves seems to also generate a lot of lag.

Yeah but that lag is either a single 1-time hit or a series of 1-time hits. Fastmos is ongoing from the explosion/singulo release until forever. And trust me when I say that fastmos is freaking expensive when the singulo is out. Like REALLY expensive.

Not that I'm trying to downplay the deletion stuff though, but that's going to be expensive no matter what frankly.

[CPTANT]

Ok I did some local testing for the singularity and meteors.

Effects of tearing a singularity through the station:

atmos time required- jumped from 0.3 ds to around 1ds

tearing through parts without cables or pipes

object time required jumps to around 0.6ds

tearing through area's with cables

object time jumps to around 4ds

It wasnt that great of a test, but I suspect recreating the power grid for some reason costs huge amount of time, this seems to be responsible for the large peaks of lag experienced when the sing is loose, atmos slows down the game in general by a fair bit and the throwing/destruction of tiles also requires a significant amount of time.




Meteors lagged virtually completely through atmos, required time jumped from 0.3 to around 1.2ds

[MisterPerson]

Oh yeah you're right, I forgot about the damn powernets and pipenets. Yes, those are also going to be awful.

[oranges]

Pipenets, Powernets and atmos processing are all heavily impacted by the singularity destroying the station.

Singulo was fine for quite some time. Just revert it to how it worked back then. I don't know why codebus felt the need to mess with something that worked perfectly fine.

It's not changes to the singularity, it's changes to other systems, especially the faster atmos and I don't think most people want to go back to the old super slow super irrelevant atmos

[CPTANT]

Pipenets, Powernets and atmos processing are all heavily impacted by the singularity destroying the station.

Singulo was fine for quite some time. Just revert it to how it worked back then. I don't know why codebus felt the need to mess with something that worked perfectly fine.

It's not changes to the singularity, it's changes to other systems, especially the faster atmos and I don't think most people want to go back to the old super slow super irrelevant atmos

Can't we sacrifice some atmos accuracy for speed?

[lumipharon]

I know admins can adjust atmos speed on the fly - could you make atmos speed dynamic?
ie: If singulo is eating station, it slows down?

Laguloth is fun for no one.

[Actionb]

Talking out of my plebian ass with no coding knowledge and without a real clue of mechanics behind the game here:
Is there any reason for the powernet to be so precise? I mean, what would be lost if the powernet updated less frequently?
I can understand why piping (gotta flood fast) and lighting needs to be processed right away - but power?

Also I like lumi's idea of atmos slowing down/becoming less precise the more it has to calculate, instead of slowing down the game itself.

[Miauw]

I know admins can adjust atmos speed on the fly - could you make atmos speed dynamic?
ie: If singulo is eating station, it slows down?

Laguloth is fun for no one.

some subsystems, including atmos, already slow down if there is a large amount of lag.

also iirc atmos is calculated on a tile by tile basis, you cant just make it "less precise"

[MisterPerson]

The problem with power isn't the actual power calculations, which are somewhat infrequent and not terribly expensive.

The problem is when the singularity/bomb eats a wire/pipe, the entire network has to be recalculated from scratch.

[CPTANT]

The problem with power isn't the actual power calculations, which are somewhat infrequent and not terribly expensive.

The problem is when the singularity/bomb eats a wire/pipe, the entire network has to be recalculated from scratch.

Would it be possible to not update the pipe network the instant every time a pipe is destroyed but rather calculate a new network at fixed intervals so the network doesn't has to be rebuild 10 times but rather 1 time when a singularity rips through the pipes?

Or is this already the case?

[Remie Richards]

That would cause the network to be incorrect CPTANT.
every time a pipe is destroyed the network would be incorrect until the next scheduled redraw of the network.
an incorrect network means gases trying to flow through non existent pipes, which will cause other weirdness.

[oranges]

and more importantly

the singularity keeps retriggering the calculations, over and over

[CPTANT]

That would cause the network to be incorrect CPTANT.
every time a pipe is destroyed the network would be incorrect until the next scheduled redraw of the network.
an incorrect network means gases trying to flow through non existent pipes, which will cause other weirdness.

How often does the atmos update in pipes? iIf you redraw before updating atmos it should be ok.

It would still update often in that case but if you can cut it down from every time a pipe is destroyed to every frame a pipe is destroyed in it might already be a significant change.

But I don't really know how network updates and atmos updates are currently handled in the system.

[Miauw]

yeah we could just have breaking a pipe schedule the network to be redrawn on the next tick before atmos processes.

[CPTANT]

Changing this sounds easy enough (at least if destruction triggers a COMPLETE redraw every time currently).

But I am very unfamiliar with tg code and I can't find the relevant files for this. (that looks like complete spaghetti to me without an overview of what files handle which aspect of the game.)

[Aranclanos]

READ THIS IF YOU WANT TO KNOW THE REASONS OF THE LAG


I'll try to go as simple as possible.

Most of the lag can be easily be blamed on byond's way to manually delete objects, it goes through all the other objects of the game looking for a reference to itself to set it to null, nothing. We know this because byond has a profiler tool where you can easily check this.
It's obvious that the singularity and meteors delete a lot of objects, but there's also a second way to remove objects from the game, the garbage collector. In simple words, if no other object is referencing the one that you're trying to delete, it deletes itself after some time without doing the loop looking for references. Nexis from /vg/ (I think?) made a cool controller that puts objects that you want to delete in a queue and removes all possible references who are expected (the expectations change from object to object). After some time, if the object wasn't removed by the garbage collector, its manually deleted (AKA LAG)
So when the singularity lags, it means that something it's failing to garbage collect (soft delete) and ends up being manually deleted (hard delete, lag)

Now, pipes failed to GC themselves because the pipenet system was a disaster, leaving references all over the place. I personally fixed this, revamping the whole thing (that's why you say that at some point it didn't lag)
Buuut some people touched it and it broke again, after some months and a lot of screaming the same people seem to have fixed it, hopefully. (like a week ago)
So yeah it should be fine now.

[CPTANT]

What is the PR that fixed this?

edit: nevermind, got it

[Aranclanos]

This was my revamp:
https://github.com/tgstation/-tg-station/pull/5638

This was the un-fuck up:
https://github.com/tgstation/-tg-station/pull/10864