3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
Changes map votes to be based on a persistent tally count.
Tallies for maps are cached between rounds and are added to by map
votes.
When a map is chosen, and it wasn't the only valid one, the tallies for
said chosen map will be reset.
Refactors map vote handling and moves it from SSmapping to SSmap_vote.
Rock the Vote has been removed as a result of this refactor.
## Why It's Good For The Game
Makes it more likely that all maps will be played over the course of a
server instead of always being truly random.
Removes some clutter off of SSmapping.
🆑
refactor: Map Votes are now carried over between rounds. When a map vote
is actually a contest, the winning map will have its votes reset.
/🆑
## About The Pull Request
This pull request aims to fix the wiki manuals. Currently the wiki
manuals just show "You start skimming through the manual..." because of
a bad link (http://www.tgstation13.org/wiki instead of
http://tgstation13.org/wiki) which is fixed with this PR, but the issue
does not end there. Because BYOND uses trident for its `browse()`
function, a lot of Javascript and HTML elements do not function
properly, disallowing the removal or blocking of hyperlinks which break
the book entirely if they are clicked.
Therefore, as a temporary solution (until BYOND 516 is released with
webview2) when the user opens a book they are prompted with the
following:
Although not the best solution, it makes the books have a function again
and are usable.
Fixes https://github.com/tgstation/tgstation/issues/77315.
## Why It's Good For The Game
Makes books work again so new players can use them to be guided to the
wiki resources.
## Changelog
🆑
fix: fix wiki manuals by making them open wiki page on browser
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This pull request fixes the link you get redirected to when you click
the "Rules" button on the top right of the game. Before it redirected to
http://www.tgstation13.org/wiki/Rules but the correct link is
http://tgstation13.org/wiki/rules (the www part is the problem).
## Why It's Good For The Game
Makes the rules button direct you to the correct link, making it easier
for someone to view the rules of the server.
## Changelog
🆑
fix: fixed link for the rules button
/🆑
* Adds a config to change the interval profiler information gets saved (#83849)
## About The Pull Request
As title says
## Why It's Good For The Game
Important for server operation
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Adds a config to change the interval profiler information gets saved
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
## About The Pull Request
As title says
## Why It's Good For The Game
Important for server operation
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
Do not merge this without coordinating with your server's host.
Slightly refactors the way we handle IP intel.
You can still use the old data stored in the database.
Adds the ability to automatically reject connections determined by
config flags.
We used to have IP intel to check for VPNs, although it was disabled due
to being bad and unhelpful.
This refactor should make it much more manageable for hosts and admins.
This adds a new SQL table `ipintel_whitelist`
Look at the schema!
🆑
admin: The return of IPIntel
/🆑
---------
Co-authored-by: MrStonedOne <kyleshome@gmail.com>
Co-authored-by: oranges <email@oranges.net.nz>
## About The Pull Request
- Fixes `vote_delay` not being a thing. I broke this two years ago but
there's no bug report associated.
- Admins can now reset the vote delay (to let people vote again
instantly)
- Admins can now end the current vote immediately (rather than
cancelling)
- Custom multi and custom single combined into one vote
## Why It's Good For The Game
Makes voting a bit easier to use, both for admins and for coders adding
new votes.
## Changelog
🆑 Melbert
admin: Custom Single and Custom Multi votes are now combined into one
vote
admin: Admins can now end votes instantly, rather than cancelling them
admin: Admins can now reset the vote cooldown
fix: Vote cooldown actually applies now
/🆑
## About The Pull Request
- Fixes `vote_delay` not being a thing. I broke this two years ago but
there's no bug report associated.
- Admins can now reset the vote delay (to let people vote again
instantly)
- Admins can now end the current vote immediately (rather than
cancelling)
- Custom multi and custom single combined into one vote
## Why It's Good For The Game
Makes voting a bit easier to use, both for admins and for coders adding
new votes.
## Changelog
🆑 Melbert
admin: Custom Single and Custom Multi votes are now combined into one
vote
admin: Admins can now end votes instantly, rather than cancelling them
admin: Admins can now reset the vote cooldown
fix: Vote cooldown actually applies now
/🆑
Do not merge this without coordinating with your server's host.
## About The Pull Request
Slightly refactors the way we handle IP intel.
You can still use the old data stored in the database.
Adds the ability to automatically reject connections determined by
config flags.
## Why It's Good For The Game
We used to have IP intel to check for VPNs, although it was disabled due
to being bad and unhelpful.
This refactor should make it much more manageable for hosts and admins.
## HOSTS BEWARE
This adds a new SQL table `ipintel_whitelist`
Look at the schema!
## Changelog
🆑
admin: The return of IPIntel
/🆑
---------
Co-authored-by: MrStonedOne <kyleshome@gmail.com>
Co-authored-by: oranges <email@oranges.net.nz>
* Adds respawn config option forcing respawn as another character slot (#78459)
## About The Pull Request
Adds an option to the respawn config which forces you to pick another
character (slot) before you respawn.
## Why It's Good For The Game
Just an idea i'm throwing out there, not necessarily pushing for it to
be enabled on any servers.
Respawning as an alternative character can be a good way to make people
less frustrated at dying, particularly if paired with the cooldown
config that already exists:
"Oh shucks, I died and got my head cut off and got absorbed and got
spaced by some changeling. I won't be able to finish my project or
whatever. At least in 15 minutes I may be able to join as my botanist
character to try something else rather than having to wait an hour and a
half for the round to tick over."
Also nice for downstream support.
(Obviously you can just, *ban* people who respawn as the same character,
use an honor system, but codifying it seems better than not.)
## Changelog
🆑 Melbert
config: Adds a config option for player respawning that enables
respawns, but forces you pick a new character.
config: "NORESPAWN" has been replaced with "ALLOW_RESPAWN 0". Unlimited
respawns is "ALLOW_RESPAWN 1" and character limited respawns is
"ALLOW_RESPAWN 2".
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Adds respawn config option forcing respawn as another character slot
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
## About The Pull Request
Adds an option to the respawn config which forces you to pick another
character (slot) before you respawn.
## Why It's Good For The Game
Just an idea i'm throwing out there, not necessarily pushing for it to
be enabled on any servers.
Respawning as an alternative character can be a good way to make people
less frustrated at dying, particularly if paired with the cooldown
config that already exists:
"Oh shucks, I died and got my head cut off and got absorbed and got
spaced by some changeling. I won't be able to finish my project or
whatever. At least in 15 minutes I may be able to join as my botanist
character to try something else rather than having to wait an hour and a
half for the round to tick over."
Also nice for downstream support.
(Obviously you can just, *ban* people who respawn as the same character,
use an honor system, but codifying it seems better than not.)
## Changelog
🆑 Melbert
config: Adds a config option for player respawning that enables
respawns, but forces you pick a new character.
config: "NORESPAWN" has been replaced with "ALLOW_RESPAWN 0". Unlimited
respawns is "ALLOW_RESPAWN 1" and character limited respawns is
"ALLOW_RESPAWN 2".
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
* Emergency Profile Dumps (#75924)
## About The Pull Request
Adds some hooks to the MC that detect if something ate a ton of real
time last tick, and reacts by dumping our current profile into a file
It's really frustrating to see a spike in td in our performance logs,
but see no reason in the profile because it's only taken every 5
minutes. This resolves that
I'm throwing this up so mso can give it a look over, not sure if I want
to use defines or configs here, taking suggestions
🆑
server: Adds a system to emergency dump profiles if too much time passes
between ticks
config: Added configs that control how often emergency profiles are
allowed to dump, alongside the threshold for what counts as too much
time between ticks
/🆑
* Emergency Profile Dumps
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
## About The Pull Request
Makes client upload limit a config. Increases max file size admins can
upload to 5mb, up from 2.5mb.
## Why It's Good For The Game
Makes it easier to do custom maps for events. Some of our in-game maps
are already larger than 2.5mb (delta is almost 3mb).
## Changelog
🆑
admin: admins can now upload files to the server up to 5mb (used to be
2.5mb)
config: file upload restriction is now config
/🆑
* Removes redundant CID randomizer check (#76396)
## About The Pull Request
This check is redundant because 512 fixed the exploit it was designed to
check. Randomizers still exist, but this code doesn't apply to them
since they use a different method.
Someone else tried this before but got his shit slapped for it being his
first PR and there being a possibility he was removing it so he could
bypass it. I'm not banned and have no possible ulterior motives; I just
want to get rid of dead code.
## Why It's Good For The Game
I'd make an Old Yeller joke, but the code's already dead, so.
Fixes#43227
## Changelog
This is not a player-facing change.
* Removes redundant CID randomizer check
---------
Co-authored-by: Vekter <TheVekter@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
## About The Pull Request
This check is redundant because 512 fixed the exploit it was designed to
check. Randomizers still exist, but this code doesn't apply to them
since they use a different method.
Someone else tried this before but got his shit slapped for it being his
first PR and there being a possibility he was removing it so he could
bypass it. I'm not banned and have no possible ulterior motives; I just
want to get rid of dead code.
## Why It's Good For The Game
I'd make an Old Yeller joke, but the code's already dead, so.
Fixes#43227
## Changelog
This is not a player-facing change.
## About The Pull Request
Adds some hooks to the MC that detect if something ate a ton of real
time last tick, and reacts by dumping our current profile into a file
It's really frustrating to see a spike in td in our performance logs,
but see no reason in the profile because it's only taken every 5
minutes. This resolves that
I'm throwing this up so mso can give it a look over, not sure if I want
to use defines or configs here, taking suggestions
🆑
server: Adds a system to emergency dump profiles if too much time passes
between ticks
config: Added configs that control how often emergency profiles are
allowed to dump, alongside the threshold for what counts as too much
time between ticks
/🆑
## About The Pull Request
Adds optional (disabled by default) respawn delay. If the player is
observer and have a body, it will firstly check the body. If the body is
destroyed or if there was none, then it will check observer's login
time.
## Why It's Good For The Game
Optional respawn delay is good, when you want players to comeback not
only as a midround event, but don't want them to not care about their
life. Also, if respawn is enabled, removes "money dupe" and other
problems with 0 respawn delay.
This proc can also be used for ghost-roles or anything else, where we
need to check how much time has elapsed since their death, but is not
implemented here.
## Changelog
🆑
add: Added optional respawn delay (disabled by default), which prevents
returning to lobby while dead.
/🆑
## About The Pull Request
Converts all logging, excluding perf and investigate, to json.
I focused on making the system as easy to use and as easy to add new
categories as possible.
Due to issues related to logging to world at global creation logger is
now a byond real, which is created directly before Master
Log categories support versioning, secret flagging, and sub-category
filtering. Although all of this is entirely optional for coders.
If you ever want to add a new category and use it, all you need to do is
make the barebones category datum and the define.
I've kept existing procs such as log_game, and simply turned them into a
wrapper for Logger.Log(xxx, ...)
## Why It's Good For The Game
Makes processing and filtering logs much easier in the future, while
only minimally downgrading log crawling experience.
I am also working on a log viewer frontend for admin usage however that
will take a little bit longer to finish up.
Also makes special logging and data tracking much easier thanks to a
data list processing implementation and handling
## Changelog
🆑
server: All logs are now formatted in json, excluding perf and
investigations
/🆑
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Allows Export of your Preferences JSON File (#75014)
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
* Allows Export of your Preferences JSON File
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Hey there,
This was spoken about in #70492 (specifically
https://github.com/tgstation/tgstation/pull/70492#issuecomment-1278069607),
and I have been waiting for this to be implemented for some time. It
never got implemented, so I decided to code it myself.
Basically, **if the server host doesn't disable it**, you are free to
export your JSONs as a player, right from the stat-panel. It's a pretty
JSON on 515 versions, too!
It's right here:
Here's what the prettified JSON looks like on 515.
There's a cooldown (default to 10 seconds) between exporting your
preferences.
#### Why is this config?
It's because in the past, a server host could always just file-share the
.sav or .json or whatever to the player, but they would have to do the
explicit option of actually bothering to make the files accessible to
the player. In that same line of logic, the server operator will have to
explicitly make the files accessible. This is mostly because I'm not
sure how good `ftp()` is at being a player function and wanted to have
some sort of cap/control somehow in case an exploit vector is detected
or it's just plain spammed by bots, so we'll just leave it up to the
direct providers of this data to elect if they wish to provide the data
or not.
## Why It's Good For The Game
Players don't have to log into Server A to remember what hairstyle they
loved using when they want to swap to Server B! That's amazing actually.
I always forget what ponytail my character has, and it'll be nice to
have the hairstyle in a readily accessible place (after I prettify the
JSON for myself).
It's also more convenient for server hosts to make player data like this
accessible if they really want to, too.
If we ever add an _import_ feature in the future (which would have to be
done with a LOT of care), this will also be useful. I wouldn't advise it
though having taken a precursory look at how much goes into it while
trying to ascertain the scope of this PR.
## Changelog
🆑
qol: The game now supports export of your preferences into a JSON file!
The verb (export-preferences) should now be available in the OOC tab of
your stat-panel if enabled by server operators.
server: Exporting player preferences is controlled by a configuration
option, 'FORBID_PREFERENCES_EXPORT'. If you do not wish to let clients
access the ftp() function to their own preferences file (probably for
bandwidth reasons?) you should uncomment this or add it to your config
somehow.
config: Server operators are also able to set the cooldown between
requests to download the JSON Preferences file via the
'SECONDS_COOLDOWN_FOR_PREFERENCES_EXPORT' config option.
/🆑
* Config Flag to Save Generated Spritesheets to Logs (#74884)
## About The Pull Request
I was helping someone debug some weird bug with spritesheets a bit ago,
and I didn't like having to manually comment out all of the `fdel()`
stuff in order to help visualize what the potential issue might have
been with the spritesheets on either their DM-side generation or their
TGUI-level display. I decided to add a compile-time level flag that will
automatically copy over any generated spritesheet assets (css and pngs)
to the round-specific `data/logs` folder for analysis when a developer
should need it.
I also had to switch around some vars and make a few new ones to reduce
how copy-pasta it might get and ensure standardization/readability while
also being 0.001 times faster since we benefit from the string cache
(unprovable fact).
## Why It's Good For The Game
It's incredibly useful to see the actual flattened spritesheet itself
sometimes when you're doing this type of work and you keep getting odd
bugs here and there. Also saves headache from having to clear out the
temp `/data/spritesheets` folder every time you comment shit out, as
well as having an effective paper trail for A/B testing whatever
bullshit you've got going on.
## Changelog
Doesn't affect players.
* Config Flag to Save Generated Spritesheets to Logs
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
I was helping someone debug some weird bug with spritesheets a bit ago,
and I didn't like having to manually comment out all of the `fdel()`
stuff in order to help visualize what the potential issue might have
been with the spritesheets on either their DM-side generation or their
TGUI-level display. I decided to add a compile-time level flag that will
automatically copy over any generated spritesheet assets (css and pngs)
to the round-specific `data/logs` folder for analysis when a developer
should need it.
I also had to switch around some vars and make a few new ones to reduce
how copy-pasta it might get and ensure standardization/readability while
also being 0.001 times faster since we benefit from the string cache
(unprovable fact).
## Why It's Good For The Game
It's incredibly useful to see the actual flattened spritesheet itself
sometimes when you're doing this type of work and you keep getting odd
bugs here and there. Also saves headache from having to clear out the
temp `/data/spritesheets` folder every time you comment shit out, as
well as having an effective paper trail for A/B testing whatever
bullshit you've got going on.
## Changelog
Doesn't affect players.
Adds a config-optional endgame chat message (#72860)
This basically does what we do for roundstart announcements, but for
round end.
With a delay between a round ending, the server rebooting, and a new
round starting, sometimes it feels like players would be more likely to
catch a roundstart when they know the previous game has just ended, and
not a few moments before the next one starts.
This idea was suggested to me several times by many people who don't
have good connections to servers and keep missing roundstart because
they just aren't given enough time to get on SS13.
I also included Round ID in this, so people who know what time they've
played a round can also now easily see which round it was, if they
wanted to go back to look at the logs for any reason they have.
🆑
config: There's now a config-optional announcer for a round ending.
/🆑
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Add config to validate admin discord commands with discord links and admin ranks (#73818)
This adds a config to secure discord chat commands used by admins.
When enabled it compares the discord id the chat command came from with
the linked discords db to find their ckey, then checks they have the
correct admin rights.
The check automatically self disables if the db is down or if legacy
admin ranks are enabled. (There is no config for discord account linking
or i'd just use that.)
Moved non-admin discord commands out of the admin modules folder and
into the discord modules folder.
Deleted some defunct shit. There was a global list and admin only notify
command that was used by nothing.
There was a whole discord config section that was used by nothing.
* Add config to validate admin discord commands with discord links and admin ranks
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
This adds a config to secure discord chat commands used by admins.
When enabled it compares the discord id the chat command came from with
the linked discords db to find their ckey, then checks they have the
correct admin rights.
The check automatically self disables if the db is down or if legacy
admin ranks are enabled. (There is no config for discord account linking
or i'd just use that.)
Moved non-admin discord commands out of the admin modules folder and
into the discord modules folder.
Deleted some defunct shit. There was a global list and admin only notify
command that was used by nothing.
There was a whole discord config section that was used by nothing.
* Adds a config option for warning clients about older builds (not just older versions) (#73549)
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
* Adds a config option for warning clients about older builds (not just older versions)
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
MSO was being tsundere about this and it seemed useful, so here we go
## Changelog
🆑
config: Added a warning build config setting, you can now lightly
repremand but not block clients with older builds but fine major
versions
/🆑
## About The Pull Request
config validation didn't actually throw on invalid configs, thus CI
never caught breaking changes
## Why It's Good For The Game
config should work
## About The Pull Request
This basically does what we do for roundstart announcements, but for
round end.
With a delay between a round ending, the server rebooting, and a new
round starting, sometimes it feels like players would be more likely to
catch a roundstart when they know the previous game has just ended, and
not a few moments before the next one starts.
## Why It's Good For The Game
This idea was suggested to me several times by many people who don't
have good connections to servers and keep missing roundstart because
they just aren't given enough time to get on SS13.
I also included Round ID in this, so people who know what time they've
played a round can also now easily see which round it was, if they
wanted to go back to look at the logs for any reason they have.
## Changelog
🆑
config: There's now a config-optional announcer for a round ending.
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Sends a toast notification when initializations complete. (#72465)
## About The Pull Request
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
## Why It's Good For The Game
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.
## Changelog
No player-facing changes.
* Sends a toast notification when initializations complete.
Co-authored-by: Y0SH1M4S73R <legoboyo@earthlink.net>
## About The Pull Request
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
## Why It's Good For The Game
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.
## Changelog
No player-facing changes.
* Adds support for non-science techwebs (+Config) (#71070)
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
* Adds support for non-science techwebs (+Config)
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
