* Add: 2 Quirks Configs (#81033)
This PR adds two new config options for quirks:
- *Flag* `DISABLE_QUIRK_POINTS`
- When enabled, disables quirk points balancing.
- When enabled, players can select positive quirks without first
selecting negative ones.
- When enabled, the quirk points balance visually hides itself on the
Quirks page.
- *Number* `MAX_POSITIVE_QUIRKS`
- Limits the maximum quantity of positive quirks which players can
select using the Character Preferences page.
- I ported this from the old `MAX_QUIRKS` define.
- When set to `0`, players won't be able to select any positive quirks,
and they won't appear on the Quirks page.
- When set to `-1`, players will be able to select any quantity of
positive quirks.
- When commented-out or undefined, the default is `6`.
- When set to `0` or `-1`, the positive quirk balance visually hides
itself on the Quirks page.
There is some downstream repositories asking for the quirks system to be
configurable. Additionally, I always find myself tweaking these values
on my own private servers and I thought it would be nice to share my
edits. Usually I was simply commenting-out sections of this code in
order to get the same result, so it helps to have an official way to
disable quirk points.
🆑 A.C.M.O.
config: Added two new config flags for quirks, DISABLE_QUIRK_POINTS and
MAX_POSITIVE_QUIRKS.
/🆑
* Oh come on
---------
Co-authored-by: Dani Glore <fantasticdragons@gmail.com>
Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com>
* Increased odds of station traits a little. Introduced a "budget", so smaller traits only take half as much space. (#80211)
## About The Pull Request
Recently, I chatted with others about how few station traits are rolled
on a round by round basis - about 59% of the shifts go without either
positive or negative traits for example - and how the mild most of these
traits are (not a bad thing per se), which results in an underwhelming
feature, despite the more interesting bits of it. So, after sharing
opinions, I've decided to make this PR to increase the rolls and odds a
bit.
EDIT: After reading comments and taking some time to think this
thoroughfully, I've decided to push the probabilities back a little in
favor of a simple budget system for station traits, to allow for smaller
things to only count as half a station trait. This mean smaller traits
won't necessarily stop "better" ones from rolling, or at least allow for
plentier permutations of traits that do not affect the round TOO much.
I've also reduced the weight of the glitched pda beeps trait from 15 to
10, the same of scarves, wallets and colored assistant jumpsuits.
## Why It's Good For The Game
I believe the current odds of station traits to be a smidge low, and
that the lack of any sort of cost-budget for station traits to hurt the
rarer, more interesting traits (and the feature in general) if the more
common, milder ones take just as much space. It's totally within the
spirit of the feature to have small, niche traits, though they can get
quite boring pretty fast on their own, so what I'm saying is that their
cost should stay low so that other traits can roll.
## Changelog
🆑
refactor: Introduced a simple budget system to station traits, so that
smaller things only count as half a trait, for example.
balance: Increased the odds and maximum number of station traits that
can be rolled each shift.
/🆑
* Increased odds of station traits a little. Introduced a "budget", so smaller traits only take half as much space.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* 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>
* Fixes some more issues with job configs not being loaded by ResetOccupation (#78596)
## About The Pull Request
Job configs would get reset by ResetOccupation and not loaded
afterwards. This fixes that.
## Why It's Good For The Game
Bugfix
## Changelog
🆑
fix: Fixed job configs not being loaded properly.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixes some more issues with job configs not being loaded by ResetOccupation
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.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>
* Alert a Discord role when a new player joins (#77432)
## About Why It's Good For The Game The Pull Request
What it says on the tin. A requested feature for people who like to keep
an eye on swaths of new players. A config that is off by default, but a
Discord role ID can be added to have TGS ping that role.
Also sends alerts to Discord if a player with sketchy telemetry joins.
## Changelog
🆑 Tattle
admin: Pings an admin role on discord when a new player joins (when
enabled by config)
/🆑
---------
Co-authored-by: tattle <article.disaster@ gmail.com>
* Alert a Discord role when a new player joins
---------
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@ gmail.com>
* Removes TTS voice disable option (#76530)
## About The Pull Request
Removes the TTS voice disable option, which was already unavailable on
TG as it was set to off by default. The reason this was added was so
that downstreams could toggle the config on or off.
## Why It's Good For The Game
I think this option fundamentally undermines the TTS system because it
allows individual players to disable their voice globally, meaning that
players who have TTS enabled will not be able to hear them.
This worsens the experience for players who have TTS enabled and it's
not something I want to include as an option. If players don't like
their voice, they can turn TTS off for themselves so that they don't
hear the voices. If players don't want to customize their voice, they
can quickly choose a random voice, and we can take directions in the
future to make voice randomization consistent with gender so that a male
does not get randomly assigned a female voice and vice versa.
This option is already unavailable on TG servers because it was
primarily added for downstreams, but I don't think giving downstreams
the option to undermine the TTS system is the right direction to take.
Downstreams are still completely free to code this option on their own
codebase.
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Removes TTS voice disable option
* Returns the option to not have a voice to TTS, properly this time
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Xenomorph/Alien Rework 2023: Part 1 (#75286)
## About The Pull Request
Alternative to #75277
Kept you waiting, huh?
This PR is the first part of a Xenomorph rework which seeks to make the
big lugs more balanced and up to date with /tg/'s current design. This
mainly involves curtailing xenomorph's infamous hardstuns into more
interactive forms of combat, while also giving some buffs to the
xenomorph's more unique abilities in order to keep them threatening.
Part 1 will focus on simple number changes and some simple mechanic
changes. In the future, changes will be made to endgame involving
xenomorphs, along with changes to other facets of Xenomorphs.
Highly based off of #55937.
Changes:
- Xenomorph disarm has been completely reworked. While a disarm will
attempt to, well, disarm, a human opponent should they be holding
something, it will no longer immediately hardstun targets when they
aren't. Instead, the xenomorph will shove the target several tiles back
and inflict 35 stamina damage. If the target slams into a wall, this
will also come with the added effect of knocking them down. If a human
is incapacitated, however, right click will slam them into the ground,
which paralyzes them for a lengthy 5 seconds (which is ultimately half
the time xenos could stun you for before), allowing for safe transport
back to the nest as long as you keep them close.
- Humans can now shove xenomorphs. Due to being the superior predator,
however, you can't knock down xenomorphs from shoving. You can slow them
for a little bit akin to humans though.
- Neurotoxin no longer is a hardstun. Instead, it deals 50 stamina
damage on contact. It is still resisted by BIO armor.
**HUNTER:**
- Speed reduced from -1 to -0.3.
- Pounce speed is twice as fast as before (1 to 2)
- Hardstun time on pounce reduced from 10 seconds to 5 seconds.
Hunters being insanely fast has been a major balance-ruining factor of
xenomorphs for many years now. These buggers could practically ambush
anyone, hardstun them immediately, and then leave before anyone could do
anything. Now, with their speed nerfed and in combination with the xeno
shove changes, hunters will need to spend more time to down a target.
Their pounce was practically useless, so its been sped up in order to
make it more practical to use.
**SENTINEL**
- Speed reduced from 0 to 0.2
- Cloak alpha reduced from 0.75 to 0.25 (you're more hidden now)
Sentinels receive a large nerf in regards to their spit, but their
before useless cloaking ability has been greatly improved upon as
compensation. They now serve better as defenders and ranged ambushers.
**XENOMORPH DRONE**
- No changes
As in the original PR, drones are perfeclty balanced in my eyes, so no
changes were required.
**XENOMORPH PRAETORIAN**
- Speed increased from 1 to 0.5
- No changes
Praetorians get affected by the nerfs of the other xeno abilities, but
now they're a bit faster in order to close the gap to use their
abilities.
**XENOMORPH QUEEN**
- Speed increased from 3 to 2
- Health increased from 400 to 500
- Damage increased from 20 to 50
Xenomorph queens have been sped up and made more tanky and lethal in
close-range combat. Fighting this beast up-close should be a death
sentence to almost anything else in the game. Speed increases will help
her re-position and close the gap on potential prey.
**OTHER CHANGES**
- Fixed a bug where simplemobs didn't actually use xenomorph's damage
values when they were attacked by them.
## Why It's Good For The Game
Xenomorphs are old, and haven't been updated for quite a long time. This
has left them as sources of a bunch of hardstuns which made counterplay
from a modern spaceman extremely difficult. With these changes, fighting
xenomorphs is more interactive and should end up being more enjoyable
for both crew and xenos. Buffs were also given out to incentivize usage
of xenomorph's unique abilities as opposed to the standard disarm spam
which was most effective for them until now.
## Changelog
🆑
balance: Xenos have been rebalanced, removing their hardstuns on their
disarm and neurotoxin, along with a slew of other changes. Xenos have
received buffs to their more unique abilities in return.
fix: Fixed simplemobs ignoring xenomorph's melee damage values when
being attacked by them.
/🆑
* Xenomorph/Alien Rework 2023: Part 1
---------
Co-authored-by: IndieanaJones <47086570+IndieanaJones@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Datumizes out jobconfig.toml (extensibility edition) (#76102)
## About The Pull Request
Hey there,
#75992 (fc54fd6a60) made me realize just
how wacky the job config system is to people trying to add more new
stuff to it, so I finally got the motivation to fix it up.
The gist is that it does all of the same stuff on the front-end as you
would expect, but instead of having to modify core generation code to
create/recreate the files, it instead uses a robust series of getters
and setters. It's much better to use these getters and setters because
we can apply needed game logic (like ensuring that the age that the
server operator puts in is actually sane, and not completely out of
bounds (if you want to permanently price people out of a position, just
set it to 0)). The getters are also nifty too, because they let me atone
for an early mistake I made with how assistants are meant to work with
"unlimited" nonsense.
All a new coder who wants to add stuff to the config needs to do now is
create the define, create the datum, add the procs for the datums, and
that's it! They don't have to do any of the wacky stuff or account for
weird stuff or do any weird copypasta, it's all handled by the system.
One datum is all you need, quite neat.
This also fixes some issues in #75992 that probably weren't discovered
in testing, but the only good way to fix it was a retune+refactor, which
is included in this PR.
## Why It's Good For The Game
Much more extensible, ensuring this system actually works as fully
intended, etc.
I fixed up the documentation (they didn't regenerate the job config
after they updated the code-side documentation) and some weird spacing
stuff that I missed in my review of that aforementioned PR. Everything
should work as expected, it's been tested quite a bit. It's also in its
own folder now, which is neat because we can share the local defines and
split all this stuff out of the already-quite-large SSjob file.
## Changelog
🆑
server: job_config.toml should now comply with reload-configuration
verb, meaning you can hot-reload the configuration from disk and have it
apply ingame automatically.
config: The documentation for setting Minimum Character Age on a per-Job
basis has been altered to be more explicit.
fix: The Minimum Character Age configuration entry is now sanitized to
ensure that it's within the codebase-defined ages, since there's no
(legitimate) way to get a character outside of those ages anyways.
Invalid values will log to the config log.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Datumizes out jobconfig.toml (extensibility edition)
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* 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>
* Fix Basic Mob Speed (#75306)
## About The Pull Request
All basic mobs became slower because of #75186. This fixes that.
## Why It's Good For The Game
Intended speed.
## Changelog
🆑
fix: Fixes the speed of all basic mobs.
/🆑
* Fix Basic Mob Speed
---------
Co-authored-by: Comxy <tijntensen@gmail.com>
* fix: Basic mobs' multiplicative movespeed (#75186)
## About The Pull Request
Adds default multiplicative movespeed for basic mobs, so their speed is
configurable via config.
## Why It's Good For The Game
Closing things which were probably missed in the development of basic
mobs
## Changelog
🆑
code: Adds default multiplicative movespeed for basic mobs, to make them
editable in config
config: Default multiplicative movespeed for basic mobs in example
config
/🆑
* fix: Basic mobs' multiplicative movespeed
---------
Co-authored-by: larentoun <31931237+larentoun@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>
* 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>
* Refactors and defuckulates dbcore. Adds support for min_threads rustg setting, Reduce query delay, Make unit tests faster (#74852)
dbcore was very fuckulated.
It had 3 lists of queries, but they all had their own current_run style
list to support mc_tick_check (as it was already being done before with
the undeleted query check, so i can understand why they ~~cargo culted~~
mirrored the behavior) This was silly and confusing and unneeded given
two of those loops can only process at most 25 items at a time on
default config, plus these were cheap operations (ask rustg to start
thread, ask rustg to check on thread).
Because of the confusingness of the 6 lists for 3 query states, The code
to run pending/queued queries immediately during world shutdown was
instead looking at the current_run list for active queries, **meaning
those queries got ran twice.**
The queued query system only checked the current active query count in
fire(), meaning even when there was nothing going on in this subsystem
new queries had to wait for the next fire() to run (10 ticks, so 500ms
on default config)
Those have all been fixed.
the config `BSQL_THREAD_LIMIT` has been renamed to
`POOLING_MAX_SQL_CONNECTIONS` and its default was lowered to match
MAX_CONCURRENT_QUERIES .
added a new config `POOLING_MIN_SQL_CONNECTIONS`, allowing you to
pre-allocate a reserve of sql threads.
The queue processing part of SSdbcore's fire() has been made to not obey
mc_tick_check for clarity and to make the following change easier to do:
If there is less than `MAX_CONCURRENT_QUERIES` in the active queue, new
queries activate immediately.
(its ok that there are two configs that kinda do the same thing,
POOLING_MAX_SQL_CONNECTIONS maps to max-threads in the mysql crate, and
it seems to only be a suggestion, meanwhile MAX_CONCURRENT_QUERIES can't
do anything during init, which is when the highest amount of concurrent
queries tend to happen.)
🆑
config: database configs have been updated for better control over the
connection pool
server: BSQL_THREAD_LIMIT has been renamed to
POOLING_MAX_SQL_CONNECTIONS, old configs will whine but still work.
fix: fixed rare race condition that could lead to a sql query being ran
twice during world shutdown.
/🆑
I have not tested this pr.
* Refactors and defuckulates dbcore. Adds support for min_threads rustg setting, Reduce query delay, Make unit tests faster
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
* Station shift start time config (#74711)
## About The Pull Request
We have a config flag to set random shift start times or server sync'd
start times, but not one to simply set the shift start time.
## Why It's Good For The Game
Control over the shift start time. This way events such as breakfast can
occur during actual breakfast hours.
## Changelog
🆑 LT3
config: Station shift start time can now be set in the server config
/🆑
---------
Co-authored-by: Kyle Spier-Swenson <kyleshome@ gmail.com>
* Station shift start time config
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: Kyle Spier-Swenson <kyleshome@ gmail.com>
* Auxtools is now a config opt-in (#74501)
See https://github.com/tgstation/tgstation/pull/74497
Causes auxtools to not be a default part of the server environment and
requires server operators to manually enable it.
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Auxtools is now a config opt-in
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Removes Starlight Config (#74289)
## About The Pull Request
It was config'd off to save init time, but having it function in testing
and mapping is more valuble then the time spend on it.
On that topic, we spend roughly 1.7 seconds of init on this.
~1.3 is spent handling the light sources and their light object
modifications (this is potentailly inflated since other sources could
cause the same objects to need updates)
~0.3 is spent searching for space turfs around lighting_objects during
init.
This will impact change_turf slightly too, costing about ~0.07 in local
testing.
It does save time for live however, since we avoid these config checks.
## Why It's Good For The Game
I believe this time is worth spending.
I've had people try to "fix" artifacts of starlight not being enabled,
things that aren't bugs.
The test environment should as much as we can make it reflect the visual
reality of the game. This helps ensure that
## Changelog
🆑
server: The starlight config has been removed, as it is enabled by
default
/🆑
* Removes Starlight Config
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
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>
* 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>
* 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>
* Add development override configuration system (#71427)
Config system will now load dev_overrides.txt automatically if it
exists, but this file is in gitignore. I want to use this for
configuring SQL and such easier.
* Add development override configuration system
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* 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>
* kill skyrat_wiki var
* OPTIONAL COMMIT: Comment "Tidying"(?) and Description improvements
* config i hope i did these right
WIKIURLSKYRAT IS OBOSLETE AND REMOVED
* hnhbg
* Rocking The Boat, er, Map Vote (#69561)
* Rocking The Boat, er, Map Vote
Hey there,
A while ago, I spooke (typo intentional) to some other people. One frustration I heard was the fact that people would sometimes sneak through map votes during the very start of a shift, during a high-paced portion, or just as a meme. People in OOC would then flood the vote, putting in any given station. However, if a vote happens 10 minutes in- and the round goes for 70 minutes and not many of the original players are around, then it's not particularly fair to those who have to play next shift on a map they bemoan.
So, we can rock the vote! If a player isn't particularly chuffed with the hand they are given, they can poll the players to see if they want to change the map as well. If rocking the vote goes through, huzzah, you get the ability to vote for the map again. If it doesn't go through: tough luck. You can rock the vote one time per shift by default, and server operators can change the amount of times you can call to rock the map vote at their discretion. Calling to rock the vote either successfully or non-successfully counts as a "call", and when that limit is exceeded: no more calls.
Does this mean that we will only rotate between two maps because pissants will keep rocking the vote until they get what they like? Maybe? I still see people bemoan getting Tram or shit the bed over IceBox, but I think enough people get sick of bread-on-butter to take the server where it need to go. If operators don't really like seeing only two maps play, they can always adjust the config to ensure it doesn't happen.
* makes the grammar grammar
it would be "Rock the Vote vote" otherwise
* Rocking The Boat, er, Map Vote
Co-authored-by: san7890 <the@san7890.com>
* Cadaver spawner fixes (#69544)
fix: Fixed a runtime preventing nonhuman cadavers from spawning properly.
config: Cadaver spawners will no longer yell at you when morgue_cadaver_other_species_probability is blank.
config: morgue_cadaver_disable_nonhumans will now properly disable nonhuman races! (It was reversed, woops.)
* Cadaver spawner fixes
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
