Adds `USE_BYOND_TRACY`, which automatically loads a given
prof.dll/libprof.so using https://github.com/mafemergency/byond-tracy/.
Not intended for use in production, and we do not ship a copy of
byond-tracy. It is extremely easy to compile yourself, but if you're
someone interesting enough to play around with this then let me know and
I can just give you a build.
I'm going to be using this for init profiling.
## About The Pull Request
When runlevels change mid work, subsystems running behind have their
next_fire updated.
It's offset by a sum of random numbers, so things don't bunch up,
especially KEEPTIME SSs
The trouble is we have so many subsystems that get added at roundstart
that this offset gets LARGE, like 10 seconds on average.
So instead of randomly offsetting, why not "fill" a set of time slots?
Only 1 keeptime subsystem a tick, and 4 others. Then we just fill up
those buckets and get to it (also don't offset things that are already
processing)
I've talked to mso a bit about this. What he reccomended was sampling a
random time withing a 2 second window.
I'm not totally sure why, kinda waiting for him to tell me off, if he
does I'll fix things up.
This pattern takes the max possible delay from 16 (76 * 5 / 20)) seconds
to 0.7 (56 / 4 / 20)
It obviously scales with subsystem count, but I like this scaling a bit
better
I've applied the same pattern to the offsetting we do at the start of
Loop(), for ticker subsystems. I am less confident in this, it does take
last fire times from at worst 3.75 seconds (15 * 5 / 20) to a static
0.75 (15 / 20)
As stated I'm less sure of this, hoping to get mso'd so I can clean
things up
## Why It's Good For The Game
Makes roundstart snappier
## Changelog
🆑
code: Roundstart "starting" should be much snappier now
/🆑
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Sends a toast notification when initializations complete. (#72465)
Initialization is significantly slowed down by the presence of clients,
though when testing features, you need to join the server. I've been
told that some devs (particularly Mothblocks) are alt-tabbed out of
Dream Daemon while doing dev work, meaning that they are liable to miss
initializations completing, causing an effective slowdown in the dev
cycle. Mothblocks said it would be nice if there was a way to produce a
desktop notification when initialization completes.
I originally intended to add a function to rust_g that would produce a
Windows toast notification with a button allowing you to immediately
launch Dream Seeker. However, I couldn't find a reliable way to detect
if the OS version was Windows 7 or earlier, so running this function on
such an OS would cause a rust panic (which I was told is only a problem
because MSO probably still uses Windows 7).
Fortunately, PowerShell scripts can access the necessary .NET APIs to
produce toast notifications on Windows 10, while also failing more
gracefully than crashing the host process. So I recreated the
functionality I intended in PowerShell.
Toast notifications will only be sent on Windows, if the
TOAST_NOTIFICATION_ON_INIT config flag is enabled, AND there are no
clients on the server.
**Note for downstreams:** If you want the toast notification to have
your downstream's icon, copy it, scale the copy down to 16x16, and
either rename it "tg_16.png" or change that path in the call to
`world.shelleo` to the name of the new file.
Video Demo:
https://user-images.githubusercontent.com/12720844/210492033-963923d7-a1de-4326-9c9f-4f0c0b71d1a5.mp4
This isn't really a line item in the Dev Cycles Initiative, but even if
Mothblocks was exaggerating the benefits, it would still be a
significant speedup in the dev cycles.
No player-facing changes.
* Sends a toast notification when initializations complete.
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
- nerfed most disruptive events from happening, raising pop requirement
- stopped radstorms and heart attacks from occuring
- slightly buffed lighter or less destructive events
Metis