Thread Rating:
  • 1 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Lag causes hellburn engine to break.
#1
So there's been a bug that keeps happening whenever I set up the engine and someone does something that causes lag (usually a small - medium TTV). After the lag subsides, the engine burn chamber's fire disappears for a quick second, and when it reappears the temperature drops down by several million degrees. This causes the engine to break, and has ruined several of my antag rounds just because someone decided to spend 10 minutes in toxins making a decent bomb. I think it has something to do with the atmos process getting hung up from testing on a private server (?). Not sure how essily this can be fixed, but it's been bugging me for a long time and I haven't seen a thread on it yet.
#2
That used to only happen with canbomb level lag. If it happens from smaller lagstorms like hellfoam or ttvs then it's troublesome.

If you're running a tight burn (1 tile fire) you might want to up the fire size a bit. It might help mitigate the problem.
#3
This probably relates to how the "new" system reduces lag by temporarily putting stuff off until the next tick, if I remember correctly about being how that works. Couple that with the new extremely high tick-rate, and I could see stuff being needing to be shoved off to the next tick more often due having less time available to occur.

Let's hope it doesn't relate to the lag fixes, because fixing something like that would require really fundamental changes.
#4
(05-29-2016, 08:40 PM)Vitatroll Wrote: That used to only happen with canbomb level lag. If it happens from smaller lagstorms like hellfoam or ttvs then it's troublesome.

If you're running a tight burn (1 tile fire) you might want to up the fire size a bit. It might help mitigate the problem.
Yeah, the reason I posted this was because there was an explosion in cloning (literally just the size of cloning) and it ended up disabling the engine from the lag. I also have tried putting up the gas mixer pressure to 150 kPa (anything beyond that is just extremely innefficient and you shouldn't have to use that to get around a bug) and the engine still ends up breaking.

(05-29-2016, 09:01 PM)Mageziya Wrote: This probably relates to how the "new" system reduces lag by temporarily putting stuff off until the next tick, if I remember correctly about being how that works. Couple that with the new extremely high tick-rate, and I could see stuff being needing to be shoved off to the next tick more often due having less time available to occur.

Let's hope it doesn't relate to the lag fixes, because fixing something like that would require really fundamental changes.
That definitely sounds like what is happening. How hard would that be to fix? On a side note, this has happened more after the tickrate was doubled, so that may definitely be contributing to why even a small explosion can ruin the engine.
#5
Off the top of my head, the only fixes would be adjusting the priority of what stuff is and isn't shoved off to the next tick, which I'm not entirely sure is possible, or rework atmos, which been on the docket since... forever.
#6
Ok so first off all. I am dumb. My brain capacity is 8bits.

But anyways!

Couldn't the engine/fire temperatures be saved and then like get like taken back after the tick thing happens?
#7
(05-30-2016, 09:02 AM)Naximous Wrote: Ok so first off all. I am dumb. My brain capacity is 8bits.

But anyways!

Couldn't the engine/fire temperatures be saved and then like get like taken back after the tick thing happens?
I'm not sure about how this works either, but that sounds like a decent idea. The thing is it would have to save the atmos temp of every single tile of the server every single tick, which might cause lag (i have no idea how this works dont kill me if its wrong ok) Maybe it could somehow be limited to the burn chamber?
#8
Tobba is already working on an atmos rework, and I don't think any other coders want to so much as look at the abomination that is FEA code.

That having been said, this seems like a very recent issue, so maybe something else is causing this.
#9
There isn't that much that can be done here unless someone is willing to rework a large part of the scheduler code to allow for prioritized processes
#10
(05-30-2016, 04:46 PM)ErikHanson Wrote: There isn't that much that can be done here unless someone is willing to rework a large part of the scheduler code to allow for prioritized processes

Unfortunately, that's entirely true.


Forum Jump:


Users browsing this thread: 1 Guest(s)