shiptest-ss13
Subsysteming Attempt 2...?
About The Pull Request
This is cursed, and I apologise to tmt for doing this like this
My attempt at reviving #2087
Modifies /datum/map_generator code somewhat, allowing for the actual work of generation to be moved to a subsystem. This subsystem then processes a single map generator at a time. This prevents multiple concurrent map generations from lagging the server immensely by eating entire ticks or waking before the MC. Virtual level clears are implemented as a "map generator" that clears every turf passed to them: they were causing the other half of the lag. These map generation jobs are added at a lower priority than planet generation, as there's nothing especially urgent about them.
To communicate map generation progress to players, the spawn_dynamic_encounter proc may now take an additional arg -- the ship requesting the dock. This ship's helms will announce updates on the generation progress every 3 seconds or so according to the number of datums and their progress which remain ahead of the relevant datum in the map generation queue. This should make it a little more obvious that progress is actually being made.
Once again tries to move map generation and deletion to a subsystem. This time with some interesting workarounds to make SSair fire every tick to make sure it does run, as well as running as a background subsystem so it can use up any spare processing time to keep working.
Also adds an element for registering signals from a movable's current vlevel, updated whenever that changes. I... really don't know how we're going to handle stuff without vlevels anymore. I need to either go full in on making sure nothing can exist outside of one somehow, or just chicken out and make there be a default fallback vlevel for stuff. And a signal that gets sent on vlevels when they're starting to clear so we can get spawners to stop and such. Hopefully I can get that all hammered out. Or maybe I won't and we'll live with that one painful sleepless movable deletion loop.
todo:
- [ ] Actually test this on a live game to see if my changes actually fixed anything
- [ ] See if I can make the template placement phase actually use MC_CHECK_TICK somehow. probably make it return false when incomplete and provide a wrapper that does a while() loop until it's done, idk
- [ ] Find out if I can remove ALL of the stragglers that are left by my "improvement" to movable clearing code. also probably move that into the subsystem somehow
- [ ] Handle docking progress more gracefully, make it more accurate, and make it UI
- [ ] Find out if using can_fire is actually bad (I'm not a big SS_HIBERNATE fan)
Why It's Good For The Game
Big source of lag, reduced to atoms. Also gives people a better representation of how long dock should take.
Changelog
:cl: tweak: Overmap docks to outposts or encounters which require map generation will now announce their progress periodically via the helm. refactor: Map generation is now queued via a subsystem, reducing lag by preventing them from hogging CPU time. /:cl:
nah I changed it around so it actually runs every tick* now instead of only being in the background. in testing it never got over a minute for generation even when constantly generating and deleting planets
I could be way off the mark though so shrug. just wanted to test a silly idea I had
yup. that's why it needs testing on live
I'm fully prepared to scrap it a second time if it doesn't work so don't worry, but I'm also fully prepared to tweak it as much as I can
This pull request has conflicts, please resolve those before we can evaluate the pull request.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This pull request has conflicts, please resolve those before we can evaluate the pull request.
this stopped fires from going out for some reason when we test merged it.
am i blind or are these identical
The original was a mispelling, notice how it's written as PRIOTITY
this stopped fires from going out for some reason when we test merged it.
oh sick a testmerge happened. fires as in hotspots, or fires as in turf fires?
this stopped fires from going out for some reason when we test merged it.
oh sick a testmerge happened. fires as in hotspots, or fires as in turf fires?
What i witnessed was hotspots. Oil fires for example def didn't go out. Im unsure of the full specifics as I left shortly after i confirmed the hotspot thing.
Atmospheric machines also did not function. Gas spread through pipenets, but when it hit a machine (such as a pump), it did not move further. Atmospherics itself had some minor issues - Temp was a bit weird. Manually extinguishing turf fires seemed to really cool the area down.
Yeah, I can believe atmos just outright broke because of this. That's the one thing I'm still fighting, since apparently I managed to just silence an error that I really should have dealt with a long time ago, and now I'm having to deal with it.
Onto other things, though, were there any noticeable performance improvements? I imagine loading planets was slower, but was lag during loading/unloading less present? I'll check the profiler when I can.
this stopped fires from going out for some reason when we test merged it.
oh sick a testmerge happened. fires as in hotspots, or fires as in turf fires?
What i witnessed was hotspots. Oil fires for example def didn't go out. Im unsure of the full specifics as I left shortly after i confirmed the hotspot thing.
flamethrower troops shot fire Hotspot which never went out and would stack if given the ability, and explosion that made fire (baby grubiod for example) would create infinite Hotspot as well. Hotspot could still be put out with a fire extinguisher, to note
This pull request has conflicts, please resolve those before we can evaluate the pull request.